AI agent audit trail: recording what each agent did, for whom, and why it was allowed

What an AI agent audit trail is

An AI agent audit trail is a record system that captures each action an agent attempts, the decision made about it and the result. It is built so that missing or changed entries show. Each entry says which agent, owned by whom and acting for whom, did what to which record. It also names the policy version, any approval and the result.

It is not the same as the logs you already have. Application logs show what a service did, often under one shared credential. Model-provider logs show what a model was asked and answered, not what the tool call then did at the service. Observability traces help with debugging, but they are often sampled and easy to edit. An audit trail is complete, unsampled and built to be shown to someone who has no reason to trust you. That is the difference between agent activity evidence and agent telemetry.

AI agent logging matters more than logging for human users, because no person clicks each button. When something goes wrong, the record is often the only witness. This page covers what to record, what to leave out, how to make the record tamper-evident and how to map it to frameworks. It is part of our practical guide to AI agent security.

Questions auditors and incident responders ask

Design the record backward from the questions. These come up in audits, customer security reviews and incident investigations:

1. Which agents exist, and who owns each one? The agent inventory answers this.
2. What was this agent allowed to do on a given date, and which policy version said so?
3. Whom was the agent acting for when it made this call?
4. Who approved this action, and were they independent of the person who asked?
5. Which records did it read or change?
6. What did it try to do that was refused?
7. Can you show the record is complete and unaltered?
8. How long do you keep it, and who can read it?

If your logs can't answer question 2 for last quarter, you will be rebuilding policy from memory during an incident. Version your policies and write the version into every decision.

Incident responders add a speed requirement. They need to filter by agent, by person acted for, by record and by outcome within minutes. Store structured fields, not free text.

What to record for each agent action

Record one entry per decision at the point where the action is enforced, usually a gateway or proxy in front of the service. Recording inside the agent is weaker, because a manipulated agent can skip writing the entry. The OWASP Logging Cheat Sheet frames the minimum as "when, where, who and what". For agents, "who" has three parts: the agent, its owner and the person it acts for.

An example receipt

The JSON below is illustrative. The field names are ours for this example, not a standard or a product schema. It records a refund by the invoice reconciler at Northwind, a simulated company from AgentFort's lab demos:

{
  "receipt_id": "rcpt_01JB8X4Q7M",
  "time": "2026-10-28T14:09:41.207Z",
  "agent": "spiffe://northwind.example/agents/invoice-reconciler",
  "owner": "team:finance-platform",
  "acting_for": null,
  "operation": "billing.refunds.create",
  "target": { "type": "invoice", "id": "INV-20931" },
  "decision_inputs": { "amount": 450, "currency": "USD" },
  "decision": "allowed_after_approval",
  "reason": "refunds above 100 USD need Finance approval",
  "policy": { "id": "billing-refunds", "version": 14 },
  "approval": { "approver": "user:dana", "approved_at": "2026-10-28T14:09:38Z", "uses": 1 },
  "outcome": { "executed": true, "status": 201 },
  "data_findings": [],
  "prev_hash": "sha256:9c1e…",
  "hash": "sha256:4b7a…"
}

What to leave out of the record

An audit trail that copies everything becomes a second store of your most sensitive data. The OWASP cheat sheet says access tokens, passwords, encryption keys, session identifiers, payment card data and sensitive personal data should usually not be recorded directly. For agents, leave out:

• The values of sensitive fields in requests and responses. Record the field and the action taken, such as "SSN masked", not the number.
• Prompts and model responses that contain personal data. If you must prove which content was involved, record a reference or a keyed hash. Plain hashes of short values such as phone numbers can be reversed by guessing.
• Credentials of any kind, including the token the agent presented.
• Full documents the agent read. Record the document ID and any finding, such as "hidden instruction detected", as covered in data protection for AI agents.

Investigators sometimes want content. If you keep it, put it in a separate store with stricter access, short retention and its own access log, not in the audit trail.

Denials and approvals belong in the record

Many teams log only successful calls. For agents, refusals are often the more useful evidence.

A denial shows that a control operated. An auditor testing "agents can't refund another customer's invoice" wants to see refused attempts, not just an absence of bad refunds. Denials also reveal attacks. A burst of refused calls from one agent can mean a prompt injection is steering it, or that it is probing for access. And denials expose broken grants: an agent refused the same legitimate call all day needs a policy fix.

At Northwind, four refund requests produced four different records. A $40 refund ran. A $450 refund was held for Dana in Finance and ran once after she approved it. A $4,500 refund was blocked by a limit of $2,000 per invoice per week. A refund on another customer's invoice was denied after the invoice was read. Each record is evidence that a specific rule worked; see spending limits for AI agents.

Approvals need their own fields: who asked, who approved, what exactly they saw, when, and how many times the approval may be used. Record that the approver was not the person the agent acts for. Separation of duties only counts as evidence if the log shows it. Human approval for agent actions covers the workflow.

Tamper evidence: hash chains and evidence in your own account

Logs count as evidence for AI agent actions only if you can show nobody altered them. The usual technique is a hash chain. Each entry includes a hash of the previous entry. Change or delete one entry, and every later hash stops matching.

AWS CloudTrail uses a version of this. It hashes each log file with SHA-256 and delivers an hourly digest file listing those hashes. It signs each digest, and each digest carries the previous digest's signature. AWS says this makes it "computationally infeasible to modify, delete or forge CloudTrail log files without detection."

A chain has limits. It detects edits inside the chain. It doesn't stop someone deleting the whole chain or its newest entries. Close those gaps:

• Sign the latest hash periodically and store it in a separate system with different administrators.
• Write entries to storage with retention locks, so they can't be overwritten.
• Number entries in sequence and report delivery gaps instead of hiding them.
• Log every access to the trail itself, as OWASP recommends.

Keep the authoritative copy in a cloud account you control, next to your services. A vendor's console is a useful view. Your evidence shouldn't depend on a vendor's retention settings, uptime or continued existence. Keeping it in your account also keeps sensitive metadata inside your boundary.

Mapping the AI agent audit trail to compliance frameworks

No framework prescribes a receipt format for agents. Several ask for evidence that an agent audit trail supplies. For AI agent compliance work, as of October 2026:

Read the EU rows carefully. The logging duties apply to high-risk AI systems, and whether an agent is high-risk depends on its use case, so check with counsel. Timing has also moved. The AI Omnibus was published in the Official Journal on 24 July 2026. According to the Future of Privacy Forum, it moves obligations for Annex III high-risk systems to 2 December 2027 and for Annex I systems to 2 August 2028. Article 19 also defers to EU data protection law, which can limit what you keep.

Sending agent receipts to a SIEM with OCSF

Your security team will want agent records in its security information and event management (SIEM) system, next to everything else. A shared schema saves mapping work. The Open Cybersecurity Schema Framework (OCSF) is an open-source schema for security events, built from categories, event classes and a shared attribute dictionary.

A tool call fits OCSF's API Activity class in the Application Activity category. As of October 2026, the schema's development branch (1.10.0-dev) also includes an AI Operation profile, with attributes for the agent (ai_agent), the model and the delegation the operation ran under. Check which schema version your SIEM supports before relying on it. One reasonable mapping:

Validate the mapping with a few real events before you build detections on it. Field names in a development branch can still change.

AI agent audit trail checklist

• Record every decision at the enforcement point, including allows, holds and denials.
• Write the agent, its owner and the person it acts for into every entry.
• Version your policies, and record the version on each decision.
• Record approvals with the approver, the exact call approved and the number of uses.
• Leave secrets, tokens and sensitive values out; record data types and actions instead.
• Chain entries with hashes, and sign or anchor the latest hash outside the chain.
• Keep the authoritative copy in an account you control, with retention locks.
• Report delivery gaps and log every read of the trail.
• Map entries to a schema your SIEM understands, and test detections on real events.
• Set retention per regulation and data class, and review it each year.

How AgentFort handles this

AgentFort keeps a receipt for every request: the agent's identity, the owner's grant, the policy and the outcome. Allowed and denied activity are both recorded and can be filtered. Data protection receipts say what was found, where, what was done and how long it took, never the values. Receipts are chained, so a missing or edited entry shows. They are kept on the customer's side and reconciled to the console, with delivery gaps reported. When an agent is refused, it gets a short reason and a receipt number, never the rule's details. See AgentFort Access, or request a demo.