Agent Flight Recorder
Docs

One API call per action.

Do this at every tool call, decision point, and output in your agent — the ledger does the rest.

01 · Create an API key

Sign up, open API keys, and create a key for your agent. Keys start with afr_. Keep it secret — it writes to your ledger.

02 · Register your agent

Add the agent in your console. The agent_id you POST must match the agent ID you registered.

03 · Post actions

Python — one line per action:

import requests

requests.post("https://agent-flight-recorder.onrender.com/v1/actions",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={
        "agent_id": "support-bot",          # must match a registered agent
        "action_type": "tool_call",          # e.g. tool_call, decision, message
        "tool_name": "issue_refund",         # optional
        "input_summary": "Customer asked for a refund on order #1234",
        "output_summary": "Issued $42.00 refund via Stripe",
        "metadata": {"order_id": "1234", "amount_usd": 42.00},  # optional dict
    })

JavaScript — one line per action:

await fetch("https://agent-flight-recorder.onrender.com/v1/actions", {
  method: "POST",
  headers: {"Authorization": "Bearer YOUR_API_KEY", "Content-Type": "application/json"},
  body: JSON.stringify({
    agent_id: "support-bot",
    action_type: "tool_call",
    tool_name: "issue_refund",
    input_summary: "Customer asked for a refund on order #1234",
    output_summary: "Issued $42.00 refund via Stripe",
    metadata: { order_id: "1234", amount_usd: 42.00 },
  }),
});

04 · Verify the chain

Open your agent in the console and hit Verify chain — every hash is recomputed server-side with a PASS/FAIL stamp. Or check programmatically:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  https://agent-flight-recorder.onrender.com/v1/chain/support-bot
# {"agent_id": "support-bot", "intact": true, "break_seq": null, ...}

05 · Embed the integrity badge

Put this on your trust page. Green chain intact · N actions, or red the moment anything breaks:

<img src="https://agent-flight-recorder.onrender.com/badge/PUBLIC_ID.svg" alt="Agent audit trail integrity badge">

Your agent's PUBLIC_ID is shown on its console page.

06 · Declare causal links (caused_by)

When one agent's action causes another's, declare it at ingest — the target is validated and the exact record is pinned at write time:

requests.post("https://agent-flight-recorder.onrender.com/v1/actions",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={
        "agent_id": "refund-bot",
        "action_type": "tool_call",
        "tool_name": "issue_refund",
        "output_summary": "Issued $42.00 refund via Stripe",
        "caused_by": {"agent_id": "orchestrator", "seq": 12},  # or {"hash": "3c07…"}
    })

The Pro causality graph renders every declared link across your agents as a labeled DAG — trace a multi-agent incident back to its cause, with hash citations.

07 · Mint a Tamper-Seal certificate (Pro)

Open any agent and hit Certificate to mint a signed attestation of ledger integrity — agent, action count, chain tip, minted-at, HMAC-SHA256 signature. Anyone can verify it without an account:

curl https://agent-flight-recorder.onrender.com/v1/attestations/AFR-20261011-XXXXXX
# {"cert_id": "…", "valid": true, "detail": "chain intact · 1482 actions at minting", …}

We never certify a broken chain. A public human-readable certificate lives at https://agent-flight-recorder.onrender.com/attest/<cert_id> — hand it to auditors, customers, regulators.

08 · Ask the Tape (Pro)

Every agent page has an Ask the Tape box: interrogate the ledger in plain language — "what happened before seq 42", "how many tool_calls", "first issue_refund use", "between seq 10 and 20". Answers are computed deterministically from the ledger — no language model, so no hallucinations — and every claim carries a seq # and hash.

09 · Log image generations with consent (EU AI Act Article 5)

The EU AI Act's Digital Omnibus update prohibits non-consensual intimate imagery (NCII) and CSAM, effective 2026-12-02. Post an image_generation event for every image your agent produces, with consent metadata — the ledger becomes your Article 5 evidence:

requests.post("https://agent-flight-recorder.onrender.com/v1/actions",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={
        "agent_id": "creator-bot",
        "action_type": "image_generation",   # first-class event type
        "image_gen": {
            "model": "veo-3.1",              # model/tool used
            "prompt_sha256": "9f2c…",        # 64 hex chars: SHA-256 of the full prompt
            "prompt_summary": "Product hero shot of a sneaker on white",  # redacted, ≤300 chars
            "output_sha256": "b71d…",        # 64 hex chars: SHA-256 of the generated file
            "consent_attested": True,
            "consent_attested_by": "jane@studio.com",
            "consent_attested_at": "2026-10-12T14:30:00Z",
            "subject_is_real_person": False,
        },
    })

Instead of prompt_sha256 you may send "prompt": "the full prompt text" — it is hashed server-side and never stored. The ledger keeps only the hash plus your redacted summary. input_summary is ignored for these events and replaced by the redacted summary.

Deterministic, never an accuracy play: the ledger records what your agent reports — model, hashes, consent attestations. It never inspects, classifies, or claims to verify image content, and a recorded attestation is not proof consent was genuine — it is proof the attestation was recorded in a tamper-evident chain.

  • Every image_generation event with consent_attested: false fires a consent_missing alert in your inbox immediately.
  • Filter the agent timeline by event type to review consent metadata per record.
  • Pro: the Article 5 evidence extract (agent page → 📦 Article 5 extract) bundles the hash-chained generation sequence + consent attestations + chain-integrity statement as downloadable JSON, PDF, or a printable page — hand it to an auditor.

10 · Log agent memory (Memory Integrity Ledger)

Persistent agent memory — Meta's "Wonder" active memory, claude-mem, and every framework that carries context across sessions — is an unlogged attack surface: memory poisoning (malicious instructions persisted into long-term memory) and cross-session contamination (a write in session A steering a flagged decision in session B). Post a memory_write event for every memory your agent reports persisting, and a memory_read event for every memory fragment injected into a session:

requests.post("https://agent-flight-recorder.onrender.com/v1/actions",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={
        "agent_id": "support-bot",
        "action_type": "memory_write",      # or "memory_read"
        "memory": {
            "session_id": "sess-2026-10-13-001",   # which session wrote it
            "memory_key": "user:preferences",      # the key/namespace
            "content_sha256": "4a1f…",             # 64 hex chars: SHA-256 of the full memory text
            "summary": "User prefers concise answers; timezone America/Belize",  # redacted, ≤300 chars
            "source": "user",                     # user | agent | tool | environment
            "ttl": 86400,                         # seconds until expiry; 0 = persistent
        },
    })

Instead of content_sha256 you may send "content": "the full memory text" — it is hashed server-side and never stored. The ledger keeps only the hash plus your redacted summary. input_summary is ignored for these events and replaced by the redacted summary. For memory_read, send session_id (the reading session), memory_key, and optionally content_hash (fingerprint of the injected fragment).

Deterministic, never an accuracy play: the ledger records what your agent reports persisting — it never judges whether a memory is true, safe, or correct. Only that it existed, was read, and preceded a decision.

  • A memory_write from an untrusted source (agent, tool, environment) whose summary contains tool-call instructions or credential-like material fires a memory_poisoning alert to your alert inbox immediately.
  • When a memory_read in session B consumes a key last written by a different session A, and a flagged/bypassed/anomalous decision follows in session B, a memory_contamination alert fires with the full write→read→decision lineage (write seq/hash/session/time → read seq/time → decision seq).
  • The 🧠 Memory ledger page on every agent (all plans) shows writes + reads with TTL/decay state (live / expired / persistent), per-key cross-session lineage, and memory forensics: for every recorded decision, replay exactly what the agent knew at that moment.
  • Pro: the 🧠 Memory evidence extract (agent page → 🧠 Memory extract) bundles the hash-chained memory sequence + TTL state + chain-integrity statement + contamination lineage as downloadable JSON, PDF, or a printable page — hand it to an auditor.

Limits & guards

  • Ingest is rate-limited per API key; monthly action quotas are enforced server-side (Free: 1,000/mo, Pro: 100,000/mo, Team: unlimited).
  • Any URL inside your payload must point at a public internet host — private/internal addresses are rejected (SSRF guard).
  • A caused_by target must name a registered agent in your workspace and an existing record; invalid targets are rejected with 400.
  • Summaries are capped at 4,000 characters each; metadata at 20 KB.
  • image_generation events require image_gen with a valid prompt_sha256/prompt, a redacted prompt_summary (≤300 chars), and output_sha256. When consent_attested is true, consent_attested_by and a non-future consent_attested_at are required. Raw prompts are never stored.