How to respond to an AI agent incident

An AI agent incident can take several forms. An agent sends data to a service it should not reach. It calls a tool outside its job, follows instructions hidden in a document, or runs up a large bill in a loop.

AI agent incident response follows the shape of other security incidents, with a few differences. Agents act quickly, use delegated credentials, and may keep running on a schedule while you investigate. A plan needs to account for each of those, and it works best when the team has rehearsed it.

This post walks through five steps.

Contain

The first goal is to stop further harm while keeping the agent available for examination. Deleting the agent destroys the record.

Three questions guide the first minutes.

• Is the agent still acting, on a schedule or in a live session?
• Can it still reach external systems?
• Does it still hold credentials that work?

Any yes calls for containment right away, and the details can wait. Use the actions below.

• Quarantine the agent. In Halo's secure agent runtime, operators can quarantine and release agents, so the agent stops acting while you investigate.
• Pause what depends on it. Pause scheduled work and stop active deployments that rely on the agent. Budget actions can pause new operations or stop active deployments when spend is the problem.
• Define the blast radius. List the models, tools, apps, and data the agent could reach, using its identity and policy record.

Decide in advance who has the authority to quarantine. People hesitate when the agent belongs to another team.

Contain first, and keep the agent's configuration and records intact for the review.

Preserve evidence

Capture the record before you change anything else. Fixes overwrite state, and evidence ages quickly.

• Export the audit logs and gateway decisions for the agent and the time window. Halo exports them as CSV and JSON.
• Record the agent's configuration, the policy versions in effect, and the identity of the delegating user.
• Note the approvals that were granted, and by whom.
• Collect logs from the connected apps the agent used, such as messaging or code hosting tools, since those systems hold their own records.

Write down what you did and when. The response timeline becomes part of the incident record.

Revoke and rotate

Credentials come next. When provider and app credentials stay bound at the gateway, and agents receive scoped capabilities and never see raw keys, revocation is a change at one point. Remove the agent's capabilities and confirm that its calls are denied.

Rotate any credential that may have been exposed elsewhere, such as a shared key that lived in a configuration file or a chat message. Review what the agent could do in connected apps, and look for changes you need to undo.

Review

Reconstruct the timeline from the records. For each step, ask what the agent was asked to do, which decision the policy made, and who approved it. Then classify the cause.

• Policy gap. The action was permitted because no rule covered it.
• Scope too broad. The agent held permissions its job did not need.
• Untrusted input. Instructions came from content the agent read, such as a document or a tool result.
• Change. A new tool, model, or configuration altered behavior after the last review.
• Missing coverage. The activity took a path that no control watched.

For example, an agent that summarizes shared documents might follow a hidden instruction in one document and post the summary to an external channel. The review would find untrusted input as the trigger and a scope that allowed external posting without approval as the gap.

Include the people who own the agent and the people who own the affected data. Decisions about notifying customers, regulators, or affected individuals belong to your legal and privacy teams under your own incident process, so bring them in early.

Recover

Release the agent only after a fix is in place and tested. Release it with a smaller scope first, such as read-only tools, human approval on writes, and a lower budget.

Verify the fix with a replay. Recreate the failing case with synthetic data and confirm that policy now denies or escalates it. Close the incident after the check passes, and keep the test as part of your drills.

Then update the control. Put the lesson into a versioned policy change, and share a summary with the teams that run similar agents.

After release, watch the agent closely. Keep approvals on for a trial period, and compare its decisions with the pre-incident baseline in the decision timeseries.

Assign roles before the incident

Agent incidents cross teams, so name the roles ahead of time.

• Incident lead. Runs the response and decides on containment.
• Agent owner. Explains what the agent was for and what it should have done.
• Platform operator. Quarantines the agent, revokes capabilities, and exports records.
• Data owner. Judges what the affected data means for the business.
• Legal and privacy contacts. Decide on notifications under your own process.

Write the names and the backup names somewhere people can find them during an incident.

Practice before you need it

Run a drill on a low-risk agent each quarter. Time how long it takes from the decision to quarantine to the last permitted call.

Confirm that the evidence export works and that the right people can run it. Treat what you find as a backlog item with an owner.

The post on giving agents identities you can revoke covers the identity records that make the first minutes easier.

How Halo helps

Halo's secure agent runtime gives operators quarantine and release controls and runs agents with default-deny network egress. Credential brokering keeps credentials at the gateway for central revocation, and audit logs and gateway decisions export as CSV and JSON for the review. Read about AI agent governance or book a walkthrough to rehearse a response with your own scenario.