Learn · Governance
How to audit every action an AI agent takes
Most agent logs record a token and call it an audit trail. But a token is just a string anyone could have copied. A real audit trail proves which agent acted, under whose authority, in evidence you can verify after the fact.
Why token logs aren't enough
A log line that says "request authenticated with token T" tells you a valid token was presented. It does not tell you the request genuinely came from the agent the token names, because a token read out of a log or copied from memory would produce the same line. If your audit evidence is a plain bearer token, your evidence is only as good as the assumption that the token was never copied — which is exactly the assumption an incident calls into question. For agents, bearer-token logging is attribution theatre.
Attribution you can re-verify
Provable attribution means each action is accompanied by an operation proof made with an anchor key that never leaves the agent's host, over the exact operation requested. Later, anyone with the public key can re-verify that this specific action was signed by this specific agent — no trust in the log pipeline required. The identity token requires proof of possession, so a copied token cannot reproduce the operation proof. The result is evidence rather than a claim: you can hand an auditor a record and they can check the math themselves.
The test of an audit trail is whether it survives the question "could someone have faked this?" An operation proof backed by proof of possession survives it; a logged bearer token does not.
What to record
- Agent identity — the verified, unique identity (the anchor key's thumbprint) that signed the request, not a shared key.
- Sponsor — the accountable sponsor that enrolled the agent, from the enrollment record.
- Operation and resource — exactly what was requested and against what.
- Boundary decision and policy version — allow or deny, and the policy that made the call.
- Operation proof and timestamp — the proof itself, re-verifiable later, and when it happened.
How to set it up
- Prove every request. Use per-agent anchor keys and request signing (RFC 9421) so each action carries an operation proof. See per-agent identity.
- Decide and record at the Gateway MCP. Capture the verified identity, operation, boundary decision, and policy version together.
- Retain the proofs. Keep the operation proofs so boundary decisions can be re-verified independently.
- Tie back to the sponsor. Join each action to the enrollment record for the accountable sponsor.
Oathera frames audit as Gateway assertions, verifiable credentials from the credential service (VCI), and OpenTelemetry export. See the security overview.
FAQ
How do you audit every action an AI agent takes in a way that proves the identity behind each request, not just logs a token?
Have each agent produce an operation proof over the exact request with an anchor key that never leaves its host, and record that proof alongside the verified identity, the sponsor, the operation and resource, and the boundary decision. Because the operation proof requires proof of possession and is re-verifiable, the log proves which agent acted rather than merely recording a token that could have been copied.
What is wrong with logging the token on each request?
A plain token is a bearer string; a copy of it produces an identical log line. If your audit evidence is a token, it cannot distinguish the real agent from anyone who obtained the token. An operation proof made with a non-exportable anchor key can.
Can an auditor verify the trail without trusting our logging pipeline?
Yes. Because each action carries an operation proof made with the agent's anchor key, anyone with the corresponding public key can re-verify that the specific action was signed by the specific agent, independent of how the log was stored.