AI Agent Post-Mortems Blame the Model. The Credentials Did It.

Post-mortems are supposed to find root causes. For AI agent incidents, they usually find the wrong one.

The language in these write-ups tends toward model behavior: the agent “hallucinated,” it “misunderstood the prompt,” it “took an unexpected action.” That framing makes teams feel like they analyzed something. It doesn’t change anything, because the next agent they deploy will have the same underlying problem.

That problem is almost always credential scope.

What the Pattern Actually Looks Like

Four failure modes keep showing up across AI agent incidents. They look different on the surface. Underneath, they’re the same problem.

Credential overreach. The agent has a token with write, delete, or admin permissions it never needed for the task at hand. When the task deviates from the happy path, those extra permissions become the blast radius.

A repo maintenance agent with write and delete access to production S3 is one small logic error away from a serious incident. The agent doesn’t need write access to flag stale files. It doesn’t need delete access to report on disk usage. The permissions were granted because they were convenient, not because they were required.

Tool chaining gone wrong. Multi-step pipelines pass outputs between tools without sanitizing what that output could trigger downstream. A tool call that succeeds unexpectedly feeds into the next step. That step has broader permissions. Something gets written to the wrong place, or deleted, or exposed.

The individual tools look fine in isolation. The credential scope for each tool looks reasonable in isolation. The combination is where the problem lives.

Persistent token abuse. Setup is the most dangerous moment in an agent’s lifecycle, because that’s when engineers provision credentials in a hurry. The token created at midnight during a sprint is still active six months later, when nobody remembers which agent it belongs to or what it was originally scoped for.

Long-lived tokens don’t stay contained. They get copied between environments, added to other agents’ configs, and inherited by successor systems. Their original scope becomes meaningless over time.

Silent escalation. The agent requests additional permissions mid-run. The user approves without reading the scope carefully. The authorization log shows approval, which looks fine in the post-mortem. The actual scope change is buried in a multi-screen OAuth prompt that nobody examined.

This one is particularly hard to catch because the audit trail shows “user approved.” What it doesn’t show is that the approval was uninformed.

Three Incidents That Illustrate the Problem

These are composite cases drawn from publicly documented incidents and anonymized reports. The details are reconstructed, but the failure pattern is real.

The cleanup agent. A team deployed an agent to archive old files. It was given the same service account used by the deployment pipeline, because that account already had the right access to the relevant S3 buckets. The agent ran in test mode for two weeks without issues.

On day fifteen, a configuration flag was set incorrectly and the agent ran against production. It had delete permissions because the deployment pipeline needed delete permissions. The post-mortem blamed the configuration flag. The actual issue was that a file archival agent had no business holding delete access to production buckets.

The onboarding bot. An agent that provisioned developer access was built on top of a service token with admin-level IAM permissions. Easier to provision that way during the prototype phase. The prototype shipped.

A malicious ticket description contained a prompt injection that instructed the agent to create a new IAM user with console access. The agent complied. The post-mortem called it a prompt injection incident. It was, but the injection only worked because the token had permissions it shouldn’t have had.

The data sync agent. A billing sync agent had read access to the full customer table. It only needed three fields to do its job. A bug in the transformation logic caused it to pass the full table into an outbound webhook payload. Several thousand customer records left the system.

The post-mortem focused on the transformation bug. Fixing the bug doesn’t fix the fact that the agent had access to data it never needed.

What the Post-Mortems Miss

Incident analysis for AI agents tends to focus on the observable failure: the specific action taken, the specific output produced, the specific configuration that was wrong. Teams fix the immediate cause and move on.

They rarely ask why the agent had the permissions it used. That question leads somewhere uncomfortable: the agent was given broad credentials because provisioning narrow ones takes effort, and nobody thought the agent would fail in that specific way.

The real finding in most of these post-mortems is that credential provisioning for AI agents is done by intuition, not by policy. Engineers copy existing service accounts. They grant permissions that seem “safe enough.” They don’t model the blast radius of the credentials they’re issuing.

A post-mortem that doesn’t include “which credentials did this agent hold, and were they necessary” is not a complete post-mortem.

What the Fix Actually Requires

Least privilege for AI agents is harder than least privilege for traditional services. The agent’s permission requirements can change based on the task it’s asked to perform, the tools it calls, and the runtime context it operates in. Static service account permissions don’t map well to dynamic agent behavior.

Two patterns address this directly.

Session-scoped credentials mean the agent gets a token that lives only as long as the run. When the job finishes, the token expires. There’s no window for persistent token abuse because the token doesn’t persist. A compromised agent run is contained to that run.

Phantom tokens mean the agent never holds the real credential. A proxy layer intercepts outbound requests and injects the real key at the boundary. The agent’s context window, its logs, its memory — none of them contain anything an attacker could use. Even a fully compromised agent can’t exfiltrate credentials it never held.

Neither pattern prevents bad prompts or logic errors. They reduce the blast radius when something goes wrong. They’re not a substitute for monitoring or code review. They’re the layer that makes the other mitigations actually effective.

The Post-Mortem Checklist That’s Missing

When an AI agent incident happens, these questions should be in the post-mortem:

• What credentials did the agent hold at the time of the incident?
• Were those credentials necessary for the task that triggered the incident?
• How long had those credentials been active?
• Could a session-scoped token have expired before the damage occurred?
• Did the agent’s credential scope match its intended task scope, or was it inherited from a broader service account?
• How many other agents share the same credentials?

Most incident templates for API failures don’t include these questions. Teams pull in a standard template, write it up, and close the ticket. The next agent they build has the same credential architecture.

The pattern repeats because the post-mortem didn’t reach the part of the system where the actual fix lives.

That part is the credential layer. Session-scoped, phantom-token-based, audited at every step. That’s what makes the next post-mortem different from the last one.