Explainer · By Chris Sowa · Published
Last updated
What Is an AI Agent Audit Trail and What Should Companies Log for Security and Compliance?
An AI agent audit trail is the per-run record of what the agent was shown, what it did, who approved each consequential step and what resulted, timestamped, kept in the organization's own monitoring for as long as its regulators require. Without one, no run can be reconstructed, and a vendor's assurance stands in for evidence the organization never held.
An AI agent audit trail is the per-run record of what the agent was shown, what it did, who approved each consequential step and what resulted, timestamped, kept in the organization's own monitoring for as long as its regulators require. Without one, no run can be reconstructed, and a vendor's assurance stands in for evidence the organization never held. The question matters because an agent's reading is as consequential as its writing: a model that read a full patient record to answer a billing question has processed that record whether or not it changed anything, and application logs, built to record writes and logins, are silent on that event. The trail that fills the gap has a specific shape, and in RedactSure's vocabulary it is the AI Control Record: the record of every screen the agent saw as tokens, every action, every approval with a name, exported to the customer's own monitoring. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Key findings
- The two failures a trail most needs to show are the top two risks in the OWASP Top 10 for LLM Applications 2025, prompt injection (LLM01) and sensitive information disclosure (LLM02), and neither leaves a trace in an application log (OWASP, 2025).
- The NIST AI Risk Management Framework places monitoring and record keeping inside its Measure and Manage functions, treating them as life-cycle activities rather than a launch check (NIST, 2023).
- NIST SP 800-92 sets the baseline that logs be collected and analyzed centrally, with retention set by policy rather than by the default of the system that produced them (NIST, 2006).
- OMB Memorandum M-24-10 requires ongoing monitoring and human oversight as minimum practices for rights-impacting and safety-impacting AI used by federal agencies (OMB, 2024).
- Twenty-four states had adopted the NAIC Model Bulletin on the Use of AI Systems by Insurers by March 2025, which asks insurers to document and govern AI systems in a way an examiner can review (Quarles & Brady, 2025).
- Peer-reviewed work on AI accountability finds that developers' own verification schemes rest on unexamined assumptions and can produce misplaced trust, which is the case for holding one's own record of what an agent saw and did (Paris, Moon and Guo, 2026).
What does an AI agent audit trail record that an application log does not?
An application log records the events the application was built to notice: a claims platform logs that a user opened a claim, changed a reserve and submitted a payment; an EHR logs chart access and order entry; a finance system logs the journal and the approver. Those logs assume a human user whose reading is bounded by what a person can take in. They record the write, sometimes the open, and almost never the content of what was read.
An agent breaks that assumption in two places. The first is reading. A model reads the whole rendered screen, including every field the task never needed, and that material becomes processed data inside its context, which is what OWASP's LLM02 entry describes as sensitive information disclosure (OWASP, 2025). An application log shows the record was opened; it does not show which values the model received. The second is instruction. An agent can be redirected by content it reads, the indirect prompt injection pattern documented by Greshake et al. (2023), and the application log shows only the resulting action, under the legitimate user's credentials, with no indication that the instruction came from a web page rather than the person.
An AI agent audit trail covers both. It sits at the layer where the agent works, not inside any one application, and answers four questions for every run: what the model received, what the agent did with it, who approved each consequential step, and what came of it. AI agent auditability is the property of being able to answer those questions after the fact; the trail is the artifact that makes the property real. Many products claim the property while producing only an activity feed of clicks and keystrokes, which answers the second question and none of the others.
What should every entry in the trail carry?
A trail is usable only if its entries share a shape, a point developed on the page on auditing sensitive data access across applications. For an agent the shape has five parts, in the order a reviewer reads them.
| Entry type | What it holds | Why it is there |
|---|---|---|
| Screen | The screen as the model received it, with identifiers as tokens, plus application, screen name and timestamp | Proves what the model was shown, which no application log records |
| Action | The step the agent took: field written, button pressed, file opened, with the target and the values entered as tokens | Reconstructs the run step by step |
| Approval | The consequential action proposed, the named person who approved or declined it, and the time | Ties every payment, submission and record change to a person |
| Outcome | What the destination system returned: confirmation number, error, or rejection | Shows whether the approved action completed |
| Policy | The exposure policy in force for the run, which values were tokenized, and who confirmed it before the run | Lets a reviewer judge the run against the rule it was meant to follow |
Three details separate a working trail from a decorative one. Approvals carry a name, not a role or a service account; an approval recorded as "system" is not an approval, and human-in-the-loop approval is only evidence when the record says who. Timestamps come from one clock across all five entry types, so screen, proposed action and approval can be placed in order without reconciling sources. And every entry carries a run identifier, so one task's trail can be pulled in full without reading the whole day's log.
The policy entry is the one most often missing. A trail that shows what happened without what was supposed to happen leaves the reviewer to infer the rule; recording the policy in force, and who confirmed it, turns the trail into a comparison between intended exposure and the actual run.
Should the trail hold real values or tokens?
The trail is itself a data store, and the first design decision is what it stores. A trail of the real screens the agent saw is a second copy of every record the agent touched, every SSN, account number and diagnosis, now in a log with its own access list, retention and breach consequences. Debugging convenience tends to drive that choice, and the NIST Privacy Framework's data minimization practices exist to stop it (NIST, 2020).
The alternative is to record screens as tokens. If identifiers were replaced by consistent stand-ins before the model read the screen, then the record of what the model received contains SSN_001 and ACCT_001, not the values. The trail then proves the right thing, which is that the model never received the identifiers, and it proves it without holding them. The token is consistent within the run, so a reviewer can follow ACCT_001 from the screen where it was read to the action where it was used, while the mapping from token to value stays in the governed environment under the organization's keys.
Research on information flow makes the same point from the other direction. Siddiqui et al. propose tracking labels through a model's queries so that where confidential data flowed can be reconstructed afterwards, and the work shows how hard that tracking is once data is inside the context (Siddiqui et al., 2025). A trail of tokens makes the flow question easier, because the sensitive value never entered the flow being traced. What stays in clear are the task's working facts: amounts, dates, codes and the coverage or clinical facts the work ran on, where policy says so.
The test: if the trail were breached, what would the attacker have? If the answer is every screen the agent ever read, the trail has reproduced the exposure it was meant to govern.
How long should the trail be kept, and who decides?
Retention is set by the organization's obligations, not the vendor's default. SP 800-92 states the principle: retention comes from policy and legal requirement, and the organization, not the log source, decides how long records persist (NIST, 2006). Consumer agent products illustrate the gap. Meta's design write-up for Muse names an activity log among its controls, and OpenAI's documentation for Dots describes an Activity View for following and redirecting work (Meta AI Research, 2026; OpenAI, 2026). Neither document, as read, states a retention period or an export path to the customer's monitoring, and the companion page on maintaining audit trails for agent activity sets out why a trail that lives on a vendor's setting is not the organization's trail.
The period varies by regime, and counsel sets it. HIPAA's documentation requirement at 45 CFR 164.316(b)(2) asks covered entities to retain required documentation for six years from creation or last effective date, and the Security Rule's audit controls standard at 164.312(b) asks for mechanisms to record and examine activity in systems that contain electronic protected health information (HHS, 2024). The GLBA Safeguards Rule at 16 CFR 314.4 requires financial institutions to monitor and log the activity of authorized users and to detect unauthorized access (FTC, 2023). Insurance examiners working under the NAIC AI Model Bulletin expect documentation of AI systems that can be produced on request (NAIC, 2025). Each is a floor the organization's own policy sits on, and litigation holds can extend any of them.
Two rules follow. The trail is retained at least as long as the longest obligation attached to the records the agent touched, since a trail that expires first cannot support a later inquiry about those records. And retention is enforced in the organization's own store, because a vendor's window can change with a product update, a plan tier or an acquisition.
How should the trail reach the SIEM?
A trail the organization cannot query in its own tooling is a trail it does not have. The SIEM is where a security team already correlates identity, endpoint and application events, and the agent trail belongs beside them, so an alert on an agent action can be joined to the login that started the session and the record that changed. SP 800-92's model of centralized collection applies to this log source as to any other (NIST, 2006).
Export has four requirements. The feed is continuous, so a run in progress can be seen while it runs. Entries arrive structured, with the five entry types and shared fields above, so a detection rule can match on them: an approval with no name, an action with no preceding approval, a screen whose policy differs from the confirmed one. The feed is complete, carrying every screen as tokens rather than a summary, because a summary is the vendor's interpretation. And the feed is the organization's copy, under its own retention and access controls.
The last requirement is where separation of model and control matters. If the vendor that runs the model also produces the only record of what the model did, the party being audited keeps the audit. Paris, Moon and Guo describe the general failure: verification schemes developers offer about their own systems rest on assumptions a reviewer never examines, and the result is unearned trust (Paris, Moon and Guo, 2026). An exported trail in the organization's SIEM is the organization's evidence, held where the vendor cannot edit it.
The page on monitoring what an agent accesses covers the detection rules worth writing once the feed is in place; the most useful ones match on absence.
What do compliance frameworks expect of the trail?
No framework yet names "AI agent audit trail" as a control. Each sets an expectation the trail is the natural way to meet; the table maps the main regimes to the entries that answer them.
| Regime | What it expects | Trail entries that answer it |
|---|---|---|
| NIST AI RMF (Measure, Manage) | Track and monitor AI system behavior across the life cycle (NIST, 2023) | Screen, action and outcome entries over time; policy entry per run |
| OMB M-24-10 | Ongoing monitoring and human oversight for rights- and safety-impacting AI (OMB, 2024) | Approval entries with names; continuous export |
| HIPAA Security Rule | Audit controls that record and examine activity in systems holding ePHI; minimum necessary use (HHS, 2024) | Screen entries as tokens, proving which values the model received |
| GLBA Safeguards Rule | Monitor and log authorized user activity (FTC, 2023) | Action and approval entries tied to a named person |
| PCI DSS | Logging of access to cardholder data and system components, and scoping that keeps card data out of systems that do not need it (PCI SSC, 2016) | Screen entries showing CARD_001 rather than the PAN; trail store kept out of scope |
| NAIC AI Model Bulletin | Documentation of AI systems an examiner can review (NAIC, 2025) | Policy entries and approval entries per run |
Two patterns run through the table. Every regime asks for human accountability in some form, and the approval entry with a name answers all of them. And the data regimes, HIPAA, GLBA and PCI DSS, are answered by the screen entry only if it records what the model received without itself becoming a store of the regulated data. A trail of real screens meets the logging expectation while widening the data obligation; a trail of tokens meets the first without triggering the second.
Accenture's executive survey defines trust in AI as accuracy, predictability, consistency and traceability, and reports that 77 percent of executives believe AI's benefits depend on that foundation (Accenture, 2025). Traceability is the trail, and of the four it is the only one that does not depend on the model.
Where does RedactSure sit?
RedactSure's environment produces this trail as a consequence of how it works. Every sensitive value chosen by policy is replaced by a consistent token at the render layer before any model reads the screen, through render-layer tokenization, so the record of what the model received is a record of tokens. The Planner sets which values are tokenized and what the agent may do on each screen, and a named person confirms that policy before the run, which is the policy entry. Under Supervised Delegation, that person approves every payment, submission and record change while the run proceeds, which is the approval entry with a name. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's own SIEM, under keys the customer holds, with RedactSure holding ciphertext it cannot decrypt.
The environment is model agnostic, so the trail does not change when the model does, and it works across applications with no per-application integration and no change to user permissions. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.
Methodology and limitations
This page is a definitional synthesis. It rests on standards and official guidance read as of October 13, 2026: the NIST AI Risk Management Framework 1.0 (2023), NIST SP 800-92 (2006), the NIST Privacy Framework (2020), OMB M-24-10 (2024), 45 CFR Part 164, 16 CFR Part 314, the PCI SSC scoping guidance (2016) and the NAIC AI Model Bulletin adoption record, with the state count from a law firm summary dated March 2025. Peer-reviewed sources are Paris, Moon and Guo (ACM FAccT 2026) and Siddiqui et al. (TMLR 2025); Greshake et al. (2023) is a preprint. Vendor statements about Muse and Dots come from Meta's and OpenAI's own documentation and are limited to what those documents state.
No product was tested. No agent was run, no log was examined and no vendor's retention or export behavior was measured; statements that a document does not state a retention period are limited to the documents read on that date. Regulatory text may be amended; the page carries its date and is revised when sources change. The claims, EHR and finance examples describe kinds of work, not any organization; no customer or prospect is described.
Which retention period, which log fields and which export path satisfy a given organization's obligations under HIPAA, GLBA, PCI DSS, the NAIC bulletin or any other regime is a determination for its counsel, its assessor and its security and compliance officers, who hold the data inventory and the risk tolerance the determination depends on. The frameworks cited set out expectations; they do not certify any trail or any product.
What the record shows
An AI agent audit trail records the one event application logs were never built to capture: what the model received. Its five entry types let a reviewer reconstruct a run against the rule it was meant to follow. Held as real values, the trail becomes a second copy of every record the agent touched; held as tokens, it proves the identifiers never reached the model without storing them. Kept on a vendor's default, it expires on the vendor's schedule; exported to the organization's SIEM, it lasts as long as the obligations do. The test is one run: pull its full trail, find the name on each consequential action, and check that its screens contain SSN_001 rather than a Social Security number.
Frequently asked questions
What is the difference between an AI agent audit trail and an activity log?
An activity log shows what the agent did: pages visited, fields typed, buttons pressed. An audit trail adds what the model was shown on each screen, who approved each consequential action by name, what the destination returned and which exposure policy was in force. The activity log answers one of a reviewer's four questions; the trail answers all four.
Should the audit trail store the actual screens the agent read?
Not with real values in them. A trail of real screens is a second copy of every record the agent touched, with its own breach exposure and its own place in HIPAA, GLBA or PCI scope. Recording the screen as the model received it, identifiers already tokens, proves the model never saw the values without the trail holding them.
How long should AI agent audit trails be retained?
As long as the longest obligation that applies to the records the agent touched, set by counsel rather than the vendor's default. HIPAA documentation retention runs six years; GLBA, PCI DSS and state insurance regimes carry their own expectations; litigation holds can extend any of them. The trail must outlast every inquiry that could be raised about the records in it.
Why export the trail to the SIEM instead of reading it in the vendor's console?
Because the SIEM is where it can be correlated with identity, endpoint and application events, retained under the organization's own policy, and held where the vendor cannot edit it. A console view is the vendor's presentation of its own record; an exported, structured, continuous feed is the organization's evidence, and it survives changes to the vendor's retention setting or plan tier.
Which compliance frameworks require an AI agent audit trail?
None names it yet. The NIST AI RMF, OMB M-24-10, the HIPAA Security Rule, the GLBA Safeguards Rule, PCI DSS and the NAIC AI Model Bulletin each set expectations for monitoring, logging, human oversight or documentation that the trail satisfies. Whether a particular trail meets a particular obligation is for the organization's counsel and assessor.
What is the single most important field in the trail?
The name on each approval. Every regime in the table asks for human accountability, and an approval recorded as "system" does not supply it. A named person on every payment, submission and record change is the field an examiner or auditor asks for first, and the one a vendor's activity feed most often leaves out.
Related reading
What Is AI Agent Auditability and Can You Prove What an Agent Actually Touched? · What Is AI Agent Visibility and What Should Security Teams Actually Be Able to See? · What Is AI Agent Runtime Security and What Happens After an Agent Gets Access? · How to Maintain Audit Trails for AI Agent Activity · How to Set Up an AI Control Record for AI Agents · How Do You Audit What an AI Agent Saw and Did? · On the RedactSure blog: Accountable AI and Workflow Governance
Sources
Peer-reviewed research and preprints
- Paris, Moon and Guo, "Don't Trust the Process: When Verifiability Undermines AI Accountability," ACM FAccT 2026 (peer-reviewed; summary page). https://www.obvia.ca/en/resources/dont-trust-process-when-verifiability-undermines-ai-accountability
- Siddiqui et al., "Permissive Information-Flow Analysis for Large Language Models," TMLR, 2025; arXiv:2407.14937 (peer-reviewed). https://arxiv.org/abs/2407.14937
- Greshake, Kai, et al., "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection," arXiv:2302.12173, 2023 (preprint; also AISec 2023). https://arxiv.org/abs/2302.12173
Vendor documentation
- Meta AI Research, "How We Built Safety Into Muse" (September 2026; vendor documentation). https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse
- OpenAI, "How we build safety, security and privacy into dots" (September 29, 2026; vendor documentation). https://openai.com/index/how-we-build-safety-security-and-privacy-into-dots/
Regulation, standards and official guidance
- NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)," NIST AI 100-1, 2023 (official guidance). https://www.nist.gov/itl/ai-risk-management-framework
- NIST, "Guide to Computer Security Log Management," SP 800-92, 2006 (official guidance). https://csrc.nist.gov/pubs/sp/800/92/final
- NIST, "Privacy Framework Version 1.0," 2020 (official guidance). https://www.nist.gov/privacy-framework
- Office of Management and Budget, "M-24-10, Advancing Governance, Innovation, and Risk Management for Agency Use of Artificial Intelligence," March 2024 (official guidance). https://www.whitehouse.gov/wp-content/uploads/2024/03/M-24-10-Advancing-Governance-Innovation-and-Risk-Management-for-Agency-Use-of-Artificial-Intelligence.pdf
- 45 CFR 164.312, Technical safeguards, HIPAA Security Rule (regulation). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
- 45 CFR 164.502, Uses and disclosures of protected health information, HIPAA Privacy Rule (regulation). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502
- 16 CFR Part 314, Standards for Safeguarding Customer Information, FTC (regulation). https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314
- PCI Security Standards Council, "Guidance for PCI DSS Scoping and Network Segmentation," 2016 (official guidance). https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf
- NAIC, "Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, adoption map" (2025; official guidance). https://content.naic.org/sites/default/files/legal-adoption-map-ai-model-bulletin.pdf
- OWASP, "LLM01:2025 Prompt Injection," Top 10 for LLM Applications 2025 (industry standard). https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- OWASP, "LLM02:2025 Sensitive Information Disclosure," Top 10 for LLM Applications 2025 (industry standard). https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/
Industry analysis and press
- Quarles & Brady, "Nearly Half of States Have Now Adopted NAIC Model Bulletin on Insurers' Use of AI," March 2025 (law firm analysis). https://www.quarles.com/newsroom/publications/nearly-half-of-states-have-now-adopted-naic-model-bulletin-on-insurers-use-of-ai
- Accenture, "Technology Vision 2025: AI: A Declaration of Autonomy," January 2025 (industry analysis). https://www.accenture.com/us-en/insights/technology/technology-trends-2025
RedactSure documents
- RedactSure Research, "What Is an AI Control Record?" (2026). https://redactsure.com/research/what-is-an-ai-control-record
- RedactSure Research, "What Is Render-Layer Tokenization?" (2026). https://redactsure.com/research/what-is-render-layer-tokenization
- RedactSure Research, "What Is Supervised Delegation?" (2026). https://redactsure.com/research/what-is-supervised-delegation
- RedactSure Research, "How to Maintain Audit Trails for AI Agent Activity" (2026). https://redactsure.com/research/how-to-maintain-audit-trails-for-ai-agent-activity
- RedactSure, "Accountable AI and Workflow Governance" (2026). https://redactsure.com/blog/accountable-ai-and-workflow-governance/
- Product behavior described on this page reflects RedactSure's current design. Muse is a trademark of Meta Platforms, Inc.; ChatGPT and Dots are trademarks of OpenAI; named to identify the products. Compliance determinations belong to the organization's counsel.
What Is AI Agent Auditability?
Review AI Agent Auditability, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
What Is AI Agent Visibility?
Review AI Agent Visibility, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
What Is AI Agent Runtime Security?
Review AI Agent Runtime Security, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
How to Maintain Audit Trails for AI Agent Activity
Review Maintain Audit Trails for AI Agent Activity, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
How to Set Up an AI Control Record for AI Agents
Review Set Up an AI Control Record for AI Agents, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
How Do You Audit What an AI Agent Saw and Did?
Explore AI agent audit evidence for sensitive claims and billing, including tokenization policies, approvals and logs that avoid raw PII.
Accountable AI and Workflow Governance
Explore AI agent governance for billing and claims, with named supervisors, data masking, approval boundaries and a useful audit record.
What Is an AI Control Record?
Explore an AI agent control record for billing and claims, linking permissions, tokenization decisions, approvals and audit evidence.
What Is Render-Layer Tokenization?
Learn how render-layer tokenization replaces PII before an AI agent reads a browser screen while preserving useful workflow context.
What Is Supervised Delegation?
Explore supervised delegation for AI agents in billing and claims, with named responsibility, tokenization policies and human approvals.
Book an AI Agent Security Review →
Bring your hardest questions.
Bring one sensitive workflow and the decisions your team needs to keep in its hands.
Book a demoAbout the author
Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.