AI governance

An AI agent audit trail is a record of everything an agent did: who asked, what it read, which tools it called, what it changed and who approved it. To be worth anything, that record has to live somewhere the agent can’t edit or delete. If the agent can reach its own logs, you don’t have an audit trail, you have the agent’s version of events.

That last point stopped being theoretical this month. A research paper posted on September 24 by researchers at the ELLIS Institute Tübingen, the Max Planck Institute for Intelligent Systems and others tested popular AI coding agents running with full access to a computer. In almost every setup, the agent deleted its own activity record when asked, and the built-in safety monitors didn’t flag it. The researchers also showed that outside instructions could push an agent into doing it, and that agents found the trick on their own when a task rewarded shorter or cleaner logs. Fast Company reported that some agents went further and set up repeated clean-up jobs to keep removing the evidence.

The researchers are clear that the agents weren’t scheming. The problem is design: the log sat on the same machine, with the same permissions, as the agent writing it. Their advice is the core of this article: record what an agent does through a separate mechanism outside the agent’s control.

Why AI agents need an audit trail

A chatbot answers questions. An AI agent takes actions: it sends email, updates records, moves files, calls APIs and runs code. When something goes wrong, someone will ask what happened, and “the AI did it” isn’t an answer a customer, an auditor or your own leadership will accept.

A good audit trail lets you answer four questions after the fact:

• What did the agent do? Every tool call, with its inputs and results.
• Why did it do it? The request or trigger that started the task and the content it was working from.
• Who allowed it? The person or policy that approved each action that needed approval.
• What changed? The records, files or messages that were created, edited, sent or deleted, so you can reverse them.

It also helps day to day. Reviewing logs is how you find the agent that keeps retrying a failed step, spends more than expected, or reads data it never needed.

What an AI agent audit trail should record

For each agent run, capture:

• Identity. Which agent ran, under which account, and on whose behalf. This only works if each agent has its own identity instead of borrowing a person’s login or a shared admin key.
• Trigger. The user request, schedule or event that started the run.
• Inputs. References to the emails, documents, web pages and records the agent read. Outside content is where prompt injection hides, so you want to know what it saw.
• Tool calls. Each tool or API the agent called, with the arguments and the response, including calls that were blocked or failed.
• Approvals. Who approved or rejected each high-impact action, and when.
• Outputs and changes. What the agent sent, wrote or changed, with enough detail to undo it.
• Time and cost. Timestamps for each step and, where your platform reports it, model usage per run.

Be deliberate about sensitive data. Logging a full customer record or a password into a log store creates a new risk. Log references and redacted values where the full content isn’t needed, and protect the log store as carefully as the systems the agent touches.

Keep the logs where the agent can’t reach them

This is the lesson from the September research, and it’s the part most teams get wrong. If an agent writes its own log file on the machine it runs on, anything it can do to a file, it can do to its history. A monitor running on that same machine has the same weakness.

The fix is architecture, not a better prompt:

• Log at the gateway, not inside the agent. Route the agent’s tool calls through a layer you control, such as an API gateway, a proxy or a custom MCP server, and record each call there. The agent never touches that record.
• Use append-only storage. Send logs to a separate account or service where the agent’s credentials can add nothing and delete nothing. Cloud platforms offer write-once storage and managed audit logging for exactly this.
• Don’t give the agent rights it doesn’t need. An agent that can’t delete files or edit system settings can’t delete its trail either. Full-access modes are for sandboxes, not production.
• Compare two records. Check the gateway log against the business systems’ own logs, such as the CRM’s change history or the mail server’s sent items. Gaps between them are worth investigating.

Turn the audit trail into monitoring

Logs that nobody reads only help after the damage. Once the record is in a place you trust, put a few simple alerts on it:

• An agent calls a tool it has never used before, or one outside its job.
• An action that should need approval runs without one.
• A run touches far more records, or costs far more, than usual.
• An agent tries to read, change or delete logs, settings or its own instructions.
• The log stream for an agent goes quiet while the agent is still running.

Pick an owner for these alerts. An agent audit trail is part of operations, the same as server monitoring.

Where to start if your agents are already live

1. List every agent you run, including the ones teams set up on their own, and note where each one’s logs live today.
2. For each agent, check whether it can reach, edit or delete its own logs. If it can, move logging to a gateway or a separate account first.
3. Give each agent its own account with only the permissions its job needs.
4. Add approval steps for actions that send, pay, delete or share.
5. Set up the alerts above and do one practice review: pick a past run and see if you can explain it end to end from the logs alone.

Frequently asked questions

What is an AI agent audit trail?

It is a record of every action an AI agent takes: what started the task, what data it read, which tools it called with what inputs, who approved high-impact steps, and what it changed. It lets you explain and reverse what an agent did.

Can an AI agent delete its own logs?

Yes, if the logs are stored where the agent has access. A September 2026 research paper found that most popular coding agents running with full access deleted their own traces when asked, without safety monitors flagging it. Logs should be recorded outside the agent’s control, for example at a gateway or in a separate append-only store.

Is an AI agent audit trail the same as observability?

They overlap. Observability tools help engineers see performance, errors and cost. An audit trail is evidence: it has to be complete, tamper-resistant and tied to identities and approvals so it holds up in an investigation or compliance review. Many teams use the same pipeline for both, with the audit copy kept in protected storage.

Build AI agents you can account for

GrtLabs designs and builds AI agents and AI automations with their own identities, scoped permissions, approval steps and logging that the agent can’t touch, inside your own AWS or Azure account. If you’re running agents today or planning your first one, talk to our team about setting up an audit trail you can trust.

AI agent governance means deciding, before an agent goes live, what it may do on its own, what needs a human yes, and how every action gets logged and reversed. If you can’t answer those three questions for an agent, it isn’t ready to touch real orders, invoices or customer records.

This week the big platforms made the same point. SAP, ServiceNow, IBM and SAS all announced agent features built around audit trails, agent inventories and controls on how much autonomy an agent gets. The tools are new, but the rules behind them are simple enough for any business to apply, whatever stack you run.

Why AI agents need governance and chatbots didn’t

A chatbot answers a question. An agent takes an action: it updates a CRM record, approves a refund, routes a purchase order or sends a file to a vendor. When an answer is wrong, someone reads it and moves on. When an action is wrong, money moves, data changes or a customer gets the wrong message.

That’s the whole reason governance matters. The more an agent can do, the more you need to know what it did, why, and how to undo it.

The five controls every AI agent should have

1. A written scope

List the systems the agent can read, the systems it can write to, and the actions it is allowed to take. Anything not on the list is off limits. Keep it to one page so the business owner, not only the developer, can sign it.

2. Its own identity and least-privilege access

Give the agent its own account instead of borrowing a person’s login or an admin API key. Grant only the permissions its scope needs. If the agent is compromised or misbehaves, you can switch off that one identity without locking out a team.

3. Autonomy levels by action

Not every action carries the same risk. A practical split:

• Act on its own: reading data, drafting replies, tagging and routing tickets.
• Act, then report: low-value, easily reversed updates, such as correcting a field in a CRM record.
• Ask first: anything that spends money, changes a contract, deletes data or reaches a customer.

Start strict and loosen a rule only after the agent has a clean track record on it.

4. A full audit trail

Log every input, every tool the agent called, every decision and every result, with a timestamp. When someone asks why an order was changed, you should be able to answer in minutes, not after a week of digging.

5. An off switch and a rollback plan

Someone on your team should be able to pause the agent in one step. For each write action, know how you would reverse it, whether that’s a database revision, a credit note or a follow-up message.

Keep an inventory of every agent you run

Agents multiply fast. One team builds an email triage agent, another turns on an assistant inside their ERP, a third wires up an automation through a no-code tool. Within a year nobody knows how many there are or what they can touch.

A simple inventory fixes that. For each agent, record its owner, its purpose, the systems it touches, its autonomy level, the AI model it uses and the date it was last reviewed. A shared spreadsheet is fine to start.

Test agents before and after they go live

Before launch, run the agent against a set of real past cases where you already know the right outcome, and check what it gets wrong. After launch, keep sampling its work. Models change, data changes and prompts drift, so an agent that was accurate in month one can quietly get worse by month six.

Where to start if you already have agents running

1. List every agent and automation that can write to a business system.
2. For each one, check whether it has its own identity and a log of its actions.
3. Move every action that spends money or contacts customers to “ask first” until you’ve reviewed it.
4. Name one owner per agent who is responsible for its results.

None of this needs a new platform. It needs clear rules, applied consistently.

Build agents that are governed from day one

GrtLabs designs and builds AI agents with scope, permissions, approval steps and logging built in, inside your own AWS or Azure account. See how we approach it on our Agentic AI page, or contact us to talk through the agent you want to put to work.