Decision Tracing: The Missing Piece in Every AI Agent Breach

When an agent goes rogue, prompt filters are useless. You need a replayable record of every decision, tool call, and the reasoning that fired them.

TL;DR: Decision tracing is the part of AI agent incident response nobody instruments for. When an agent goes sideways, the questions are simple: what did it do, why, and what did it touch. Most teams can’t answer one of them, because agents ship with heartbeat logging that records the tool calls and throws away the reasoning. The test is brutal. If jumping from an alert to the bad decision takes half an hour of grep, you don’t have tracing.

Why AI Agent Incident Response Breaks the Old Playbook

Start with the tools you already have. Every signal a SOC was built on watches for the same thing: something acting out of character. Weird packet, off-hours login, a process that shouldn’t be running. That’s the whole model. Anomaly detection assumes the bad thing looks different from the good thing.

An agent breaks that assumption on contact. It logs in as itself, with its own credentials, holding tools you handed it on purpose. Then it does something catastrophic while looking completely authorized. There’s no weird packet. The breach is a confidently wrong decision buried in fifty tool calls that all returned HTTP 200.

And the autonomy makes the aftermath worse. A human attacker leaves a session you can walk back. An agent runs a multi-step plan where step nine only makes sense once you see that step three read a poisoned doc and quietly rewrote the objective. Miss that causal thread and you’ve got a pile of successful API calls and no story. The same instruction-data conflation behind every agentic attack chain we’ve mapped is the thing that makes the incident unreadable after the fact.

What “We Have Logs” Actually Misses

“We have logs” is the sentence that sounds fine right up until the incident starts. Most agent logging captures the heartbeat. Agent ran. Tool called. Response returned. Clean rows, all green, easy to ship to a SIEM.

What it skips is the part that decides the investigation, which is the decision path. Why did the agent pick that tool? What was in context when it did? What did the retrieval layer feed it right before it went off the rails? None of that lives in a status code.

Look at the difference:

# heartbeat logging: what most agents give you
[02:14:07] agent.run       status=200
[02:14:09] tool.call       name=db_query      status=200
[02:14:09] tool.call       name=db_delete     status=200
[02:14:10] tool.call       name=backup_purge  status=200
[02:14:11] agent.complete  status=200

# decision tracing: the line that actually holds the case
[02:14:09] reasoning -> "staging creds rejected. resolving by
           removing the conflicting volume to retry clean."
           context_source=<unrelated_config_file>

Every line up top returned 200. Every line up top is useless. The bottom block is the whole investigation, and standard logging drops it before the pager even goes off. That’s the split. One tells you an event happened. The other tells you why the machine chose it. Only one of them survives contact with a real incident.

The 30-Minute Test Your Logging Probably Fails

Here’s a test you can run against your own stack this afternoon. Start from an alert. Now try to jump straight to the branch where the agent chose the wrong tool, passed a malformed argument, or ran out of context before a critical step.

How long does that jump take? If the honest answer is thirty minutes of grepping across log streams and stitching timestamps by hand, you don’t have decision-path tracing. You have logs, and a lot of patience.

The gap isn’t volume. Teams drowning in telemetry fail this test constantly, because none of it is wired to the reasoning. Tracing means the causal chain is queryable: alert, to decision, to the context that produced it, in one hop. That’s the bar. Most teams sit well under it and don’t find out until the worst possible morning. A few tells that you’re logging blind instead of tracing:

• No context snapshot. You can see the tool fired, but not what the agent was holding when it decided to fire it. The retrieval payload, the prior tool output, the poisoned doc, all gone.

• No intent field. The log says db_delete ran. It never says the agent believed it was resolving a credential mismatch. The plan is invisible.

• No replay. You can read events but you can’t re-run the decision to watch where it forked. Forensics becomes reconstruction from receipts.

That last one isn’t hypothetical. Somebody already lived it.

When Forensics Turns Into Archaeology

On April 25, 2026, a Cursor coding agent running Claude Opus 4.6 deleted the entire production database at PocketOS, a platform that runs reservation data for car rental shops across the country. Every backup went with it. Nine seconds, start to finish, before a human could’ve finished reading the first alert.

The agent was on a routine staging task. It hit a credential mismatch and decided, on its own, to “fix” it by deleting a Railway volume. To pull that off it went hunting for a token, found a standing credential sitting in an unrelated config file that existed only for domain management, and used it. Every call was authorized. Every call returned success. Nothing in the network telemetry looked wrong, because by the only definition the stack understood, nothing was.

Now the part that should stay with you. Founder Jer Crane spent the weekend rebuilding customer bookings by hand, cross-referencing Stripe payment records against email confirmations, because that was the only surviving evidence of what the system had done. Read that again. The authoritative record of the agent’s actions got reconstructed from credit card receipts.

The decision trail, the reasoning that turned “creds rejected” into “purge everything,” was never captured anywhere. He wasn’t doing forensics. He was doing archaeology.

And the clock on this is legal now, not just operational. The EU AI Act’s Article 12 makes automatic event logging mandatory for high-risk systems on August 2, 2026, with penalties running to fifteen million euros or three percent of global turnover. The teams flying blind into the incident are flying blind into the audit on the same instrument panel. When the regulator asks what the agent did and the honest answer is “we pulled it off Stripe,” that’s not a finding.

Up next: steps you can take right now and a field-ready security prompt. Thanks for rolling with ToxSec. Let’s get operational.