What should an AI agent's audit trail capture?

An adequate agent audit trail lets you reconstruct, from the record alone, how it reached its current state and on whose authority. Four elements are the minimum: Acting identity - the specific agent, not a shared integration account. Triggering event - the ticket, message, schedule, or record change that started the run. Decision inputs - what the agent could see at the time, which is what separates a bad decision from a decision made on bad data. Delegated authority - who approved that this agent could take this class of action. One practical constraint matters more than the field list: the log must be joinable to the record. An audit trail living only inside the agent platform, with no way to correlate it to the ticket or opportunity, is not usable during an incident or by an auditor sampling records months later.

Iryna Tkachuk August 12, 2026 13 min read AI-assisted

Your AI Agents Moved Into the Systems Your Business Runs On

AI Transformation Leadership Workflow

The agent governance debate is being conducted about the wrong variable. Almost every framework published this year asks how autonomous the agent is. The question that actually determines your exposure is where it runs.

For two years the industry argued about capability. The more consequential development arrived without a launch event, through partnership announcements and platform roadmaps: agents stopped being a product you open and became a property of software your company already owns.

They ended up inside systems of record. The ITSM queue. The CRM opportunity. The purchase order. The customer conversation thread. These are the stores an organization treats as authoritative, the ones every downstream process and report trusts without checking. An agent that drafts a suggestion in a side panel is a productivity tool. An agent that closes the ticket, updates the opportunity stage, or approves the requisition is something else. It is a system that creates business facts.

Most of the governance advice available right now was written for the first kind of agent. It treats the agent as free-floating software that happens to be autonomous, which is not wrong so much as incomplete. What it under-weights is location. An agent operating inside the authoritative record needs stronger permissions, better logs, defined exception behavior, and a named human owner, and it needs all four before it is allowed to write anything.

Four controls, one trigger. The trigger is write access to the record.

The agents moved, and that is the real story

Look at where the significant agent deployments of the past year landed, and a pattern shows up immediately.

In May 2026, Wipro expanded its ServiceNow partnership to scale agentic AI workflows across IT, HR, procurement, and cybersecurity. Not a chatbot layered on top of ServiceNow, but agents operating inside the platform that holds the authoritative state of those four functions. In June 2026, Meta launched Business Agent globally, embedding agents into business messaging alongside commerce and support workflows, which means agents acting inside the record of what a business told a customer and what that customer bought.

Different companies, different platforms, same architectural decision. In both cases the agent does not advise a human who then updates the record. The agent updates the record.

That distinction sounds small in a slide and is enormous in production. The advisory pattern keeps a human in the loop by construction, because nothing changes until a person types something. The embedded pattern removes that checkpoint by design , because removing it is the entire value proposition. Nobody is buying an agent that suggests the ticket resolution. They are buying one that resolves the ticket.

Every control question that follows comes from that single change. Start with what the record actually is.

Why a system of record is a different risk surface

A system of record is the store your organization has agreed to treat as true. Other systems read from it. Reports aggregate it. Auditors sample it. Downstream automation triggers off it. When the CRM says an opportunity closed, finance behaves as though it closed.

Three properties make it a distinct risk surface.

Other systems trust it without verifying. A wrong value in a sandbox stays in the sandbox. A wrong value in the record propagates into forecasts, commission calculations, capacity plans, and customer communications, often within the same day and usually without anyone reviewing the original write.

Corrections are expensive and visible. Fixing a bad record is not one update. It is one update plus every downstream artifact that already consumed it, plus the conversation with whoever acted on the wrong information. Some corrections are not possible at all, because the payment already cleared or the email already sent.

The record is the evidence. When something goes wrong, the record is what you reconstruct the incident from. If the record does not capture how it got into its current state, you are investigating with the primary evidence missing.

An agent that drafts a bad email costs someone a minute. An agent that closes the wrong ticket, discounts the wrong opportunity, or approves the wrong purchase order creates a business fact that other systems immediately act on. The technology is identical. The blast radius is not.

Which raises the question every deployment answers implicitly and almost none answers deliberately: what is this agent allowed to reach?

Permissions: what the agent can do versus what you allowed

Gartner (2026) put a number on how this goes wrong, a forecast rather than a measurement, though the failure mode behind it is the one that keeps showing up. It predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents because of governance gaps that only surfaced after production incidents. Its analysis locates the root cause precisely: failures cluster where organizations fail to distinguish an agent's ability to act from the scope of access it was granted.

That distinction is worth sitting with, because it is not the distinction most teams think they are managing. Teams evaluate what the agent is designed to do, which is a question about the prompt, the tools, and the workflow. The scope of access is a separate question about what the agent could reach if it behaved unexpectedly. In a system of record those two answers are usually very far apart, and the gap is where incidents live .

There is a mundane reason for this. The fastest way to ship an agent is to give it an integration user with broad permissions, because scoping it properly means understanding every object it might touch and every action it might take, which is slow. Most pilots took the fast path. Most pilots then became production without anyone revisiting the decision.

Three things change the picture:

Give each agent its own identity. Not a shared service account, not a borrowed human credential. If the audit trail says a named employee closed 300 tickets overnight, the identity model has already failed.
Scope per object and per action, not per system. "Can access ServiceNow" is not a permission model. "Can transition incidents in these categories from in-progress to resolved, cannot modify change requests" is.
Inventory before you scope. Google Cloud's Office of the CISO (2026) describes the shadow agent problem: autonomous systems provisioned outside IT's view, often by a developer automating something tedious. You cannot scope what you have not found, and the agents most likely to be over-permissioned are exactly the ones nobody registered.

Scoping decides what an agent may do. It says nothing about proving what it did.

Logging: can you reconstruct what happened?

Most organizations have logs. Far fewer can answer the question that matters during an incident , which is not "what did the agent do" but "how did this record get into this state, and on whose authority."

The bar for an agent operating on a system of record is reconstruction. From the record itself, you should be able to determine four things.

Which identity acted. The agent, specifically, not the integration account it shares with three other automations.

What triggered it. The event, ticket, message, or schedule that started the run.

What it knew at the time. The inputs available when the decision was made. This is the field teams most often skip, and it is the one that determines whether a post-incident review can distinguish a bad decision from a decision made on bad data.

Whose authority it inherited. Agents act on delegated authority. Someone, at some point, decided this agent could resolve tickets in this category. That decision is part of the audit trail.

There is a practical constraint that gets missed. The log has to be joinable to the record. An excellent audit trail inside the agent platform that cannot be correlated to the ticket is not usable at 2am during an incident, and it is not usable by an auditor sampling records six months later. If your agent platform and your system of record hold separate, unlinkable histories, you have two partial accounts and no complete one.

This is also where the tooling is moving. Microsoft (2026) released an open-source agent governance toolkit aimed at runtime security and mapped explicitly to the OWASP Agentic AI Top 10, which is a reasonable signal that runtime enforcement and evidence capture are being treated as infrastructure rather than policy.

Permissions and logs both assume the agent finishes what it started. The harder question is the one nobody on this topic is answering.

Exception handling: what happens when the agent stops

An agent will hit situations it cannot resolve. The ticket does not match any known pattern. The customer record is missing a required field. The approval exceeds a threshold. Confidence drops below whatever bar was set. What happens to the work item at that moment?

There are four possible behaviors, and each has a distinct failure mode:

Fail open. The agent completes the action anyway, using a default. Fast, and the worst option in a system of record, because it manufactures a business fact from a guess.
Halt and queue. The agent stops and leaves the item in a pending state. Safe for data integrity, and the source of the silent backlog that nobody discovers until a customer escalates.
Escalate to a named human. The item routes to a specific person or queue with the agent's context attached. Correct in most cases, and it only works if the routing target is a real, staffed destination.
Roll back. The agent reverses its partial work and returns the item to its prior state. Cleanest for multi-step actions, and the hardest to build, because it requires every step to be reversible.

The problem in most deployments is not that they chose badly. It is that they did not choose. Exception behavior was never specified, so it resolved to whatever the platform does by default, which in practice usually means the work item sits there.

So the operationally sharp version of the question: if 400 items are stuck in an agent's exception queue at 2am, who is paged, and how do they find out? If the honest answer is that a customer will tell you, the exception design is not finished. And that question has no technical answer, because it is really a question about a person.

Process ownership: someone still owns the work

Automating a process does not vacate its ownership . It changes the job, and organizations are consistently failing to tell anyone that their job changed.

The old version of process ownership was largely about executing and supervising the steps. The new version is about governing a system that executes the steps. Concretely, the owner of an agent-run process now owns four things.

Scope changes come first. When someone proposes expanding what the agent can do, the process owner approves or refuses. This is the highest-leverage control in the entire model, because scope expansion is how a well-governed agent becomes an ungoverned one, one reasonable-sounding increment at a time.

Then the exception queue, including its review cadence and its aging. An exception queue nobody reads is a backlog with better branding.

Then the audit record. Someone has to be able to attest that the agent's actions over a period were within policy. That person is the process owner, not the platform team.

And last, the decision to stop. Pulling an agent out of production is an operational decision with business consequences, and it needs a pre-assigned owner. Made during an incident by whoever happens to be awake, it will be made badly.

The role implications differ across the executive team. For the CIO, the load is identity and evidence: agent identities, scoped permissions, and a joinable audit trail. For the COO, it is exception design and process ownership, meaning who is accountable for the work item when the agent stops. For the CTO, it is the enforcement point and reversibility, meaning where policy is applied at runtime and whether an agent's work can be undone.

At which point the instinct is to write one policy covering all of it. That instinct is the failure mode.

Why one governance policy for every agent backfires

Gartner (2026) is direct about why that fails: enterprises treat agent governance as binary, either locked down or fully trusted, and that binary framing is itself the root cause of failure.

Uniform policy fails in both directions at once. Set the bar at the level a record-writing agent needs, and every read-only agent drowns in approval overhead until teams route around the policy entirely. Set it where a read-only agent is comfortable, and the agent updating your purchase orders inherits controls designed for something that cannot cause harm.

Tier by blast radius instead. A workable first cut has three levels:

Read-only agents. Retrieve, summarize, analyze. Light registration, standard logging, no approval workflow.
Agents writing to non-authoritative stores. Drafts, staging tables, internal notes. Scoped permissions, real audit trail, defined exception behavior.
Agents writing to a system of record. Everything above, plus a named process owner, explicit exception routing, and a scope-change approval path.

The tiers matter more than their exact boundaries, and the boundaries will move once you see your own inventory. What you are buying is the ability to move quickly on the low-risk majority while applying genuine rigor to the small number of agents that can create business facts.

Where to start in the next 90 days

Start where the blast radius is largest rather than where the work is easiest. If nothing in your stack writes to a record yet, this is the sequence to have in place before the first thing does. In practice that means a specific sequence:

Inventory every agent that can write to a system of record. Not all agents. The ones with write access to ITSM, CRM, ERP, HRIS, or customer communications. This list is almost always longer than expected and it is the only list that matters first.
Give each one its own identity. Anything currently running on a shared integration account or a human's credentials gets its own, this quarter.
Define exception behavior explicitly for each. Fail open, halt, escalate, or roll back. Write it down. Name the destination for escalations and confirm someone monitors it.
Name the process owner. A person, not a team. Make sure they know the four things they now own.
Tier the policy. Only after the first four steps, because tiering an inventory you do not have produces a document rather than a control.
Test the reconstruction. Take one completed agent action from last week and try to reconstruct it end to end from the record alone. Whatever you cannot answer is your logging gap, stated precisely.

Most organizations can complete the first four steps in a quarter. The ones that struggle are usually not blocked on technology. They are blocked on the fact that nobody has the authority to inventory agents across four departments, which is an organizational problem wearing a technical costume.

If you want that mapped against your actual stack rather than in the abstract, our Discovery Sprint is a one-week engagement that produces exactly this: the inventory, the permission gaps, the exception design, and a concrete roadmap for the agents already touching your systems of record.

The agents already moved into the record. The controls are what still need to follow them there.

Frequently asked questions

AI agent governance is the set of controls that decide what an autonomous AI agent is allowed to do, enforce those limits while it runs, and produce a record of what it actually did. It governs actions rather than outputs, which is what separates it from earlier AI oversight work.

In practice it rests on four things: a distinct identity for each agent, permissions scoped to specific objects and actions, a runtime enforcement point that can refuse an action before it happens, and an audit trail detailed enough to reconstruct any past action. Governance written only as policy documentation does not qualify, because a document cannot stop an agent mid-action.

The requirement tightens sharply when the agent writes to a system of record such as an ITSM queue, CRM, or ERP, since those writes become business facts that other systems immediately trust.

Model governance asks whether an output is accurate, fair, and safe to ship. Agent governance asks what the system is permitted to do once it can act without waiting for a human, and how you prove what it did.

The control point moves. Model governance operates before deployment, through evaluation, documentation, and review of what the model produces. Agent governance operates at runtime, at the boundary where the agent calls a tool, writes a record, or triggers a transaction.

The risk type also changes. Model risk is output risk, where a bad answer misleads someone who then decides what to do. Agent risk is action risk, where the agent updates the record itself and downstream systems act on it before anyone reviews it. Model governance is still necessary. It is no longer sufficient.

Write access to a system of record raises the control requirement because the agent stops producing suggestions and starts producing business facts. A system of record is the store your organization treats as authoritative, so other systems, reports, and automations consume its values without independently verifying them.

Three consequences follow. Errors propagate quickly and silently into forecasts, communications, and downstream automation. Corrections are expensive, because fixing the record does not undo what already acted on it. And the record itself becomes the evidence you reconstruct incidents from, so gaps in its history are gaps in your investigation.

An agent drafting text in a side panel and an agent closing tickets can run on identical technology. Only the second one needs scoped write permissions, a joinable audit trail, defined exception behavior, and a named process owner before it goes live.

An adequate agent audit trail lets you reconstruct, from the record alone, how it reached its current state and on whose authority. Four elements are the minimum:

Acting identity - the specific agent, not a shared integration account.
Triggering event - the ticket, message, schedule, or record change that started the run.
Decision inputs - what the agent could see at the time, which is what separates a bad decision from a decision made on bad data.
Delegated authority - who approved that this agent could take this class of action.

One practical constraint matters more than the field list: the log must be joinable to the record. An audit trail living only inside the agent platform, with no way to correlate it to the ticket or opportunity, is not usable during an incident or by an auditor sampling records months later.

The agent should escalate to a named human destination with its context attached, and for multi-step actions it should roll back partial work first. What it must never do in a system of record is fail open, meaning complete the action anyway using a default value.

There are four possible behaviors and each fails differently. Fail open manufactures a business fact from a guess. Halt and queue protects data integrity but creates silent backlogs nobody discovers until a customer escalates. Escalation is usually correct, but only when the routing target is a real, staffed queue. Rollback is cleanest and hardest, because every step must be reversible.

Most deployments have not chosen at all. Exception behavior was never specified, so it defaults to whatever the platform does, which in practice means the work item sits there indefinitely.

A single named person, usually the existing business process owner, remains accountable. Automating a process does not vacate its ownership. It changes the job from executing the steps to governing a system that executes them.

Four responsibilities land on that owner. They approve or refuse scope expansions, which is the highest-leverage control available, because a well-governed agent becomes an ungoverned one through a series of reasonable-sounding increments. They review the exception queue on a defined cadence. They can attest that the agent's actions over a period stayed within policy. And they hold the pre-assigned authority to pull the agent out of production.

The common failure is diffusion. When IT owns the platform, a vendor owns the model, and a business unit owns the outcome, no one owns the decision, and that gap surfaces during the first incident.

Start by inventorying every agent that can write to a system of record, not every agent you have. Write access to ITSM, CRM, ERP, HRIS, or customer communications is what determines blast radius, and that list is almost always longer than leadership expects.

A workable first-quarter sequence follows from there: give each of those agents its own identity rather than a shared service account or a borrowed human credential, define its exception behavior explicitly, and name a single accountable process owner. Only then tier your policy by blast radius, because tiering an inventory you do not have produces a document rather than a control.

Finish by testing reconstruction. Take one completed agent action from last week and rebuild it end to end from the record alone. Whatever you cannot answer is your logging gap, stated precisely enough to fix.

Editorial statement

This article was produced with AI assistance and has undergone human review and editorial control. Iryna Tkachuk holds editorial responsibility for its content within the meaning of Article 50(4) of Regulation (EU) 2024/1689.