- Home
- AI agents
- Governance and regulation
- Audit trails
Govern and secure · Governance and regulation
What should an AI agent audit trail contain, and how do you keep it?
An AI agent audit trail is the tamper-evident record that lets someone reconstruct a single agent run after the fact: which identity acted and for whom, what it read, which tools it called with which arguments, who approved what, what it produced, and which versions of model, prompt and agent were live.
In this guide: 83 pages
Key takeaways
- An audit trail and a trace answer different questions. Traces are sampled telemetry for engineers; the audit trail is a complete, tamper-evident record of actions and approvals for auditors, and it must never depend on the agent reporting its own behaviour.
- No single product holds the whole record. Join identity logs, traces, approval events and the registry entry on a run id, and test the join before an auditor does.
- Default retention is shorter than most duties. Purview Audit (Standard) keeps records 180 days, CloudTrail event history 90 days and Google’s _Default log bucket 30 days, while Colorado expects compliance records for 3 years from 1 Jan 2027 and the EU AI Act expects high-risk logs for at least six months from 2 Dec 2027 for Annex III uses and 2 Aug 2028 for Annex I.
- Make the archive write-once. S3 Object Lock in compliance mode stops anyone, the root user included, from deleting a locked object version during its retention period, and Azure immutable blob storage offers locked time-based retention and legal holds.
- The trail holds personal data, so it needs the same minimisation as any other store: pseudonymous user ids, content behind a privileged role, and retention set per field instead of per log.
What does one audit record need to hold?
It needs enough to answer an auditor’s questions about one run without opening the agent: who acted, on whose behalf, with which versions, touching which resources and tools, under whose approval and with what result. The table lists the fields and where they come from, including the fields Microsoft Purview already records for Copilot and agent interactions.
Fields of one agent audit record, why each matters and an example source as documented on 2 Nov 2026.
| Field | Why an auditor needs it | Example source |
|---|---|---|
| Run id, trace id and timestamps | Joins every other source into one record | Trace context; the agent’s run store |
| Acting agent identity and the user it acted for | Attributes the action and shows whether it was delegated or autonomous | Agent identity sign-in logs; the user principal on the request |
| Agent name and version | Ties behaviour to the approved version | Purview audit fields AgentId, AgentName and AgentVersion |
| Model provider, name and version | Shows which model produced the output when several are allowed | Purview ModelTransparencyDetails; modelId in Bedrock invocation logs |
| Instructions or prompt version | A prompt change alters behaviour as much as a model change | Prompt registry version or label |
| Resources read, with sensitivity labels | Shows whether sensitive data informed the result | Purview AccessedResources with SensitivityLabelId |
| Tool calls with arguments and results | Shows what the agent did, which is where harm happens | execute_tool spans; tool server logs |
| Guardrail and injection signals | Shows attacks seen and blocked | Purview XPIADetected and JailbreakDetected flags |
| Approval: approver, what they saw, decision, time | Proves the human oversight was real | The approval service log, copied onto the run |
| Output and the decision it fed | Links the agent to the business outcome | The record id in the downstream system |
| Stops, overrides and errors | Shows the controls worked when they were needed | Kill-switch events; error.type on spans |
Record actions from the platform side. In July 2025 Replit’s coding agent ran destructive commands on a production database during a code freeze and then told its user that a rollback was impossible, which turned out to be wrong, as The Register reported on 21 Jul 2025. An audit trail built from what an agent says about itself would have repeated the error.
How long do you keep the trail, and how do you make it tamper-evident?
Keep it for the longest period any applicable duty sets, and store it where nobody, administrators included, can change or delete it during that period. Platform defaults are often shorter than the duty, so plan an archive with a retention lock from the start.
Retention duties and platform defaults that shape an agent audit trail, as published on 2 Nov 2026.
| Rule or default | Period | What it means for the trail |
|---|---|---|
| EU AI Act Articles 19(1) and 26(6), high-risk systems | At least six months unless other law says otherwise; from 2 Dec 2027 for Annex III uses | The minimum for logs of high-risk agents, subject to data protection law |
| Colorado SB 26-189, from 1 Jan 2027 | Compliance records for at least 3 years | Decision records for agents that materially influence consequential decisions |
| Microsoft Purview Audit (Standard) | 180 days by default for records created since 17 Oct 2023 | Copilot, Copilot Studio and Foundry interactions are included; non-Microsoft AI apps use pay-as-you-go audit with 180 days |
| Microsoft Purview Audit (Premium) | One year by default for some workloads; custom policies up to 10 years with an add-on licence | Retention policies can target the Copilot and AI record types |
| AWS CloudTrail event history | 90 days of management events, immutable | Create a trail or a CloudTrail Lake event data store for anything longer |
| Google Cloud Logging buckets | _Required: 400 days, not configurable; _Default: 30 days, configurable for project buckets | Admin activity audit logs land in _Required; route data access logs to a longer bucket |
For the archive itself, Amazon S3 Object Lock in compliance mode prevents any user, the root user included, from overwriting or deleting a locked object version before its retention date, and a legal hold keeps an object until someone removes the hold. Azure immutable blob storage offers time-based retention from one day to 146,000 days; once locked, a policy can be extended and never shortened, and legal holds work alongside it.
How do you keep personal data in the trail lawful?
Treat the trail as a personal-data store with a purpose, a retention period and an access list. The EU AI Act defers to data protection law on log retention, so a six-month floor never justifies keeping prompts full of personal data for years by default.
Split the record by sensitivity. Identifiers, versions, tool names, decisions and approvals are metadata an auditor needs for the full period. Prompt text, retrieved passages and tool results hold the personal data, so keep them behind a privileged role and for a shorter period where the duty allows. On Microsoft, Application Insights routes GenAI content to the AppGenAIContent table, which supports protected access in preview: set it to Protected and grant reads through the Privileged Monitoring Data Reader role or a custom role with the matching permissions.
Pseudonymise user ids in the long-term archive and keep the lookup table separately, so an investigation can still name the person when it must. Deletion and retention interact: holds suspend deletion of Copilot messages, and deleting a Copilot conversation leaves the memory derived from it in place, so an erasure request needs a check of each store.
Design for erasure before you lock anything. A write-once archive cannot drop one person’s records early, so keep prompt content and other personal fields outside the locked store, or in a store with its own shorter retention, and lock only the metadata the duty requires. Record which store holds which field, so the privacy team can answer an access or erasure request without reading the code.
How do you test that the trail works?
Run a reconstruction drill: pick a real run from last quarter and rebuild it from stored records alone, without asking the builders. Any question below that has no answer marks a gap in the trail.
- Which agent identity acted, and for which user?
- What versions of the agent, prompt and model were live at that moment?
- Which documents and records did it read, and which sensitivity labels did they carry?
- What tools did it call, with which arguments, and what came back?
- Who approved the action, what did they see, and when?
- What did the run produce, and which downstream record did it change?
- If a guardrail fired or someone stopped the agent, where is that event?
Repeat the drill after each platform upgrade. Changes to telemetry conventions, SDKs or table layouts can drop a field without an error, as the 30 Sep 2026 move of GenAI content into the AppGenAIContent table did for queries that read the old tables.
How do Microsoft, AWS and Google implement it?
Where each part of the audit trail lives on the three clouds, as the vendor pages showed on 2 Nov 2026.
Capability, Microsoft, AWS, Google
| Capability | Microsoft | AWS | |
|---|---|---|---|
| Interaction audit | Purview Audit records Copilot, Copilot Studio and Foundry interactions with agent, model and resource fields | Bedrock model invocation logging, disabled by default, with identity.arn; cross-Region requests logged in the source Region with the inference Region | Agent Runtime telemetry in Cloud Trace and Cloud Logging; content only behind a separate switch |
| API and admin audit | Unified audit log for admin actions on Copilot and agents | CloudTrail, including AgentCore Gateway and Agent Registry calls | Cloud Audit Logs, with admin activity in the _Required bucket |
| Default retention | 180 days in Audit (Standard); longer with Audit (Premium) policies | 90 days of event history; trails and CloudTrail Lake for longer | 400 days in _Required; 30 days in _Default unless changed at project level |
| Write-once archive | Azure immutable blob storage with locked time-based retention and legal holds | S3 Object Lock in compliance mode, which administrators cannot bypass, plus legal holds | Not verified for this page |
Retention periods depend on licences and settings. Check your own tenant and accounts before you write a period into a policy.
Frequently asked questions
Are agent traces the same as an audit trail?
No. Traces are telemetry: often sampled, readable by many engineers, kept for weeks and easy to delete. An audit trail is complete for actions and approvals, protected against tampering, often in a write-once archive, and kept for the period the law sets. Build it from traces where you can, then copy the fields it needs into the locked archive.
How long should we keep AI agent logs?
As long as the longest duty that applies, and no longer: at least six months for high-risk systems under the EU AI Act, from 2 Dec 2027 for Annex III uses and 2 Aug 2028 for Annex I, three years for Colorado compliance records from 1 Jan 2027, and longer where sector rules or litigation holds require it. Keep prompt content for less time than metadata where you can.
Should prompts and responses be in the audit trail?
For agents that influence decisions about people or money, usually yes, behind a privileged role, because the content is what an investigation needs. For low-risk agents, metadata and tool calls are often enough. Decide per risk tier, write the reason down and set a deletion date.
Can the agent write its own audit record?
It should never be the only writer. Record identity, tool calls and approvals at the platform, the gateway and the identity provider, where the model cannot change or invent them. The agent’s own summary of what it did is useful context, and it belongs next to the record rather than in place of it.
More in Governance and regulation
Sources
Each source was read on 2 November 2026. The date shown is the date on the page, or the page’s ms.date for Microsoft Learn; an undated page shows the date it was read.
- Audit logs for Copilot and AI applications
- Manage audit log retention policies
- Retention policies for Copilot and AI apps
- Search for and delete Copilot and AI app data with eDiscovery
- Restrict access to sensitive content in traces
- Immutable storage for blob data overview
- Working with CloudTrail event history
- Locking objects with S3 Object Lock
- Amazon Bedrock model invocation logging
- Increase throughput with cross-Region inference
- Cloud Logging quotas and limits
- EU AI Act, Article 19: Automatically generated logs
- EU AI Act, Article 26: Obligations of deployers of high-risk AI systems
- SB 26-189, Automated Decision-Making Technology
- Vibe coding service Replit deleted production database, faked data, told fibs galore
Planning an AI program?
Talk to the team that builds it and runs it after launch.
- Built to SOC 2, HIPAA and GDPR standards
- EU AI Act-aligned delivery
- Microsoft Solutions Partner