Know what’s on your site before a plaintiff’s firm does
A free privacy audit shows which cookies, pixels and trackers are running — and which ones commonly appear in privacy claims.
For the past few years, “provenance” in AI policy has mostly meant one thing: proving where a piece of content came from. Watermarks, content credentials and the C2PA standard were built to answer a question deepfakes made urgent, which is whether an image, a video or a document is what it claims to be. That work still matters. But the AI systems now arriving in workplaces and government services do not just produce content. They read inboxes, call APIs, book meetings, move money and change records. When one of those systems does something wrong, nobody will ask whether its output was authentic. They will ask what it did, on whose authority, using which data, and whether anyone could have stopped it.
That is a different provenance problem, and it lands squarely on privacy teams, because the evidence needed to answer those questions is largely made of personal data. Keep too little and the organization cannot explain or defend an agent’s decision. Keep too much and the audit trail becomes a surveillance archive. This article sets out how to design for the middle.
Why content credentials do not cover agent actions
Content provenance standards attach a tamper-evident record to an asset: who created it, with what tool, and what edits followed. They are well suited to static objects that are published and shared. An AI agent’s work is not a static object. It is a sequence of steps, each of which may involve a model call, a retrieved document, a tool invocation, a permission check and a write to some other system. The thing that needs to be trustworthy is the chain, not any single output.
Identity is another gap. Content credentials deliberately separate technical provenance from claims about who a person is, partly to limit identity exposure, a tension we explored in how C2PA rewires trust. With agents the identity question cannot be avoided. Someone delegated authority to the agent, the agent may have acted under a service identity of its own, and other agents may have passed it instructions. Accountability requires that chain of delegation to be visible.
What governments are already asking for
Public-sector guidance has moved faster on this than most corporate policy. The New South Wales government’s AI agent usage and deployment guidance, published by the Department of Customer Service in October 2025, is a useful reference because it is practical and short. It is expressly non-mandatory, but its expectations are concrete:
- each agent should have a named accountable owner, with a primary business owner and a secondary IT owner for agents that span both;
- each agent needs observability, “including monitoring, audit logs,” ideally a unique identity, and clear escalation paths proportionate to risk;
- owners should track agent activity, tool use, memory updates and costs, and record decisions with plain-language explanations;
- decision lineage should be exportable, covering inputs, actions, outputs and timestamps, which the guidance describes as essential if an output is challenged;
- organizations should be able to detect, isolate, reverse or manually take control of an agent during unexpected behavior.
The guidance also warns about a risk specific to multi-agent setups: one agent can make a mistake that others copy or accept without question, creating false agreement. That is a strong argument for logging the hand-offs between agents, not just each agent’s final output.
In Europe, the AI Act points in the same direction for high-risk systems. Article 12 requires those systems to allow automatic recording of events over their lifetime, and Article 26 requires deployers to keep the logs under their control for an appropriate period of at least six months, unless other law says otherwise. Those obligations apply to high-risk use cases, and their start date was moved to December 2027 by the July 2026 AI omnibus, but they show where regulators expect accountability to come from: records generated by the system itself.
The privacy problem hiding inside the audit trail
Every useful element of an agent’s accountability record is likely to contain personal data. Prompts quote emails. Retrieved documents name customers. Tool calls include account numbers. Memory stores preferences and history. Logging all of it, forever, would make explanation easy and would also violate basic data protection principles: purpose limitation, data minimization and storage limitation under the GDPR, and similar principles in most modern privacy laws.
The answer is not to log less across the board. It is to decide, in advance, what evidence is needed to explain and contest each kind of decision, and to keep exactly that for exactly as long as the decision can be challenged. We call this an accountability-scoped log. It borrows from the minimization principle in AI governance: the question is not “what could be useful someday” but “what would we need to show a regulator, a court or the affected person.”
Data protection authorities have already flagged agent memory as a specific concern, recommending compartmentalization and retention limits so that information gathered for one task does not silently follow the agent into the next. The same logic applies to the logs about that memory.
A six-part design for agent accountability records
The following structure is a starting point for a privacy, security and engineering working group. It can be adapted to the risk of each agent.
- Delegation record. Who authorized the agent to act, for what scope, with which permissions and until when. This is the agent equivalent of a power of attorney, and it should be stored separately from activity logs so it can be kept longer and shared with auditors without exposing task data.
- Configuration snapshot. The model, version, system instructions, tools enabled and guardrail settings at the time of each run. Most of this contains no personal data and can be retained for the life of the system.
- Action ledger. Each tool call and external action, with timestamp, target system and outcome. Record identifiers and hashes of the data used rather than full copies wherever possible, so a later reviewer can retrieve the source if needed without the log duplicating it.
- Approval and override events. Every point where a human approved, rejected or edited an agent’s proposed action, with the reviewer’s identity. These records show whether human oversight was real, which matters under GDPR Article 22 and similar rules.
- Decision explanation. For actions with legal or similarly significant effects on a person, a short plain-language explanation generated at the time, linked to the action ledger. This is what you will send if the person asks.
- Retention and access rules. Different retention for each layer: long for delegation and configuration, tied to the challenge period for decision records, short for raw task content. Restrict access to the action ledger to the people who need it, and log that access too.
Two technical building blocks help. Verifiable credentials, standardized in the W3C’s Verifiable Credentials Data Model 2.0, can express scoped, tamper-evident grants of authority that an agent presents when it acts. And standard authorization patterns can make high-impact actions wait for an explicit approval event that is itself recorded. Neither is required, but both make the delegation chain easier to prove.
Where this fits in an existing privacy program
Most of this work extends documents privacy teams already maintain. The record of processing activities should list agent logs as a processing activity with its own purpose and retention. The DPIA for any agent that touches personal data should describe the accountability record and justify its scope. The data retention policy needs entries for each log layer. And data subject request procedures need to account for the fact that an individual’s data may now sit in agent memory and activity logs, not just in the systems of record.
For organizations evaluating where to start, our framework for governing agentic AI covers the broader control set. Captain Compliance’s AI governance and assessment workflows can hold the inventory of agents, their owners, risk classification and the DPIA or AI impact assessment that documents the logging design, with the evidence attached. The logs themselves will live in engineering systems; what the governance record adds is a dated decision about what those logs should contain and why.
Standards are still catching up
Agent identity and authorization are now active areas for standards bodies. NIST has launched work on agent standards, covered in our report on the NIST AI agent standards initiative, and some governments are experimenting with formal identities for agents, as in Estonia’s approach. Until those efforts settle, organizations should build records that can be mapped to whatever standard wins: clear identities, scoped authority, time-stamped actions and explicit approvals are common to every proposal we have seen.
Frequently asked questions
Is a standard application log enough for an AI agent?
Usually not. Application logs record that a function ran. They rarely capture the instructions the agent was following, which data it retrieved, which tools it chose and why, or whether a human approved the step. Those are the facts you need to explain a contested decision.
Doesn’t detailed logging conflict with data minimization?
It can, which is why the scope should be set by what is needed for accountability, not by convenience. Using references and hashes instead of full copies, separating layers with different retention, and limiting access all reduce the conflict.
How long should agent logs be kept?
There is no single answer. High-risk systems under the EU AI Act require deployers to keep logs for at least six months, unless other law provides otherwise. Beyond that, tie retention to the period during which a decision can realistically be challenged, and keep configuration and delegation records longer than raw task content.
Do content credentials still matter for agents?
Yes, for anything the agent publishes or sends outside the organization. Labeling AI-generated content remains a legal duty in some jurisdictions. It is simply not sufficient on its own to account for what the agent did.
Who should own the accountability record?
The agent’s named business owner should own the decision about what is recorded, with privacy defining limits and engineering implementing them. The NSW model of a primary business owner and secondary IT owner is a reasonable template.
The question an agent cannot answer for you
Deepfakes taught institutions to ask whether something was real. Agents will teach them to ask who was responsible. When the first serious complaint arrives about an agent that denied a benefit, sent the wrong payment or shared the wrong file, the organization will either have a record that explains what happened without exposing everything else, or it will have to choose between silence and surveillance. That choice is being made now, in logging configurations few lawyers have read.
Put this into practice
Turn privacy guidance into working controls.
Captain Compliance helps teams discover tracking technologies, enforce consent, manage privacy requests and document the evidence behind every decision.
