Incident Response When an AI Agent Is Compromised

Contain the execution path and preserve the evidence

Unexpected exports, unexplained tool calls or a leaked agent key justify immediate containment while you establish what happened. Assign an incident lead and record the detection time in UTC. Use a trusted administrator session for response actions; keep credentials and incident evidence away from the suspected agent.

For the opening minutes, work through these actions in parallel where staffing permits:

1. Pause the agent, queued jobs, CI retries and scheduled launches. Isolate its laptop, VM or container from company systems and external destinations.
2. Revoke the affected identity at the service enforcing access. Include copies used by other runners if they share that identity.
3. Preserve available process information, transcripts, configuration, image identifiers and remote logs before deleting or rebuilding the environment. Record who collected each artifact and when.

NIST SP 800-61 Rev. 3 calls for protecting incident records and preserving their integrity and provenance. Apply that here by restricting evidence access and recording hashes of collected exports. Keep capture bounded: an agent actively exporting data needs its access cut immediately. Save key identifiers in the incident timeline rather than pasting raw credentials into the ticket.

Revoke every credential the agent could actually use

Build a credential inventory from the runner's configuration and secret-injection records. Separate the agent's gateway key from upstream OAuth grants, database passwords, cloud credentials and model API keys. Revoke the leaked gateway key immediately. Rotate other secrets when they were present in the compromised environment or evidence indicates exposure; document why each remaining credential is outside the affected path. For scope analysis, use the blast radius of a leaked agent key.

For OAuth providers supporting RFC 7009, use the provider's documented HTTPS revocation endpoint and registered client authentication method. This illustrative request uses synthetic credentials for a confidential client; the hostname and path are placeholders:

POST /revoke HTTP/1.1
Host: authorization.example
Content-Type: application/x-www-form-urlencoded
Authorization: Basic dGVzdC1jbGllbnQ6dGVzdC1zZWNyZXQ=

token=example-refresh-token&token_type_hint=refresh_token

RFC 7009 permits HTTP 200 for an already-invalid token and describes possible propagation delays. Related-token invalidation depends on server policy. Record the affected refresh grant and access tokens, then use provider administration and resource-server evidence to establish when access ended. Do not make another request using the revoked token: the RFC prohibits clients from using it after a successful revocation response. Uninstalling the agent leaves server-side access unresolved.

Reconstruct tool activity and downstream effects

Start the investigation window at the earliest plausible exposure, such as key issuance or installation of a suspect plugin, and extend it through confirmed containment. Correlate gateway records, upstream audit trails, runner network activity and repository history. Capture whatever each system actually records: identity, UTC time, source, tool, outcome, request identifier and affected resource. Keep absent fields explicit.

Suppose a hypothetical agent reads customer records at 09:12, creates an export at 09:14 and loses access at 09:18. The investigation must identify which records were returned, where the export went and whether another credential remained usable afterward. A successful read establishes access to data; external disclosure needs additional evidence. Missing network logs leave that question unresolved.

• For reads, identify accessible datasets, returned records where available, downloads and outbound destinations.
• For writes, inspect commits, database changes, messages, newly issued credentials and permission changes.
• For failures, separate denied attempts from timeouts that may have followed a completed upstream action.

Have each system owner confirm the resulting state before reversing changes. Avoid blindly replaying a timed-out write. Record confirmed impact, plausible exposure and evidence gaps separately so an incomplete transcript does not become a claim that nothing happened. Compare available fields with audit logging for agent tool calls.

Quarantine memory, skills and lifecycle automation

OWASP's AI Agent Security Cheat Sheet identifies memory poisoning as malicious data persisted to influence future sessions or other users. Treat memory cleanup as a separate recovery task. Freeze capture and synchronization for affected agents, preserve suspect entries, then compare personal and shared context against a trusted baseline. Review changed skills, instructions and remembered destinations, especially requests to export data or bypass approval.

Inspect the automation that reloads or rewrites that context. Claude Code's hooks reference documents this setting for temporarily disabling hooks in .claude/settings.json:

{
  "disableAllHooks": true
}

Settings precedence matters. For a recovery run, claude --settings '{"disableAllHooks": true}' overrides project and local settings, but cannot disable hooks enforced through managed policy. Coordinate those with the administrator. Apply changes through a trusted editor after containment; this setting does not revoke credentials or isolate the host.

Trace which other agents read affected shared entries and review their subsequent writes. Restore reviewed versions or remove poisoned entries from active recall while retaining isolated evidence. Start a fresh conversation after cleanup so suspect material is no longer carried in the working transcript. Use memory poisoning defenses to guide the follow-up review.

Rebuild the runner and repair affected systems

Choose remediation based on the compromised boundary. A key leaked from an otherwise trusted machine calls for credential containment and exposure review. A malicious local MCP package, shell execution or altered runner image calls for rebuilding that execution environment from verified inputs. Keep the original isolated for investigation instead of trying to prove it clean by asking the same agent to inspect itself.

Compare MCP launch commands, package versions, plugin installations and startup configuration with the approved deployment. Inspect CI definitions and image-building inputs before restarting jobs. If the suspect package entered a shared base image, enumerate the runners built from it and contain their identities too.

Repair downstream state with system owners: remove unauthorized grants, invalidate attacker-created credentials and reconcile altered records against trusted history. Record each repair separately from runner replacement. Rebuilding a container does not reverse a message already sent or a permission already changed. Keep the original trigger quarantined until its role is understood.

Containing connected access with SPYN3

SPYN3 is one MCP endpoint per workspace; upstream credentials stay in the workspace and never reach the agent. An admin can revoke an agent key or disconnect a source in the dashboard, effective on the next call. Proxied calls are audit-logged with source, tool, outcome and duration; memory writes identify the key or agent responsible. Use those records alongside upstream evidence. For recovery, issue a key limited to required sources and withhold call:write_tools and write:memory until their access is needed.

Restore one agent against explicit recovery gates

NIST's recovery guidance includes checking restoration assets before use and verifying restored systems before returning them to production. For this incident, make the reopening decision depend on observable checks:

1. The old credential identifiers are revoked, remaining token lifetimes and enforcement delays are accounted for, and no unexplained successful calls appear after containment.
2. The replacement runner and its installed MCP servers match reviewed inputs. Shared skills, memory and hooks have been checked before loading.
3. A new identity can perform the required read and is denied an out-of-scope operation against a disposable test resource.
4. A controlled reproduction of the original trigger, using synthetic data and isolated destinations, cannot produce the unauthorized effect.

Resume one agent with narrowly scoped access and monitor its first task. Agree on an observation window with the system owners before expanding to the fleet. Close the incident record with the exposure timeline, affected resources, unresolved visibility gaps and owners for remaining fixes. Measure how long revocation took and how many runners needed manual intervention; those are concrete targets for the next containment drill.