Stop the agent first, then revoke its credentials, preserve logs, revert the change in version control, rotate any secret it could have read, and review what else it touched. Do the steps in that order, because containment comes before cleanup and evidence disappears quickly.
What counts as harmful
Harm from a coding agent usually falls into one of these bins: a bad change merged or deployed, a secret read or sent out, a dependency added that should not be there, a destructive command run, or a change to pipeline or permission files. The runbook below covers all five, with notes where they differ.
The runbook
- Stop the session. Kill the process, close the terminal, or disable the tool for that user through your admin controls. If the agent runs in CI, cancel the job and pause the schedule.
- Revoke access. Revoke the tokens the agent used, not just the session. If it ran under a developer's personal credentials, rotate those. This is the point where having a separate identity for agents pays off, since you can disable one identity without disrupting a person.
- Preserve evidence. Copy the agent's action log, terminal history, and the pull request or branch state before anyone cleans up. Our post on what an agent audit log should contain lists the fields worth keeping.
- Revert in version control. Use a revert commit so history stays honest. Do not rewrite shared history to hide the change, because that destroys the trail you just saved.
- Rotate exposed secrets. If the agent could read a credential file or environment, treat the credential as exposed. Rotate it. Short lived tokens make this routine.
- Check the blast radius. Look at every action in the session, not only the one that triggered the alarm. Search for new dependencies, edits to pipeline files, new remotes, and network calls to unfamiliar hosts.
- Record and learn. Write a short post incident note: what happened, which control should have stopped it, and what changes now.
Differences by harm type
| Harm | Extra step |
|---|---|
| Merged bad code | Check what deployed, and roll back the deployment as well as the commit |
| Secret exposure | Review provider logs for use of the secret since the exposure |
| Bad dependency | Remove it, regenerate the lockfile, and scan the build output |
| Destructive command | Restore from backup, then confirm backups work |
| Pipeline change | Review all runs since the change, and audit artifacts built in that window |
Why this goes wrong in practice
Teams usually fail at step two. The agent used a shared token, so revoking it breaks everyone's work, and the response stalls while people debate. A scoped, agent specific credential with a documented owner makes the decision easy.
The second failure is step three. Someone fixes the problem, and the log that would have shown the cause is gone or overwritten.
Rehearse it
Run a short tabletop. Plant a harmless harmful action, such as a new dependency with a made up name, and have a team walk through the steps with a timer. The goal is to find which step relies on tribal knowledge. The OWASP Top 10 for LLM Applications names Excessive Agency (LLM06), and every step above gets easier when agent permissions were small to begin with.
If you want more scenarios, see AI agent incident tabletop scenarios to run.
Safeguard can help at the dependency and pipeline end of this: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
A worked example: a bad dependency and an exposed token
Here is a realistic incident. An agent, asked to fix a build error, adds a package with a name close to a popular library, runs the install, and the install script reads an environment file that contained a registry token. The next morning, a reviewer notices an unfamiliar package in a pull request.
| Time | Action | Step in the runbook |
|---|---|---|
| 09:10 | Reviewer flags the package, owner stops the agent's scheduled job | Stop |
| 09:15 | Platform team revokes the agent's token and the registry token | Revoke |
| 09:20 | Copy of job logs, shell history, and the branch saved | Preserve |
| 09:30 | Pull request closed, any merged commit reverted | Revert |
| 09:45 | Registry and cloud tokens rotated, provider logs checked for use | Rotate |
| 10:30 | All sessions that day reviewed for other installs or odd hosts | Blast radius |
| Next day | Short note written, install step moved to the prompt tier | Learn |
The detail worth copying is the order. Revocation happened before cleanup, because cleanup takes time and a live token does not wait. Evidence was saved before the branch was touched.
Roles during an incident
| Role | Duty |
|---|---|
| Incident lead | Runs the steps in order and keeps a timeline |
| Platform engineer | Revokes access, rotates credentials, restores systems |
| Reviewer | Examines the change and the session record |
| Communications owner | Informs affected teams, and leadership if needed |
Small teams combine roles, but name who holds each one before an incident.
Quick decisions that save time
- If unsure, revoke. Reissuing a token costs minutes. A live bad token costs far more.
- If the change is deployed, roll back the deployment first, then revert the commit.
- If personal data may be involved, notify your privacy or legal contact early. Duties and timelines depend on facts and jurisdiction, so do not guess.
- If the agent acted under a human's token, treat the human's credentials as exposed.
Prevention checks that make rollback easier
- Agents use their own identities, so revocation is surgical.
- Credentials are short lived, so rotation is routine.
- Logs live outside the agent's reach.
- Branch protection stops direct pushes.
- Dependencies are checked by policy before merge.
After action review
Within a week, hold a thirty minute review with three questions. Which control should have stopped this? What made detection slow? What single change would have shrunk the impact most? Pick one change and ship it. Record the review so the next incident team starts with the lessons.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice how a fix is surfaced for a vulnerable package.
Quick check
Should we delete the agent's branch?
Not until evidence is preserved. Keep the branch and logs, revert the effect, then clean up after the review.
Do we need to report every incident?
Reporting duties depend on what data was involved and where you operate. Ask your counsel or compliance lead, and decide the escalation path before an incident.
How fast should we revoke access?
As soon as the problem is confirmed or strongly suspected. Reissuing a token is cheap compared with the cost of leaving a bad one live.
Sources
Last reviewed: 19 October 2026.
