AI agent incident response is the work of proving what an agent did, whether it was authorized, and how to stop it recurring.

An agent acted outside what you intended. The questions that follow are always the same — what did it do, who allowed it, how far did it reach, and can you prove any of it. This page is the first hour, and the honest diagnosis that usually follows.

Get an Agent Trust Gap Brief

The first hour

Written for the person who has just been told an agent did something unexpected and does not yet know how bad it is.

Contain. Revoke the agent's grants. Halt the class of action, not just the one agent — if one agent found the gap, its siblings can too.
Preserve. Freeze receipts, logs and queue state before anyone redeploys. The instinct to fix first is what destroys the record.
Bound it. How many actions, over what window, to which targets, at what value. A blast radius you can state in one sentence changes every conversation that follows.
Establish authorization. Was this action allowed, or merely unstopped? Those are different incidents with different fixes.
Reconstruct. Replay the sequence — beliefs, options considered, the decision, the gates, the effect.
Then decide on disclosure. With counsel, on facts, not on the first hour's panic.

Six incidents that keep recurring

Acted outside scope

The agent did something real and defensible — just not something anyone authorized it to do. Usually a permission granted for a pilot and never narrowed.

Sent the same thing twice

A retry without an idempotency key. Cheap to prevent, expensive to explain to a customer who received it four times.

Runaway spend

A loop, a throttle instead of a cap, and no receipt at the ceiling. Discovered on the invoice.

Bypassed approval

A path to the effect that did not run through the gate. Usually a legacy code path nobody remembered was still wired.

Goal drift

Instructions arrived through retrieved content or tool output and the agent had no reason to distrust them. OWASP ASI01 and ASI06.

Cascading failure

One agent's bad output became another's trusted input. ASI08 — the failure mode that turns an incident into an outage.

Direct answers

My AI agent did something it should not have. What do I do first?

Contain before you investigate. Revoke the agent's grants and halt the class of action it took, then preserve evidence before anything is redeployed. Most damage after the first incident comes from a rushed fix that destroys the record of what happened.

How do I find out what an AI agent actually did?

If execution receipts exist, replay the sequence: the identity, the policy version in force, the approval if any, the payload hash, the provider response, the outcome. If only application logs exist, you are reconstructing intent from side effects, which is slow and rarely conclusive.

Can an AI agent's actions be attributed to a specific person?

Only if the agent held its own identity with a named human owner. If several agents shared one credential, attribution is impossible by construction and no amount of log analysis afterwards will recover it.

How fast should revocation take effect?

The only meaningful specification is measured time-to-effect on a tested path. Revoking a grant that the downstream service caches for an hour is not revocation, it is a delay.

Do we have to report an AI agent incident?

It depends on jurisdiction, sector and what the agent touched. Under the EU AI Act, serious-incident reporting obligations attach to certain systems. Sector regulators impose their own. This is a question for counsel, not for a vendor page.

The uncomfortable finding, most of the time

In most first incidents the control that failed was never actually present. The agent was not permitted to act — nothing stopped it. Those look identical right up until someone asks for proof, and then they are completely different answers.

Which is why the post-incident work is rarely "patch the agent." It is: give it an identity, put a gate in front of the effect, and make the next action produce a receipt. The Agent Trust Gap Brief is the version of that you can run before an incident rather than after.