Agent audit trails won’t answer auditor questions

On October 19, ITWire reported a vendor-sponsored survey of 858 executives, run with CIO Dive and KPMG and fielded in June. In it, 82% of executives believe their organizations can keep pace with governing, integrating, and monitoring AI agents. Just 5% have automated controls, audit trails, and formal human review points in place.

The two figures do not contradict each other, because they measure different things. The 82% is a belief about capability. The 5% counts organizations with all three controls at once, so many more likely have at least one. The survey is self-reported with no published margin of error, so we treat both numbers as indicative.

Our read is that the 5% deserves the closer look, for a reason the survey does not test. An audit trail, as the industry builds it today, records what an agent did. An auditor who samples a decision where two rules applied will ask which rule governed, why it beat the other one, and who decided that. Even a company in the 5% may hold no record that answers those questions.

What the surveys and the audit profession ask for

The rest of this autumn's research points the same way. IBM's EMEA study surveyed 3,221 executives at organizations with 1,000 or more employees, fielded by Censuswide from September 14 to 24, 2026. Asked what agents acting without per-step approval will need by 2027, 32% named defined human escalation thresholds. In the same question, 30% named real-time monitoring and audit trails of agent decisions and actions, and 29% named the ability to halt agent activity across the enterprise.

Auditors are converging on the same controls. In ISACA's guidance on auditing agentic workflows, Eshaan Jain writes that "the absence of adequate logging is itself a finding." His control tests check that escalation conditions are documented, then review logs for escalations that should have occurred but did not.

We agree with all of this, because an agent without logs leaves nothing to audit. The EU AI Act takes the same view in Article 12, which requires high-risk systems to allow automatic recording of events over their lifetime.

Each of these sources describes the audit trail as a record of events, such as inputs, tool calls, outputs, timestamps, and sometimes the person who verified a result. Some identity platforms add the delegation chain, which shows who authorized an agent to act at all, and one industry analysis treats a missing chain as an authorization defect as well as a logging one. None of the sources we read asks for a record of which rule governed when two of them applied.

A deletion request and a legal hold

The following is an illustration, not a case study, built from rules most large companies already have.

1. A customer asks a company to delete their personal data, and a service agent picks up the request.
2. The company's privacy policy says verified deletion requests are completed within 30 days.
3. The customer also has an open billing dispute, and General Counsel has placed a legal hold on records tied to that matter.
4. Retrieval works and returns both the deletion policy and the hold notice.
5. The agent deletes the profile and marketing data, keeps the dispute records, and confirms to the customer.
6. The log records the request, the identity check, the matched records, each deletion call, the retained records, and the reply, all timestamped.
7. The trace adds the model's own note that the dispute records were "retained under legal hold."

Six months later, an internal auditor samples this decision. The log shows that the agent kept the dispute records and deleted everything else. The trace adds one line, "retained under legal hold." To sign off, the auditor needs to know which hold applied, why it covered these records, and who decided that a legal hold overrides a deletion request.

None of those facts is in the agent's record. The hold notice sits in General Counsel's files and ties the hold to the open billing dispute. General Counsel has also set the rule that legal holds take priority over deletion requests. The agent's choice matched both, but its log and trace point to neither. The note "retained under legal hold" does not say which hold, what matter it covers, or whether it was still in force that day. So the auditor sees an agent that kept records past a 30-day deletion deadline, without the legitimate reason it did. Recovering that reason means asking Legal for the hold notice months later and matching its dates to the deletion by hand.

Research on reasoning models gives another reason to be careful with that note. In Anthropic's tests, researchers planted a hint in the prompt and then looked at the cases where the hint changed the model's answer. The model's written reasoning admitted using the hint on average only 25% of the time for Claude 3.7 Sonnet and 39% for DeepSeek R1. The rest of the time, it gave other reasons. That work measures how reliable model explanations are, and no regulator has ruled on them as evidence, but it is reason enough not to treat generated text as the record.

We call the missing artifact the decision record: the governing rule, the reason it beat the other rule that applied, and the person who set that order. Our last post argued that retrieval can surface both rules without picking the winner, and the decision record is where that pick gets written down.

Our position: when two rules apply to an agent action, the record of which one governs, and why, should exist before the agent acts, because nothing written afterward can reliably reconstruct it.

Why the question reaches the board

Regulation already asks for the reason. Under Article 86 of the EU AI Act, a person affected by a decision based on a high-risk system's output can obtain an explanation from the deployer. That explanation covers the system's role and the main elements of the decision. Article 12 asks only for event logs, so in our reading the law owes an explanation that the required logs do not contain.

Regulators have already fined a company over a missing explanation. In September 2025, the Hamburg data protection authority announced a EUR 492,000 fine against a financial-services provider, according to Clyde & Co. Its automated system rejected credit-card applicants with good creditworthiness and could not adequately explain its logic when they asked. That system was not an LLM agent, though the gap the regulator found is the one an agent's log would leave.

Banks are hearing a version of the question too. Reuters reported on October 13, citing six people familiar with the matter, that the OCC, FDIC, and Fed are asking banks whether they can track and audit the decisions their AI agents make, and how they would shut those systems down. The ECB has separately asked euro-zone banks to map their AI use and show they can switch systems off and restart them in a controlled manner. In April, the agencies replaced SR 11-7, their model risk guidance since 2011, with SR 26-2. Its attachment says generative and agentic AI models "are not within the scope of this guidance," so the questions are arriving ahead of a written standard.

For most CIOs, the question arrives through the board. In IBM's study, 80% of organizations said an AI-related incident reached their board or C-suite in the past year. Only 40% of those changed their governance policy or framework. Our read is that a director asks why the agent acted somewhere between those two steps, and a log of actions can offer a timeline but not a reason.

What to do on Monday

1. Run the three-field test. Pull ten recent agent decisions where more than one rule applied. For each, fill in the governing rule, why it beat the other rule, and who set that precedence, using only records that existed when the agent acted.
2. Ask where the reason comes from. Ask each vendor whether the reason attached to an agent decision is written by a rule store before the action, or generated by the model during or after it.
3. Ask the conflict question. Put this to your team and your vendors: "Two of your rules both apply to this request and they disagree. What does your system return, and what does it write down?"
4. Name the precedence owners. For each agent workflow, find the person who decides today which rule wins, such as General Counsel for legal holds. If nobody can be named, start there, because a decision record needs an owner who set the order.

Where Trail fits

Trail is the context layer your agents run on, and precedence is the problem we built it around. Rules and exceptions are nodes, dependencies and overrides are edges, and the reason each rule exists is stored on its node. The agent consults Trail before it acts, so the record of which rule governs exists at the moment of action and never has to be reconstructed from a log.

In the deletion example, the legal hold is a node with an override edge to the 30-day deletion rule. That edge is scoped to records tied to an open matter and was set by General Counsel. Trail returns the hold as the governing rule for the dispute records and the deletion rule for everything else, citing both and explaining why the hold applies. The agent's log entry then points to a decision record that already existed.

When two rules conflict and no precedence is set, Trail asks a person instead of leaving the choice to the model. Approvals, overrides, and exceptions from live runs feed back so the rules stay current. Trail sits alongside your retrieval over MCP, native retrievers, or REST and GraphQL, or you can build the agent on Trail directly.

What this means for next year's governance budget

IBM's respondents expect to need audit trails, monitoring, and the ability to halt agents by 2027, and those are reasonable places to spend. When you scope that work, put the decision record in the same requirement as the log. Logging can be extended after launch, but the reason behind a decision an agent already made cannot be recovered later. For any agent that acts where two of your rules apply, plan for the record of which rule governed to be in place before that agent goes live.