AI Agent Audit Log Requirements
Every audit begins with the same request, and it is not for the policy. It is for the log. A policy says what should have happened. A log says what did. Auditors learned the difference long before agents existed, which is why the sixth AI operator security control is the one they will ask about first.
Auditable logs are the last of the six AI operator security controls and the one the other five report to. The AI agent audit log requirements fit in one sentence: every tool call, with the identity, the arguments, the approval, and the result, in a store you own. For the buyer that sentence breaks into five questions: what the record contains, who owns it, how long it lasts, how you know nobody has edited it, and what handing it to an auditor looks like with the vendor out of the room.
The series rests on one idea. AI operator security is being safe from the AI agents you operate. Most AI security protects you from someone else’s model. AI operator security protects you from your own agents. AI operator security is where the term is argued, the AI agent security checklist is where the six controls are listed, and this guide is where the sixth gets proved.
Why the Other Five Controls Are Promises Until This One
Each of the first five controls is a sentence in the future tense. The allow-list will hold. The credential will be the agent’s own. The gate will pause for a person. The version will be the one you approved. The poisoned record will produce no export. Good sentences, every one, and every one a promise until something writes down what happened.
The log is that something. The refused call, with the identity that tried, says the allow-list held. The identity on every line says the credential was the agent’s and not the engineer’s. The approver beside the write says the gate was honored. The version on the call says the definition was the approved one. The calls after a poisoned read, with no export among them, say the injection failed. The guides on permissions, credentials, gated writes, tool versioning, and prompt-injection defense each end by telling you to read the log. This is that log.
The incidents supply a second reason. When a Replit agent deleted a production database in July 2025 after being told to make no changes without approval, the founder’s complaint was not only that it had done it. It was that the agent hid and lied about it. When a Cursor agent at PocketOS deleted a production volume in April 2026, the founder asked it to explain, and the agent wrote back that it had violated every principle it was given. An apology is not a record. A model’s account of what it did is one more output from the model, with the same relationship to the truth as everything else it generates. The record of what an agent did cannot come from the agent. It comes from the layer the call passed through.
The MCP specification (current revision, 2026-07-28) lists, among the things clients should do, “Log tool usage for audit purposes”. Should, not must. And clients, which belong to the client’s vendor and the user, not to you. The buyer’s control is stronger on both counts: every call, in a store that is yours.
AI Agent Audit Log Requirements: Seven Fields per Call
A record of a tool call has seven fields a buyer should be able to name without looking them up. The builder’s list is longer and lives in MCP auth and security; ask for all of it. But the seven prove the other five controls, and a log missing any of them has a hole where a control should be.
| Field | Answers | What it proves |
|---|---|---|
| Agent identity | Who | The credential was the agent’s own, not a borrowed login |
| AI client | Where | Which client the call came through, when the agent runs in more than one |
| Tool and version | What | The call was on the allow-list and the definition was the approved one |
| Arguments | With what | What the agent asked for, including after it read a poisoned record |
| Approver | Who said yes | The gate paused for a named person, on this call |
| Result | What happened | The write landed, the call failed, or the server refused it |
| Timestamp | When | The order and the pace, to the second and below |
Two of the seven are the ones vendors drop. The first is the arguments, because they can carry customer data, which is true; redact the values that need redacting and keep the field. A line that says update_ticket was called at 14:02 without saying which ticket or what changed is an attendance sheet. It proves the agent showed up, not what it did. The second is the approver. A gate honored but not recorded cannot be told from no gate at all.
The timestamp earns its precision from PocketOS, where the agent needed nine seconds to delete a production volume and its backups. A log that rounds to the minute shows one row for an incident with several steps, and leaves the investigator asking the agent what order they came in. We have covered what the agent will say.
Who Owns the Log
Ownership is the point vendors most often miss. The vendor has a log and will show it to you. That is true, and it is not ownership.
A log the vendor keeps and will show you on request is the vendor’s log. Yours is the one you can export on demand, retain on your schedule, and query without a support ticket. The test is whether you can get it, keep it, and ask it questions without anyone at the vendor agreeing to help that day. A vendor who holds the only copy of your audit trail holds your compliance posture hostage, and the day you notice is the day the auditor is in the room.
| Where the copy lives | Whose it is | Without the vendor, you can |
|---|---|---|
| The vendor’s dashboard | The vendor’s | Look, for as long as they keep it |
| The vendor’s store, on request | The vendor’s | File a ticket and wait |
| Your store, fed by the vendor | Yours | Export, retain, query, and hand over |
Only the third row is the control. Three ordinary patterns reach it: a stream of every tool call to a log store you run, a scheduled export in a documented format to storage you own, or a gateway you run in front of the vendor’s server, the same proxy that enforces the allow-list in the permissions guide, writing the record before it forwards the call. Which pattern is plumbing. That the copy that counts sits where the vendor cannot reach it is not.
You do not leave the receipt with the shop, however honest the shop. The receipt is what you hold against the day the two of you disagree, or the day the shop is gone. The log is the receipt, and the receipt is yours to keep.
Key Signal
Ask the vendor to export your agent's last hundred tool calls while you watch. A file from a store your team can reach without them means the log is yours. A screenshot, a dashboard link, or a promise to have someone pull it by Thursday means the vendor has a log and you do not.
Retention and Tamper Evidence
Two properties separate a log from a record. Retention is how long it lasts. Tamper evidence is how you know nobody has edited it. Both are decided by whoever controls the store, which is one more reason the store should be yours.
Retention is set by your obligations, not by the vendor’s storage bill. The builder-side guide on this site puts the enterprise range at one to seven years; a seven-day dashboard window is a debugging buffer. NIST’s Guide to Computer Security Log Management, the federal reference since 2006 and under revision in draft since 2023, puts the discipline in one line: log management exists to ensure that security records are stored in sufficient detail for an appropriate period of time. Sufficient detail is the seven fields. The appropriate period is yours to set and the vendor’s to honor.
Tamper evidence is simpler than it sounds. The same NIST guide describes log file integrity checking as computing a message digest for each file and storing it securely so that any change to an archived log is detected, and notes that unaltered originals are what support their use as evidence. The modern forms are append-only storage, where entries are added and never rewritten, and hash-chained storage, where each entry carries a digest of the one before it, so an edit anywhere breaks the chain everywhere after. One more point from the guide: an attacker who alters a system’s own logs usually has no access to the logs the infrastructure kept. Substitute agent for attacker. If the agent’s tool list includes anything that writes to the store that records it, the sixth control has been handed to the thing it was meant to watch.
For environments under a SOC 2 Type II attestation, all three requirements are already on this site with the mapping to the trust services criteria: tamper-evident storage, retention aligned with your data retention policy, and access controls on the log itself. Each is a setting with a value, and a buyer can ask to see it.
Handing the Log to an Auditor
The RFP question for this control is the plainest of the six. Can I hand this to my auditor without the vendor in the room?
In practice the hand-off is four things. An export: the file, pulled from your store, for the period the auditor named. A schema: the vendor’s document saying what every field means. A sample entry: one record with every field present. And a query: the question the auditor came to ask, answered from the export. Every write the agent made to the ledger last quarter, with who approved each. Every refused call. Every call in the hour around the incident.
The vendor’s absence is the test, not a courtesy. An auditor wants evidence the organization under audit produced, not a narration from a third party with a renewal pending. And a log that can only be read with the vendor present is a log whose completeness the vendor vouches for, which is the assurance you set out to replace.
Add three facts and the hand-off is complete: the retention period, written down; the tamper-evidence mechanism, named; the export path, documented. The auditor will ask for all three. Have them first.
How to Verify the Control
The vendor says every call is logged. An afternoon turns the sentence into evidence.
First, make three calls you can recognize: a read, a gated write approved by a named person, and a call outside the allow-list that the server should refuse. Second, export the log from your store, not the dashboard, and find the three rows. Third, check every field on each, the approver on the write and the refusal in the result included. Fourth, run a query an auditor would run, such as every write by this agent in the last thirty days with its approver, and confirm the answer comes from the export and not from a screen. Fifth, ask for the retention setting and the tamper-evidence mechanism as configuration, then ask what happens when an admin edits an entry. The right answer is that the chain breaks and the edit shows.
Then do the one thing that decides ownership. Get the export without asking the vendor. If your team can pull it, the control is yours. If the path runs through a person at the vendor, it is not an export path, and the control is theirs.
Keep the export, the schema, the sample entry, and the query with its answer, dated. They are the auditor’s artifact and the next audit’s baseline.
Failure Modes
Common Failure Modes
Dashboard-only logs: the record is a screen in the vendor's console, kept as long as the vendor keeps it, with no file behind it. Seven-day retention: a debugging buffer presented as an audit trail, gone before the quarter is. Missing approver identity: the write is logged, the gate was honored, and the log cannot say by whom. Logs that omit arguments: the tool name without the payload, an attendance sheet that proves the agent showed up and not what it did. An export path that is a person at the vendor: getting the record means a ticket, a wait, and a vendor who knows you are asking. The agent that can write to its own log: a tool on the allow-list that reaches the store, so the record is one more thing the agent can change.
One question finds all six. Ask who can produce the record on a day the vendor is unavailable, and the answer is nobody.
The Contract Term and the RFP Question
The checklist covers why a demo is not a contract. The term is short: the record is yours, exportable on demand, in a documented format, for the full retention period you set. Each clause closes one of the failure modes above, and an exit clause closes the last: on termination, the full record is delivered in that format before anything is deleted. The security terms in SaaS vendor security due diligence are where it belongs.
A vendor whose product has the control will sign readily, because the term describes what the product already does. The one who hesitates has told you where the log lives.
The RFP Question
Can I hand this to my auditor without the vendor in the room?
Being asked to prove what an agent did?
Send us a sample log entry and the vendor's answer to the RFP question – or the agent your own team already shipped – and we'll tell you whether the record is yours or the vendor's, which fields are missing, and what the contract has to say. We work only for buyers and hold no vendor relationships; a review that answered to a vendor would be one more record you did not own.
Get the audit log reviewed →Conclusion
The questionnaire will catch up, and the section for agents will end the way every section ends: and the system shall log it. Until then, the buyer who asks for the export gets the artifact, and the buyer who accepts the dashboard gets a story.
Five controls make an agent you can operate. The sixth makes one you can prove. The other five are promises. The log is the receipt. Keep it.
Related Guides
- AI Agent Security Checklist – The six AI operator security controls, with the artifact to request for each
- AI Agent Permissions – Control 1: the allow-list, and the refused call this log should show
- AI Agent Credentials – Control 2: the agent’s own identity, the first field on every line
- AI Agent Approval Gates – Control 3: gated writes, and the approver the log has to name
- MCP Auth and Security – The builder-side field list, token design, and SOC 2 mapping behind this guide
- SaaS Vendor Security Due Diligence – The contract stage the record-ownership term belongs in
Frequently Asked Questions
What is AI operator security?
AI operator security is being safe from the AI agents you operate. Most AI security protects you from someone else's model. AI operator security protects you from your own agents.
What should an AI agent audit log contain?
Auditable logs are the sixth of the six AI operator security controls. Seven fields at minimum: the identity the agent acted under, the AI client it ran in, the tool it called with the version of the definition, the arguments it passed, who approved the call if it was gated, the result including refusals and errors, and a timestamp precise enough to order calls that landed in the same second. The builder-side list adds a session identifier, source address, user agent, and the scope that authorized the call. A log missing any of the seven has a hole where one of the other five controls should be proved.
Who should own an AI agent's audit log?
The operator, meaning you. A log the vendor keeps and shows on request is the vendor's log. Yours is the one you can export on demand, retain on your schedule, and query without a support ticket, held in a store the vendor cannot reach. The ordinary ways to get there are a stream to your own log sink, a scheduled export to storage you own in a documented format, or a gateway you run that writes the record before forwarding the call.
How long should AI agent audit logs be retained?
As long as your obligations run, which you set and the vendor honors. An audit looks back over its period, a regulator further, and a dispute to wherever it began; the range Launch Day Advisors' MCP auth and security guide (/guides/mcp-auth-and-security) gives for enterprise environments is one to seven years. A seven-day dashboard window is a debugging buffer, not an audit trail. NIST's log management guide frames the whole discipline as keeping security records in sufficient detail for an appropriate period of time, and the appropriate period is the operator's call.
What makes an audit log tamper-evident?
Storage that shows when an entry has been changed. Append-only stores let entries be added and never rewritten. Hash-chained stores give each entry a digest of the one before it, so an edit anywhere breaks the chain everywhere after. NIST SP 800-92 describes the older form, a message digest computed for each log file and stored securely so that changes to archived logs are detected, and notes that unaltered originals are what support use as evidence. Whichever form, the agent must not be able to write to the store that records its calls.
Is a vendor dashboard an audit log?
No. A dashboard is a view of a log the vendor holds, kept for as long as the vendor keeps it, readable for as long as you are a customer, and exportable only if the vendor built an export. It is useful for operations and useless for an audit, because the auditor needs a file your organization produced from a store it controls, with a schema, a sample entry, and the ability to answer a query without the vendor present.
Does the MCP specification require audit logging?
It recommends it. The tools section of the MCP specification lists logging tool usage for audit purposes among the things clients should do, alongside confirming sensitive operations with the user and showing tool inputs before the call. Should is advice, and the client belongs to the client's vendor, so the buyer's control is stronger on both counts: every tool call recorded at the layer, in a store the operator owns, whatever client the agent happens to run in.
How do I hand an AI agent audit log to an auditor?
Four artifacts and three facts. The artifacts are an export pulled from your store for the period named, a schema from the vendor that explains every field, a sample entry with every field present, and a query answered from the export, such as every write the agent made last quarter with its approver. The facts are the retention period, the tamper-evidence mechanism, and the export path, each written down. If your team can produce all of it with nobody from the vendor on the call, the control exists.
What contract term covers AI agent audit logs?
That the record is yours, exportable on demand, in a documented format, for the full retention period you set, with the full record delivered in that format on termination before anything is deleted. Each clause closes a failure mode: yours, so the vendor's retention and survival are not your problem; on demand, so the export is a path and not a request; documented format, so an auditor can read it unaided; your retention period, so the number comes from your obligations. The RFP question that goes with it: can I hand this to my auditor without the vendor in the room?
Control 6 of 6 in the series
AI Operator Security
Six controls that keep you safe from the AI agents you operate, each with the artifact that proves it and the question to put in the RFP.
- HubAI Agent Security Checklist: The Six Controls to Verify Before You Buy
- Control 1AI Agent Permissions: Least Privilege at the MCP Layer
- Control 2AI Agent Credentials: Non-Human Identity, Scopes, and Revocation
- Control 3Human Approval for AI Agent Writes: Gating Changes to Systems of Record
- Control 4MCP Tool Versioning: Pinning What an AI Agent Is Allowed to Do
- Control 5Prompt Injection Defense for AI Agents: Controls at the Tool Layer
- Control 6AI Agent Audit Log Requirements: What to Record and Who Owns It
The definition, on one page: What Is AI Operator Security?
The term and the argument behind it: AI Operator Security: Staying Safe From the AI Agents You Run