An AI coding agent has deleted files or a database, run a command nobody approved, pushed a secret, or been turned against its developer by a poisoned repository or a tampered extension, and the blast radius is whatever that developer's workstation and tokens could reach. Coding agents run with the developer's own shell, file system, Git credentials, cloud profiles and package registry tokens, so an incident that starts as one bad command can become a cloud, source code or supply chain incident within minutes. This playbook is scoped to the developer workstation, the repositories the agent touched and the credentials it could use. It covers how these incidents surface, triage, containment by priority, configuration file review, recovery, evidence and notification. It is written for security operations, platform engineering and engineering managers. The generic agent misuse process is in the AI Agent Misuse Incident Playbook; this page goes deeper on coding agents specifically.
Key takeaways
- Scope by credentials, not by the agent. Everything the developer's shell could read is potentially exposed: environment variables,
~/.aws,~/.kube/config,.npmrc, Git credentials and SSH keys. - Rotate from a clean machine. If a tampered extension or a prompt injection ran code, assume the workstation is untrusted and rotate secrets from a separate, trusted system.
- Configuration files are part of the crime scene. Agent instruction files, settings, hooks and MCP server definitions can carry the attack and persist after the extension is removed.
- Uninstalling is not remediation. In the 2026 Cursor marketplace compromise, the tampered Claude Code extension tried to plant an SSH key and persistence that outlived the extension.
- Do not trust the agent's own account. In the Replit incident the agent said rollback was impossible; it was not. Use independent logs and backups.
How the incident shows up
| Incident type | Typical first signal | Example |
|---|---|---|
| Destructive command | Missing files or data, failed builds, a database or cloud resource gone, the developer reporting it | Replit's agent ran destructive database commands during a declared code freeze in July 2025 |
| Leaked secret | Secret scanning alert, provider notice that a key was exposed, unexpected usage or billing on an API key | A key committed by an agent, or printed into a log or public issue |
| Prompt injection from repository content | Unexpected network connection from the developer's machine, command run without approval, EDR alert on a shell spawned by the IDE | A poisoned README made Gemini CLI run an allow-listed grep with a second command appended that sent environment variables out (fixed in 0.1.14) |
| Compromised extension or agent build | Vendor or marketplace advisory, EDR detection, new SSH keys or scheduled tasks | Amazon Q Developer extension 1.84.0 shipped a wiper prompt; tampered Claude Code extension builds 2.1.312 and 2.1.313 appeared on Cursor's marketplace |
| Malicious configuration | Code review spotting changes to agent instruction or settings files, new MCP server entries, unexpected hooks | Instructions hidden in rules files or hooks that run shell commands on agent events |
Map the behaviour to ATT&CK when you write it up: T1059 Command and Scripting Interpreter for agent-run commands, T1552.001 Credentials In Files for harvested credential files, T1485 Data Destruction for wipes, T1195.002 Compromise Software Supply Chain for tampered extensions and T1567 Exfiltration Over Web Service for data sent out.
Triage questions
- Which agent, which version and which installation path? CLI, IDE extension, marketplace source, version number. Compare against vendor advisories immediately; a known-bad version changes the whole response.
- What permission mode was it running in? Was it approving every action, auto-accepting edits, or running with permission checks disabled? Were destructive commands on an allowlist?
- Whose identity did it act as? List the credentials reachable from that shell and IDE: environment variables, cloud CLI profiles, Kubernetes contexts, Git credential helpers, SSH agent, package registry tokens, database connection strings, and the agent's own model provider API key.
- Was the trigger internal error or external content? Did the agent read an untrusted repository, issue, web page, dependency or MCP tool output just before the action? That decides whether this is an accident or an attack.
- Did anything leave the machine? Check EDR, proxy and DNS logs for connections the developer did not expect, and Git remotes for pushes.
- What reached shared systems? Commits, pushed branches, pull requests, published packages, infrastructure changes, production data.
- Are other developers affected? The same extension version, the same poisoned repository or the same shared configuration file means more than one workstation.
| Scenario | Treat as | Workstation status |
|---|---|---|
| Agent error, no external content, local damage only | Operational incident | Trusted after review |
| Agent error affecting shared or production systems | Operational incident with change and access review | Trusted after review |
| Secret leaked by the agent (commit, log, output) | Credential exposure | Trusted; rotate the secret |
| Prompt injection that executed commands | Security incident, possible compromise | Untrusted until investigated |
| Known-bad extension or agent version installed | Security incident, assume compromise | Untrusted; consider rebuild |
Containment priorities
- Stop the agent. Kill running agent processes and background sessions, and disable the extension. Do not delete it yet if you need it as evidence.
- Isolate the workstation if code may have run. Use EDR network containment for injection or tampered-extension cases. Keep it powered on for volatile evidence.
- Revoke and rotate reachable credentials, highest impact first. Cloud access keys and sessions, production database credentials, CI/CD and deployment tokens, Git tokens and SSH keys, package registry tokens, then the model provider API key. Do it from a separate trusted machine. GitHub notes a revoked or expired token cannot be restored, so issue replacements in the same change.
- Freeze affected repositories and pipelines. Pause deployments from branches the agent touched, protect release branches and block publishing from the affected package accounts until reviewed.
- Stop further damage in shared systems. Snapshot affected databases and cloud resources before anyone tries to repair them, and remove any standing write access the agent had to production.
- Warn other developers. If the cause is an extension version, a repository or a shared configuration, tell everyone who might have it, with the indicators to check.
Rotation order and provider-specific steps for leaked model keys are in the AI model provider API keys leak response guide; Git platform clean-up is in the GitHub organisation compromise playbook.
Eradication
Review agent configuration files
Coding agents load instructions and settings from the repository and the user profile. File names differ by product, so take the exact locations from each vendor's own documentation for the agent and version involved. Review every file in these categories, in each repository the agent worked in and in the home directory, and diff them against version control and known good copies:
| File category | Why it matters |
|---|---|
| Instruction and rules files (repository root, subfolders and parent directories) | Loaded into context at session start; a hidden instruction here steers every session |
| Agent settings files (project, local and user level) | Permission allow and deny rules, auto-approval settings and, where supported, hooks that run commands on agent events |
| MCP server definitions | Servers the agent starts or connects to, including commands to run and environment passed to them |
| Custom commands, skills, workflows and subagent definitions | Load with their own instructions and can widen what the agent does |
| Session transcripts and agent memory stores | Evidence, and a place an attacker's instructions can persist |
The attack patterns are described in the Coding Agent Configuration File Attacks guide.
Remove persistence and malicious changes
- Host persistence: check
~/.ssh/authorized_keysand Windows equivalents for unknown keys, new LaunchAgents, scheduled tasks, cron entries, shell profile changes and reverse tunnel processes. For the Cursor marketplace case, look for the key labelledsvc-telemetryand use the published remediation and indicators. - Repository changes: review every commit and branch the agent created during the incident window, including changes to CI workflows, dependency manifests, lock files and agent configuration. Revert rather than patch forward where unsure.
- Secrets in history: a secret committed and then deleted is still in Git history and in forks and clones. Rotation is the fix; history rewriting is optional clean-up.
- Agent and extension versions: remove known-bad versions, install the fixed release from the official source and pin it.
- Rebuild when in doubt: if a tampered build or injected command ran with the developer's privileges and you cannot prove what it did, rebuild the workstation.
Recovery
- Restore data from independent backups. Test the restore in a separate environment first. Replit data was restored even though its agent had claimed rollback was impossible.
- Re-issue credentials scoped for agents. Give the agent its own short-lived, least-privilege credentials rather than the developer's full cloud profile, as the Amazon Q lessons recommend, and keep long-lived secrets out of shell environments.
- Separate development from production. Replit responded by rolling out automatic separation of development and production databases. No coding agent should hold standing production write access.
- Re-enable with tighter permissions. Require approval for destructive commands, network access and writes outside the workspace; parse command allowlists strictly; run unfamiliar repositories only in a sandbox or container. See the AI IDE and Coding Agent Security Guide.
- Watch for reuse. Monitor the rotated credentials' predecessors for attempted use, which confirms theft and gives you attacker infrastructure.
Metrics to track afterwards: time from detection to full credential rotation, number of agents with production write access (target zero), share of developer machines with agent versions pinned and inventoried, secrets found in agent sessions or commits per month, and percentage of agent configuration file changes that went through code review.
Evidence to preserve
- Agent transcripts and logs: session files and transcripts in the locations the vendor documents, IDE extension logs and any hook or telemetry exports. Copy them before the agent runs again, because new sessions and memory writes change them.
- Shell history and process data: shell history files, EDR process trees showing what the IDE or agent spawned, and network connections.
- Configuration snapshots: every agent instruction, settings and MCP file listed above, with hashes and timestamps.
- Extension package: the installed extension directory and version, for comparison with the official build.
- Repository state: reflog, branches, commits and pull requests from the window, and the platform audit log.
- Cloud and SaaS audit logs: API calls made with the developer's credentials during the window, from the provider's logs.
- Volatile data: memory and running processes if a tampered build or injected code may still be active.
Store evidence off the affected machine with access logged, in line with NIST SP 800-53 AU-9 Protection of Audit Information.
Notification triggers
| Trigger | Rule or source | Action |
|---|---|---|
| Personal data in a deleted, altered or exfiltrated database | GDPR Article 33 (notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk) and Article 34 (inform individuals without undue delay where the risk is high); US state laws | Run the documented risk assessment; see the Data Breach Notification Checklist |
| Malicious code reached a release or package you publish | Customer contracts, security advisories, and CVE assignment where you are the vendor | Pull the release, publish an advisory with fixed versions, as AWS did with bulletin AWS-2025-015 and CVE-2025-8217 |
| Tampered agent build or marketplace extension | Vendor and marketplace security contacts | Report with indicators; share hashes internally and with peers |
| Third-party credentials or customer environments touched | Customer and supplier agreements | Notify per contract; coordinate rotation |
| Material incident at a listed company | Securities disclosure rules where they apply | Escalate to legal for a materiality decision |
Lessons from incidents
- Replit, July 2025: an agent deleted a production database during a code freeze, generated fake data and wrongly claimed rollback was impossible. A natural-language freeze is not a control. See the Replit AI Agent Database Deletion 2025.
- Amazon Q Developer extension, July 2025: an over-scoped GitHub token in a CodeBuild configuration let an attacker commit a wiper prompt that shipped in version 1.84.0. Review prompt and instruction changes like code. See the Amazon Q Developer Extension Compromise 2025.
- Gemini CLI, June to July 2025: a poisoned README abused loose allowlist parsing to exfiltrate environment variables. Any repository content is untrusted input. See the Gemini CLI Prompt Injection Flaw 2025.
- Cursor marketplace, October 2026: tampered Claude Code extension builds collected host details and tried to add an attacker SSH key with persistence. Persistence survives uninstalling, so rotate from a trusted system and consider rebuilding. See the Cursor Marketplace Extension Compromise 2026.
Practitioner checklist
- Keep an inventory of coding agents and extensions with versions and install sources on every developer machine.
- Write a credential list per developer role so you know what to rotate when a workstation is suspect.
- Rotate from a separate trusted machine whenever code may have run on the affected host.
- Diff agent instruction, settings, hook and MCP files against version control during every incident.
- Check for SSH keys, scheduled tasks and launch agents before declaring a workstation clean.
- Remove standing production write access from agents and developers' default profiles.
- Require code review for changes to agent configuration files and CI workflows.
- Test backup restores for any data an agent can touch.
- Subscribe to security advisories for every agent and extension in use.
Standards and references
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- OWASP: LLM06:2025 Excessive Agency
- OWASP: LLM01:2025 Prompt Injection
- EUR-Lex: Regulation (EU) 2016/679 (GDPR), Articles 33 and 34
- GitHub Docs: Token expiration and revocation
- MITRE ATT&CK: T1552.001 Credentials In Files
- MITRE ATT&CK: T1195.002 Compromise Software Supply Chain
Related NHI Mgmt Group resources: AI Agent Misuse Incident Playbook · AI Coding Agents Security Guide · Coding Agent Configuration File Attacks · Developer Workstation and IDE Security Guide · Claude Agent SDK Security Guide