Why Every AI Agent Action Needs an Audit Log

An AI agent audit log is a record of every action an agent took in your tools: which tool it called, under whose authority, when, whether it succeeded, and which record it touched. It does not store the contents of what was read or written. Without it, nobody can answer "who moved that deal?" or "why is this issue closed?" when the answer is "the agent did", and that is the moment trust in the agent collapses.

This post is about the operational side, not the model side. We run a company of a dozen people on tools where an agent can create issues, move deals and post updates, and we got the logging wrong once before we got it right. What follows is the design we use now, the standards that back it, and a checklist you can apply to any agent you connect.

What an agent action actually is

A human clicking "close issue" is one action by one person. An agent closing an issue is a chain: a person (or a schedule) started an agent run, the run called a tool, the tool checked a scope, the scope was tied to a token, the token was tied to a person, and only then did the issue change state. Any of those links can be the one that went wrong.

That is why "the agent did it" is not an answer. The question an audit log has to answer is: which run, on whose token, called which tool, against which record, with what result. If any of those five is missing, the log is a comfort, not a control.

Why a plain application log is not enough

Most products already log something. Web servers log requests. Databases log changes. Chat tools keep message history. The temptation is to say the agent's actions are "in there somewhere". Three things make that fail in practice:

Attribution is lost at the boundary. A request from an agent usually arrives as a request from the integration user or from the person whose token the agent carries. The application log shows "Moeid closed issue 412". It does not show that Moeid was at lunch and a run started by a nightly schedule did it.
Reads are invisible. Application logs record writes. An agent that read every deal's value and then summarised them into a chat message left no trace of the read, and the leak is in the summary, not the database.
Logs are not reviewable. A log that mixes agent actions with ten thousand lines of request noise is not something a founder opens on a Friday to check what the agent did this week. If nobody reads it, it is not oversight.

Anthropic's guidance on building agents puts it plainly: prioritise transparency by explicitly showing the agent's planning steps, pause for human feedback at checkpoints, and include stopping conditions such as a maximum number of iterations. An audit log is how that transparency survives after the run has finished and the chat window is closed.

What the standards ask for

Three documents are worth knowing, because they define what "enough" looks like and because your customers' procurement teams will quote them at you.

OWASP Top 10 for Agentic Applications (2026). Published 9 December 2025 by the OWASP GenAI Security Project, with more than 100 contributors. Insufficient logging is one of the ten named risks, alongside excessive agency, tool misuse and memory poisoning. Secondary write-ups disagree on the numbering of the categories, so cite it by name, not by ID.
EU AI Act, Article 12. "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Logging must support traceability "appropriate to the intended purpose": identifying situations that may present a risk, post-market monitoring, and monitoring of operation. It applies from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I. A small team's issue tracker is not a high-risk system, but the wording is a good definition of what a log is for.
Anthropic, "Building effective agents" (December 2024). Not a standard, but the most-cited practitioner guidance: transparency of planning steps, human checkpoints, sandboxed testing with guardrails. Written before most of today's tooling existed, and still correct.

The common thread: the log has to be automatic (not a manual write-up after the fact), continuous (every action, not a sample) and purpose-fit (enough to reconstruct what happened, not a copy of everything).

The five fields, and the one thing to leave out

This is the record we keep for every call an agent makes, and we would argue it is the minimum for any team:

Field	Example	Why it is there
Tool	`crm_move_deal`	Which capability was used, named the way the agent sees it
Actor	token `atx_…c41`, owned by a named person	Whose authority the call ran under; the token, and the person behind it
Subject	`deal`, id `d_8f2…`	What was touched: the kind and the id, so a reviewer can open it
Outcome	`ok`, `refused: scope`, `error: 429`	Succeeded, refused by the permission layer, or failed
Time	`2026-10-27T09:14:02Z`	When, to the second, in one time zone

And the thing to leave out: the contents. Not the deal value, not the issue body, not the message text. Two reasons. First, the log must be safe to show to anyone who is allowed to see the log; if it holds the contents, it inherits the permissions of everything it logs, and you end up unable to show it to the person who most needs it. Second, the content already lives in the record. The subject id points at it; the record's own version history shows what changed.

A log that holds tool, actor, subject, outcome and time can answer every question in this post. A log that also holds contents is a second copy of your database with weaker access control.

Reads matter as much as writes

The reflex is to log only writes, because writes are what break things. Agents change that calculation. An agent with read access to the CRM can be asked, in a chat window by anyone with access to the agent, to list every deal and its value. The CRM's own permission system was built on the assumption that reading deal values needs a specific permission; if the agent's token has it and the person asking does not, the log of that read is the only evidence of the leak.

Our rule: log reads at the same granularity as writes, but keep the outcome field honest. A refused read ("refused: crm.value.view") is more useful to a reviewer than a thousand successful ones, because it shows the permission layer working and shows who was probing.

Rate limits are part of the audit story

A log tells you what happened. A limit stops the wrong thing from happening ten thousand times before anyone reads the log. The two belong together. A per-token limit on calls and a tighter one on writes means a looping agent or a stolen token does bounded damage, and the log shows the 429s as a spike a human can see.

In Atrix, every MCP token is limited to 120 calls and 30 writes per minute. That is low on purpose: an agent helping a person through a day's work never gets near it, and a loop hits it inside ten seconds.

How Atrix logs agent actions

Atrix AI exposes its workspace to agents through an MCP server with 85 tools behind OAuth 2.1. Every call is audited with exactly the five fields above: tool, outcome, subject kind and id, and the token and person behind it. Contents are never written to the audit log. The same applies to calls through the REST API, documented at /developers.

Three design choices do most of the work:

Scopes are narrow and never widen. A token is granted specific scopes (49 are grantable as of October 2026). A write scope implies its read; nothing else is implied. Nine scopes also require the matching permission on the person's own account, so a token can never reach more than the person who created it, and permissions are checked on every call. Revoke a person's access and every token they created loses reach at that moment.
Writes that notify people are gated. Posting an update to the feed is its own named scope, never implied by a general write scope, because it sends notifications to everyone's phone. An agent cannot inherit that by accident.
The log is the person's, not the agent's. The audit entry names the token and the person who created it. "The agent did it" resolves to a named teammate, who is accountable for what they let the agent do.

The limits, stated plainly: this is an audit of calls made through MCP and the API. Atrix does not scan code, does not run static analysis, and the agent's "requirements audit" is a coverage check against a frozen baseline, not a security tool. The audit log answers who did what in the workspace; it does not evaluate whether the agent's reasoning was sound.

Setting up oversight for a small team

You do not need a security team to do this. You need five fields, one weekly habit, and a rule about who gets to connect an agent.

Make one person own each agent connection. No shared integration users. If a token is created, it is created by a named person on their own account, so the permissions it carries are theirs and the log names them.
Grant read first. Connect the agent with read scopes only for a week. Read the log. Then add the single write scope the agent actually needs.
Read the log weekly, filtered to writes and refusals. Twenty minutes on a Friday. You are looking for two things: writes you did not expect, and refusals that show someone asked for more than they should have.
Keep notifying writes on a human trigger. Anything that posts to the whole team, emails a customer or moves money should be a scope a human grants explicitly and reviews separately.
Set the rate limit below what a human could do by hand. If a person could not make 30 changes in a minute, an agent should not be allowed to either.
Decide retention before you need it. Ninety days of audit entries covers nearly every "what happened last month" question. Longer is fine if the log holds no contents, which is one more reason not to put contents in it.

Agent logging compared across approaches

Approach	Attribution	Reads logged	Contents in log	Reviewable by a founder
Application/server logs only	Lost at the integration boundary	No	Often (request bodies)	No, too noisy
Chat transcript of the agent	The chat user, not the token	Only what the model said it did	Yes, everything	Readable but unreliable; the model's account of itself
Per-call audit log (five fields)	Token and named person	Yes	No	Yes, filter to writes and refusals
Full event sourcing of every change	Depends on the write path	Not usually	Yes, by design	Needs tooling

The chat transcript deserves a note. It is tempting to treat the agent's own summary ("I moved three deals to Won") as the record. It is a statement by the party under examination. The audit log is the independent one.

FAQ

What should an AI agent audit log contain?

At minimum: the tool called, the token and the person it belongs to, the subject kind and id, the outcome (ok, refused, error) and the time. Leave the contents out; the subject id points at the record, and the record's own history holds the change.

Should agent reads be logged, or only writes?

Both. An agent can leak data through a read it then summarises in chat, and the read is the only evidence. Log reads at the same granularity as writes and pay particular attention to refused reads.

Is an AI agent audit log required by law?

For most small teams, no. The EU AI Act's Article 12 requires automatic event logging for high-risk AI systems, from 2 December 2027 for Annex III systems. An issue tracker or CRM agent is not high-risk. The OWASP Top 10 for Agentic Applications (2026) lists insufficient logging as a named risk, which is guidance, not law, but it is what procurement questionnaires will cite.

How is an audit log different from the agent's chat history?

The chat history is the agent's account of what it did, written by the agent. The audit log is written by the system the agent acted on, at the moment of the action, naming the token and the person. When the two disagree, the audit log is right.

Does Atrix log the contents of what an agent reads or writes?

No. Atrix records the tool, outcome, subject kind and id, and the token and person behind every MCP and API call. Contents are never written to the audit log. Changes to a record are visible in that record's own version history.

How long should agent audit entries be kept?

Ninety days answers almost every practical question. Because a well-designed entry holds no contents, keeping it longer carries little risk; what matters more is that someone reads it every week.

Next step

If you are connecting an agent to your work for the first time, start with read scopes, one named owner, and a weekly look at the log. The Atrix AI agent runs inside those same limits, and the MCP documentation lists every scope and what it implies, so you can decide what to grant before you grant it.

Sources

Checked in October 2026: OWASP Top 10 for Agentic Applications for 2026, EU AI Act, Article 12: Record-keeping, Anthropic, Building effective agents.

Why every AI agent action needs an audit log, and what to put in it