AI agent audit trails: how to prove what an agent did on a system you manage

Last updated: 6 July 2026

TL;DR: An AI agent audit trail is the record of what an agent did on a system: which agent, what action, when, on what, and on whose authority. If the agent uses a shared human login, that record does not exist, and you cannot prove what it touched. This is how to build one that stands up.

There are, by CyberArk's 2025 count, 82 machine identities for every human in the average organisation [1], and the fastest-growing kind is the AI agent that does not only read a system but acts on it. We have written about how to grant that access safely, in a form you can scope and revoke, in letting an AI agent onto your servers. This article is about the other half of the job, the half most teams skip: proving, afterwards, exactly what the agent did.

Sooner or later, someone asks. A client whose servers you manage, an auditor, or your own board: what did your AI touch on this system, and can you show me. If the honest answer is that you are not completely sure, the access was never really under control, however careful the original grant looked. The record is the deliverable. This piece sits under securing software you built, inherited or self-host; here we go deep on one part of it, the agent audit trail.

Why "what did the agent do" is usually unanswerable

The common setup is to let the agent authenticate as a person: a shared secure shell (SSH) key, an admin token, or a database login that already belongs to an engineer. It works on the first try, which is exactly why it is dangerous, because it destroys attribution on the first incident. Every action the agent takes is recorded, if it is recorded at all, as that person's activity. Afterwards you cannot separate what the human did from what the agent did, and you cannot prove either.

OWASP, the Open Worldwide Application Security Project, ranks this failure in its own right: without logging and monitoring, breaches cannot be detected [2], let alone reconstructed. A log that exists is not automatically a log you can trust, either. NIST, the United States National Institute of Standards and Technology, warns in its Guide to Computer Security Log Management that logs "secured improperly in storage or in transit might also be susceptible to intentional and unintentional alteration and destruction", which can end in "manipulating evidence to conceal the identity of a malicious party" [3]. A shared credential and an editable log are the two ends of the same gap: you cannot say who acted, and you cannot trust the record of the action.

Treat the agent as its own identity

The root cause is a category error. An agent is not a person, and it is not the traditional service account either, yet most organisations govern it as an afterthought to both. OWASP maintains a dedicated Non-Human Identities Top 10 precisely because these machine actors "are commonly granted very broad access" and "are notoriously under-monitored, allowing malicious activity to go unnoticed" [4]. An agent handed a person's credential simply inherits that person's blind spot.

The fix is to make the agent a first-class identity, with its own credentials and its own record, so that its actions are attributable to it and to nothing else. This is the property NIST calls non-repudiation. Control AU-10 in NIST Special Publication 800-53 asks a system to "provide irrefutable evidence that an individual (or process acting on behalf of an individual) has performed" a given action [5]. That parenthetical, "process acting on behalf of an individual", is the AI agent: it acts for a principal, and the record must tie each action to the agent and, through the agent, to the human or service that set it running.

What an agent audit trail must capture

A useful test for an audit trail is whether it can answer, for any single action, six questions without guesswork:

Question	What the record must hold
Which actor?	the agent's own identity, distinct from any human
What action?	the specific operation, not a vague "task run"
When?	a trustworthy timestamp
On what?	the exact target system, resource or record
On whose authority?	the human or service it acted for, and the grant it used
With what result?	success or failure, and what changed

OWASP's guidance for over-empowered agents points the same way. Its mitigations for Excessive Agency are to "log and monitor the activity of LLM extensions and downstream systems to identify where undesirable actions are taking place", and to "require a human to approve high-impact actions before they are taken" [6]. The approval and the action belong in the same record, so the trail shows not only what the agent did but what a person signed off. In our audits we find the reverse far more often: rich application logs about business events, and near silence on which non-human actor triggered them, or under whose authority.

The record has to be tamper-evident

A record the acting party can quietly edit is not evidence. NIST's control for protecting audit information, AU-9, is blunt: "protect audit information and audit logging tools from unauthorized access, modification, and deletion" [7], and its enhancements reach for cryptographic protection and storage on a separate system to achieve it. The Center for Internet Security frames the operational side in its Critical Security Controls, asking teams to "collect, alert, review, and retain audit logs of events that could help detect, understand, or recover from an attack" [8]. "Protect" and "retain" are doing real work in those sentences: an append-only store the agent cannot reach to alter, kept long enough to matter.

The emerging engineering answer is a hash-chained log, where each entry carries a cryptographic digest of the one before it, so removing or altering an entry breaks the chain and shows. An early individual Internet-Draft at the Internet Engineering Task Force (IETF), proposing a standard logging format for autonomous AI systems, reaches for exactly this, tamper-evident hash chaining and per-agent identity fields [9]. It is one contributor's proposal with no formal standing yet, not a standard, but it is a fair signal of where this is heading.

The record you can hand to a client or an auditor

Everything above serves one outcome: being able to answer the plain question with evidence rather than assurance. NIST's Zero Trust Architecture makes monitoring a first principle. Its fifth tenet is that "the enterprise monitors and measures the integrity and security posture of all owned and associated assets" [10]. Its AI Risk Management Framework names "accountable and transparent" as a property that trustworthy AI must have, and ties accountability to attribution and provenance, to knowing which decisions came from where [11]. The UK's National Cyber Security Centre (NCSC) puts the same idea as a deployment gate: "if you cannot understand, monitor or contain an agent's actions, it is not ready for deployment" [12].

For a team that runs agents on systems it does not own, an agency, a managed-service provider, or a platform team, this is not abstract. The audit trail is the artefact you produce when a client asks what your automation did inside their environment. Hand over a scoped, attributable, tamper-evident record and the question is answered and the relationship holds. Fail to, and no amount of careful engineering upstream will save the conversation.

Design the record before you need it

None of this is exotic. It is the ordinary discipline of audit logging, non-repudiation and least privilege, applied to a non-human actor that most teams have not yet treated as one. The parts, a distinct identity per agent, scoped and short-lived credentials, an append-only log, and an approval step in front of the dangerous actions, are things you already know how to build. What they need is to be designed together, before the agent is holding a credential in production, not reconstructed after an incident from logs that were never meant to carry the weight.

The companion to this record is the access that produces it: how to grant an agent permission you can scope and revoke, which we cover in letting an AI agent onto your servers. Both are the same senior discipline we bring to any system, and the same one we describe in what happened when we audited one of our own internal tools that held access it should never have kept.

Frequently asked questions

How do I know what an AI agent did?

Only if you recorded it as its own activity at the time. Give the agent its own identity, not a shared human login, and log every action against it: what it did, when, on which system, and on whose authority. Without that, its actions blur into a person's and cannot be reconstructed afterwards.

What should an AI agent audit log capture?

For every action: which agent acted, the specific operation, a trustworthy timestamp, the exact target, the human or service it acted for, the grant it used, and the result. Approvals of high-impact actions belong in the same record. Anything less leaves a question a client or auditor can ask that you cannot answer.

Can you prove what an AI agent did on a client's system?

Only if the agent held its own scoped credential and every action was written to a tamper-evident log. If it used a shared human login, its actions mix into that person's and cannot be separated or proven. On a system you do not own, that record is the artefact the client is entitled to ask for.

Is an application log enough to audit an AI agent?

Usually not. Application logs record business events, not which non-human actor triggered them or under what authority. An agent audit trail is a security record: attributable to the agent's own identity, protected from later edits, and retained. NIST's log-management guidance stresses that a log whose integrity you cannot trust is not evidence [3].

What makes an audit log tamper-evident?

Storage the acting party cannot quietly alter. In practice that means an append-only design, protection from modification and deletion, and increasingly a hash chain, where each entry seals the one before it so any change becomes visible. NIST control AU-9 requires audit information be protected from unauthorised modification and deletion [7].

How long should you keep AI agent logs?

Long enough to answer the questions that arrive late: an incident found weeks on, a client review, or a contractual or regulatory request. The CIS Controls frame audit logs as something to collect, review and retain [8]; the period follows your own obligations, but a log discarded before the question is asked is the same as none.

Prove it, do not assume it

If you are running AI agents on systems you cannot afford to get wrong, the record of what they do deserves the same senior attention as the agents themselves. Designing that record, a distinct identity per agent, an attributable and tamper-evident trail, and an approval gate on the actions you cannot undo, is part of the work we do on AI Agents, and reviewing an existing setup before it goes near production is a Vibe Code Audit. You can book an audit whenever you want a senior engineer to tell you honestly where yours stands.

We are also building this into a product, so that giving people and AI agents governed access, and keeping the sealed record of what they did, is one deliberate step rather than a stack of parts you assemble yourself. It is in early access with a small number of teams who manage servers and agents on behalf of others. If that is you, you can join the early-access list.

Sources

1. CyberArk, "Machine Identities Outnumber Humans by More Than 80 to 1" (2025 Identity Security Landscape), 23 April 2025. https://www.cyberark.com/press/machine-identities-outnumber-humans-by-more-than-80-to-1-new-report-exposes-the-exponential-threats-of-fragmented-identity-security/ (accessed 3 July 2026)
2. OWASP, "A09:2021 Security Logging and Monitoring Failures", OWASP Top 10:2021. https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/ (accessed 3 July 2026)
3. NIST, "Guide to Computer Security Log Management" (Special Publication 800-92), September 2006. https://csrc.nist.gov/pubs/sp/800/92/final (accessed 3 July 2026)
4. OWASP, "Non-Human Identities Top 10 (2025)". https://owasp.org/www-project-non-human-identities-top-10/2025/top-10-2025/ (accessed 3 July 2026)
5. NIST, "AU-10 Non-repudiation", Security and Privacy Controls for Information Systems and Organizations (Special Publication 800-53 Revision 5), September 2020. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf (accessed 3 July 2026)
6. OWASP, "LLM06:2025 Excessive Agency", OWASP Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ (accessed 3 July 2026)
7. NIST, "AU-9 Protection of Audit Information", Security and Privacy Controls for Information Systems and Organizations (Special Publication 800-53 Revision 5), September 2020. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf (accessed 3 July 2026)
8. Center for Internet Security, "CIS Control 8: Audit Log Management", CIS Critical Security Controls version 8. https://www.cisecurity.org/controls/audit-log-management (accessed 3 July 2026)
9. Internet Engineering Task Force, "Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems" (draft-sharif-agent-audit-trail-00, an individual Internet-Draft, not an adopted standard), 29 March 2026. https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/ (accessed 3 July 2026)
10. NIST, "Zero Trust Architecture" (Special Publication 800-207), tenet 5, August 2020. https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf (accessed 3 July 2026)
11. NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)" (NIST AI 100-1), January 2023. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf (accessed 3 July 2026)
12. National Cyber Security Centre, "Thinking carefully before adopting agentic AI", 15 May 2026. https://www.ncsc.gov.uk/blogs/thinking-carefully-before-adopting-agentic-ai (accessed 3 July 2026)