A Decision Trace Is Not a Log
The record your security team actually needs can only be produced from one architectural position. And almost nobody is in it.
In the last two pieces, I identified a problem — the unattested agent — and a principle: the entity that acts cannot be the entity that attests.
I want to ensure we all agree. Yes, the attestation gap is genuine. Yes, agents are self-reporting. Yes, we require independence.
Then the follow-up question: “Okay, so what should the record actually look like?”
That’s the right question. And the answer is more specific than most people realize — because the record you need isn’t just different in content from a traditional log. It’s different in kind. It can only be produced from one architectural position — and it’s the one the industry keeps overlooking.
Let’s start with what you have today.
When an AI agent makes a tool call: reads a file, queries a database, sends an email, calls an API, the platform may log something. Even a well-instrumented platform log looks like this:
Timestamp. Agent name. Tool called. Parameters passed. Response code. Latency.
That’s helpful. It explains what occurred, approximately when, and if it was successful.
Now, try to answer these questions from that log:
Who authorized this action? Not the human who deployed the agent three weeks ago. Who — or what policy — authorized this specific tool call at this specific moment?
Was this agent permitted to call this tool with these parameters? Not “does the agent have API access.” Was this particular call to this particular resource evaluated against a policy before it executed?
What was the agent’s identity context at the time of the call? What role was it operating under? What permissions were active? What risk tier had it been assigned? Had its behavioral baseline shifted?
Was there sensitive data in the request or response? Was the payload scanned? What was found? What classification was applied? Was anything redacted, blocked, or flagged before it reached its destination?
What happened immediately before and after this call? Not in the same log file. In the causal chain. What triggered this action? What did the agent do with the result? Was this the first step in a sequence that ended somewhere it shouldn’t have?
If this agent was operating as part of a multi-agent workflow, who delegated the task? Was the delegation authorized? Did the delegating agent have the authority to grant those permissions? Can you trace the chain of authority back to a human decision?
A platform log answers none of these. Not because the platform is poorly built. Because the platform isn’t in the right position to capture any of it.
This is the distinction that matters, and it’s the one the industry keeps undermining.
A log is a record of what happened. It’s produced by the system that performed the action. It captures the system’s own view of what it did.
A decision trace is a record of what happened, why it was allowed to happen, who authorized it, what policy governed it, what data context surrounded it, and where it sits in a causal chain of actions.
A log is a line in a file. A decision trace is a chain of custody.
A log tells you the agent called read_file on /payroll/salaries.csv at 14:23:11 and got a 200 response.
A decision trace tells you:
The agent hr-assistant-03 — operating under role hr-read-only, with a current behavioral anomaly score of 0.3, in an active session authenticated 14 minutes ago made a read_file call targeting /payroll/salaries.csv.
The call was evaluated against policy filesystem.sensitive_read by an independent policy engine. The agent’s role includes filesystem:read but not filesystem:sensitive_read. The policy result was escalate. A human-in-the-loop notification was sent to the designated approver.
Approval was received 47 seconds later. The file contents were scanned for sensitive data; matches were found for patterns ssn and salary with severity critical. The response payload was classified as GOVERNMENT_ID and FINANCIAL. The payload was delivered to the agent with matched values redacted. The action was the third in a causal chain initiated by a user request through the hr-portal interface, with requester identity verified via delegation token.
The full chain: from user request to orchestrator to agent to tool call to policy evaluation to data classification to redaction to delivery is linked by causal parent IDs and independently hashable for integrity verification.
That is not a log. That is a decision trace.
And there is no way to produce it from inside the acting system, not from the agent, not from the platform, not from telemetry aggregated after the fact.
This is the point where I need to be very precise, because the architectural argument is everything.
A decision trace requires six things to be captured at the moment of action, not reconstructed afterward, not inferred from logs, not assembled by a SIEM.
Identity context. Not just “which agent.” The agent’s authenticated identity, its active role, its permission set, its risk tier, and its behavioral anomaly score at the time of the call. This requires an identity service that operates independently of the agent platform.
Policy evaluation. The specific policy rule that governed this call, the inputs to the evaluation, and the result — allow, deny, or escalate. This requires a policy engine that evaluates every action before its execution, not a scanner that reviews actions after the fact.
Data classification. Whether the request or response contained sensitive data, which patterns were matched, what severity was assigned, and what action was taken — redaction, blocking, or passthrough. This requires a data protection layer that inspects payloads in transit, not a DLP tool that scans storage at rest.
Causal linkage. Where this action sits in a chain of prior actions, what triggered it, and what the agent did with the result. If it’s part of a multi-agent workflow, identify which agent delegated the task and whether that delegation was authorized. This requires an observer who can track every action in the chain, not just the starting and ending points.
Requester provenance. Who or what initiated the chain of actions leading to this call? A human user? Another agent? An automated trigger? And is that identity verified or just asserted? This needs requester tracking that is independent of the agent’s own reporting.
Integrity chain. A cryptographic linkage — hash chains or signed records—that makes the decision trace tamper-evident. If any event in the chain is modified, inserted, or deleted, the integrity is broken and tampering becomes detectable. This requires the record to be produced and stored by an entity that the agent cannot influence.
These six elements are not just a wish list. They are the essential requirements for a record that a regulator, an auditor, or a plaintiff’s attorney would accept as credible evidence of governance.
And every one of them requires the same architectural precondition: an independent observer positioned in the execution path between the agent and the systems it acts on.
This is why the architectural position matters more than the tooling.
A SIEM can store a decision trace. It cannot produce one. A SIEM receives whatever the upstream source chooses to emit. If the upstream source is the agent’s own platform, the SIEM is storing a self-report — durably, securely, immutably. You’re still storing the testimony of an untrusted witness — just more reliably.
An EDR tool can detect that an application made a network call. It cannot tell you whether the policy engine evaluated the call before execution, what data classification was applied to the payload, or whether the agent’s delegation authority was valid for that specific action. EDR instruments the operating system. A decision trace requires instrumenting the decision.
A platform’s native logging can be detailed, timestamped, and well-structured. It still cannot produce an independent record, because the platform is part of the acting system. The platform decided to log what it logged. The platform decided what to include and what to omit. The platform’s own integrity is the issue.
The only place a decision trace can be produced is at an independent checkpoint in the execution path — a point where every action passes through, where policy is evaluated before execution, where payloads are inspected in transit, where identity is verified externally, and where the record is written by something the agent cannot touch.
That’s not a design preference. It’s a structural requirement. The same way a black box must be in the aircraft — not in the airline’s back office reading the pilot’s notes — the attestation layer must be in the execution path. There is no other position from which a decision trace is producible.
I want to make this tangible, because “structural requirement” can sound theoretical. It’s not.
Consider an incident investigation.
An AI agent with access to your CRM exported a list of customer records and sent them to an external API endpoint. Your security team gets the alert.
With a log, you know the agent made the call. Maybe you know the timestamp and the destination. You pull the platform log. It says tool: http_post, target: https://api.external-service.com/ingest, status: 200. You don’t know what was in the payload. You don’t know whether the agent was authorized to make external API calls. You don’t know whether anyone approved it. You don’t know if the data contained PII. You don’t know whether this was part of a legitimate workflow or a compromise. Your investigation is a reconstruction exercise — pulling fragments from multiple sources, hoping the pieces fit, knowing that the primary source of evidence is the system you’re investigating.
With a decision trace, the picture is immediate and complete. The agent was authenticated under identity crm-sync-agent-07, operating under role crm-read, which does not include web:write permission. The policy engine evaluated the http_post call against policy web_api.deny_post and returned deny. The action was blocked before execution. The attempted payload was scanned; matches for email_address and phone_number were found with severity high, classified as PII. The causal chain shows this was the fourth action in a session initiated by an unverified requester. An alert was generated. The full chain is hash-linked and tamper-evident.
The incident investigation didn’t happen after the breach. It happened instead of the breach.
That’s the difference between a log and a decision trace. One helps you understand what went wrong. The other prevents the wrong thing from happening and proves that it did.
There’s one more point I want to make, because it’s the one that connects everything in this series.
A decision trace is not just a better record. It is the artifact that makes governance demonstrable.
When a regulator asks “How do you govern your AI agents?” the decision trace is the answer. Not “we have policies.” Not “we have logs.” Not “we have a dashboard.” A decision trace is a producible, auditable, cryptographically linked chain of evidence that shows: this agent, with this identity, under this policy, took this action, with this data context, authorized by this entity, and the record was produced independently by an observer the agent could not influence.
That is what demonstrable governance looks like. And it’s what every compliance framework — SOC 2, EU AI Act, NIST AI RMF — is going to demand once regulators understand what autonomous agents actually are.
The log tells you something happened. The decision trace proves what happened, proves why it was allowed, and proves who authorized it — with evidence the agent itself cannot dispute.
The entity that acts cannot attest. The decision trace is what the independent attestor produces.
And if you don’t have one, you don’t have governance. You have documentation.
Next in this series: why the only architectural position from which enforcement and attestation are possible is inline — in the execution path — and why every other approach is structurally incapable of governing autonomous behavior.