How to Respond to an AI Agent Security Incident

Quick answer
Contain first: stop the run, revoke the credential, and block the destination before investigating.
Preserve the audit trail and the session transcript before they rotate out of retention.
Scope the exposure by identity: what could this credential reach, and what did it actually touch?
Assume any secret read into context is exposed, even if nothing was committed.
Fix the control that failed — scope, egress, or approval — rather than adding a warning to the prompt.

What are the first five minutes?

Stop the run and revoke the identity it used. If the destination is known, block it at the proxy or firewall. Do not spend the first minutes reading the transcript while the credential is still valid; a live credential is the difference between an incident and a breach.

Then snapshot the evidence: the audit log, the tool calls, the session transcript, and the repository state. Preserve it before anything is cleaned up, because the cleanup is what destroys the timeline.

# Contain (order matters)
agentctl stop --run "$RUN_ID"
agentctl revoke --identity "$AGENT_ID"
# Preserve
cp agent-audit.jsonl incident-$RUN_ID-audit.jsonl
git log --since="2 hours ago" --stat > incident-$RUN_ID-repo.txt
# Then scope
jq -r 'select(.run_id=="'"$RUN_ID"'") | [.ts,.tool,.host,.bytes] | @tsv' incident-$RUN_ID-audit.jsonl

How do you scope the exposure?

Start from the identity: every resource it could reach is in scope, whether or not the log shows access. Then narrow to what the log shows it touched, including reads of sensitive data that did not leave the machine.

If a secret entered the model’s context, treat it as exposed to the provider and rotate it. You cannot prove it was not retained, and the cost of rotation is lower than the cost of assuming it is safe.

What do people get wrong in the response?

They fix the prompt. A stronger instruction is not a control, and a model that was convinced once can be convinced again. The durable fix changes authority: smaller scope, narrower egress, approval for external actions.

They also treat the agent as the whole incident. An agent that acted on a shared credential implies the credential was too broad, the logs were insufficient, or an approval step was missing. Those are the findings that matter.

What goes in the post-incident review?

A timeline from the audit log, the action that caused the exposure, the control that should have stopped it, and the change that now does. Include whether any human approval was requested and what it showed, because an approval that was granted blindly is its own finding.

Add a test to the prevention set: a policy check that fails if the credential has the scope, or a canary that alerts when the destination is contacted. A review without a regression control is a story, not a fix.

Where this bites vibecoders
The instinct is to delete the branch, uninstall the skill, and move on. That removes evidence and leaves the credential live. Contain, preserve, scope, rotate, then fix the boundary — in that order.

Where AI coding assistants get this wrong

Reading the transcript before revoking the credential.
Deleting the branch or the session before preserving evidence.
Rotating one token without checking what else the identity could reach.
Fixing the prompt instead of the permissions.
Assuming nothing left because the repository looks clean.
Skipping the approval step review when an approval was granted.

Checklist

Stop the run and revoke the identity.
Block the destination if known.
Preserve audit log and repository state.
Scope by identity, then by observed access.
Rotate every secret that entered context.
Fix and test the control that failed.

FAQ

Is this a personal-data breach?

Depends on what the agent could read and what left. Apply the same classification you would for a human actor: which data, how much, to whom, and with what safeguards. The agent’s identity does not change the legal analysis.

Do I need to tell the model provider?

Follow your contract and their policy. You can confirm what was sent from your own logs. The provider will not be able to remove a specific request from its systems on request in most cases, which is why rotation matters more than notification.

How do I know the run was actually malicious?

You often cannot prove intent, and it does not change the response. If the action was outside the task’s scope and the credential could do damage, treat it as an incident regardless of whether a person or a document caused it.

What if we have no audit log?

Then scope from the credential and the diff, and treat the exposure as the full reach of that identity. The absence of a log is itself a finding, and the first remediation is logging before the next write-capable run.