How do I record what triggered an AI agent, the permission decision and the exact tool call outside the agent's own memory, so the record can't be rewritten?

What should I check, step by step?

1. Decide which actions get a record: anything that writes, sends, pays, deletes, changes permissions or calls an outside service. Read-only lookups can go to normal logs.

2. Write the record from the tool-execution layer (your tool runner, a hook, a proxy or gateway), never from a tool the model calls to 'log' itself. The model chooses what to call; it shouldn't choose what gets written about it.
3. Before the call, write an intent entry: trigger type and id (user message id, webhook delivery id, cron job id, parent agent and task id), a hash of the trigger content, the policy or approval id and version that allowed it, the decision, tool name and server, call id and a hash of the canonical arguments.
4. After the call, write an outcome entry with the same call id: result hash or typed error, duration and whether the tool reported a side effect. A missing outcome after a crash is itself evidence.
5. Chain each entry to the previous one by hash, and sign or anchor the chain head now and then, so a deleted or edited entry shows up as a break.
6. Store it where the agent's credentials can append but not update or delete: a separate service, an append-only table with no update grant, or an outside ledger. The agent's memory directory and working folder are the wrong place.
7. Never let the agent read its own action record back into trusted memory as instructions. If it needs history, give it a summary marked as data.
8. Check memory against the record now and then: if memory says 'the user approved refunds over $500' and no approval entry exists, treat the memory as poisoned.

Why can't an agent's memory be the record of what it did?

Memory is meant to change. Anthropic's memory tool docs describe Claude creating, reading, updating and deleting files in a memory directory that persists between sessions, with your application running each operation. That is useful for continuity and wrong for evidence.

• OWASP's Top 10 for Agentic Applications 2026 lists Memory & Context Poisoning (ASI06): attackers corrupt or seed stored memory, summaries or retrieval stores so later reasoning and tool use go wrong, including across sessions. A record stored in the same memory is open to the same corruption.
• Even without an attack, summaries drop detail. A compacted note that says 'sent the invoice' doesn't tell you which recipient, amount or attachment went out.

What should be recorded for each agent action?

Trigger: what started this step and where it came from. Record the source (user, webhook, schedule, another agent), its id and a hash of the content, so you can tell a person's request from an instruction that arrived inside a fetched page.

• Permission decision: the policy id and version, or the approval id and approver, the decision, and a reason code. If no rule applied, record that too.
• Exact call: tool name, server or connector, call id, and a hash of the arguments in canonical form (fixed key order, RFC 8785 for JSON). Keep a redacted copy of the arguments if you need to read them later, and the full copy only where your data rules allow.
• Outcome: result hash or error, and the time from a clock the agent can't set.

Why write the record before the tool runs?

Writing the intent entry first means a crash, timeout or killed process mid-call still leaves a trace that the call was attempted and under which permission.

• It also gives you a place to stop: if the record can't be written, don't run the tool. An action with no record is one you can't account for later.
• Pair intent and outcome by call id. Intents with no outcome are the calls to check first after an incident.

How is this different from a tool-call log?

A tool-call audit log answers 'what did the agent call'. This record also ties each call to why it ran (the trigger) and what allowed it (the decision), and it's written before the call, so the chain holds up when the agent's own state doesn't.

• Gateway recording captures calls at the network edge. This record can sit there too, but its point is the separation from memory: nothing the agent remembers, summarises or forgets changes it.

What are the common failure modes?

The 'audit log' is a file in the agent's working folder, which a later step tidies up or overwrites.

• The model writes its own log entries through a logging tool, so a prompt injection can make it log something other than what happened.
• Only the tool name is stored, not the arguments hash, so you can't tell which recipient or amount was used.
• The trigger isn't recorded, so after the fact nobody can tell whether a person asked for the action or a fetched web page did.
• The record is fed back into memory as trusted context, and a poisoned entry gets repeated as if it were history.