AI-agent incident response
AI agent security incident response checklist.
Stop new agent actions, preserve the evidence that still exists, revoke affected authority, determine what the agent reached or changed, and recover from a known-good boundary.
Do not confuse a paused agent with a contained incident. Sessions, credentials, connectors, scheduled jobs, repository changes, and external actions can remain after the visible run stops.
CapitalGuard Security Research · Version 1.0.0 · Sources checked July 30, 2026
5
Ordered steps
28
Register fields
7
Primary sources
The direct workflow
Stop. Preserve. Revoke. Scope. Recover.
Use one coordinator and one timeline. If the incident is active, destructive, regulated, or beyond the team's expertise, use a qualified incident responder before making destructive changes.
- 1
Stop
Stop new agent actions without destroying evidence
Name one incident coordinator, record the detection time, pause new agent tasks and schedules, and use an approved containment control when continued tool use could cause harm. Do not delete chats, rewrite repository history, or reset affected systems merely to make the incident look clean.
- 2
Preserve
Preserve the smallest useful evidence set
Record agent, session, model, repository, tool, connector, account, and environment references. Export available traces, audit events, diffs, commits, approvals, provider event IDs, and timestamps before retention windows expire. Keep secrets and personal data out of the response register.
- 3
Revoke
Revoke authority and rotate exposed credentials
Disable affected tokens, keys, sessions, connectors, app grants, and service accounts at their issuing providers. Rotate a potentially exposed secret before considering repository-history cleanup, and verify each replacement automation uses the new credential with the minimum required scope.
- 4
Scope
Determine what the agent reached and changed
Build a timeline of files read or changed, commands and tool calls, external destinations, accounts, data types, users, and business processes in scope. Separate confirmed evidence from assumptions, identify required internal escalation, and obtain qualified legal, privacy, or incident-response advice when needed.
- 5
Recover
Restore a known-good boundary and monitor it
Restore approved configuration and code, reissue only the access still needed, test the agent in a constrained environment, and monitor the affected repositories, accounts, connectors, and credentials for a defined period. Record residual risks, lessons, owners, and follow-up deadlines before closure.
First decision
Match the response to what is still happening.
A suspicious answer, an exposed credential, an unauthorized write, and an external action require different controls. Record facts first and preserve provider evidence before it expires.
| Observed condition | Immediate boundary |
|---|---|
| The agent is still taking unsafe actions | Pause new jobs and invoke the approved containment boundary. Record the time and control used. |
| A token, key, or password may be exposed | Revoke or rotate it at the issuing provider. Never paste the secret into the incident register. |
| Repository content changed unexpectedly | Stop further writes and preserve the branch, commit, diff, actor, workflow, and audit references. |
| A connector performed an external action | Disable the connector or grant and preserve provider event IDs, destinations, payload class, and approval state. |
| Impact is unclear, regulated, or still active | Escalate to a qualified incident responder and the organization's legal, privacy, or notification owner. |
Blank incident register
Preserve references, not secrets.
Keep the completed record private. Use provider event IDs, trace IDs, commit hashes, and authorized evidence locations instead of copying credentials, customer data, sensitive prompts, or raw source into the register.
| Field | Machine key | Why it matters |
|---|---|---|
| Incident ID | incident_id | A non-sensitive internal reference for the incident. |
| Detected time | detected_at | When suspicious behavior or exposure was first identified. |
| Incident coordinator | coordinator | The person accountable for decisions, evidence, and handoffs. |
| Initial severity | initial_severity | The organization's provisional severity and the reason for it. |
| Environment | environment | Development, test, staging, production, personal, or other boundary. |
| Agent system | agent_system | The agent product, workflow, harness, or automation in scope. |
| Agent session references | agent_session_references | Privacy-reduced run, trace, conversation, job, or session identifiers. |
| Detection trigger | trigger | The alert, report, observation, or control that started the response. |
| Observed behavior | observed_behavior | Facts observed without inferred motive or unsupported conclusions. |
| Affected repositories | affected_repositories | Authorized repository references and branches potentially in scope. |
| Affected accounts and services | affected_accounts_and_services | Identity, cloud, source-control, SaaS, and local accounts in scope. |
| Tool calls and actions | tool_calls_and_actions | Commands, writes, deployments, messages, purchases, or external calls observed. |
| Data types in scope | data_types_in_scope | Source code, credentials, customer data, personal data, or business records involved. |
| Containment start time | containment_started_at | When the first approved action limited further agent activity. |
| Agent and job status | agent_and_job_status | Paused, stopped, isolated, still running, or unknown, with the responsible owner. |
| Credentials revoked or rotated | credentials_revoked_or_rotated | Provider-side credential references and completion status, never secret values. |
| Connectors and sessions revoked | connectors_and_sessions_revoked | Application grants, connectors, sessions, devices, or service accounts disabled. |
| Evidence locations | evidence_locations | Authorized private locations for traces, logs, diffs, exports, and provider records. |
| Evidence privacy class | evidence_privacy_class | The handling category applied to the incident evidence. |
| Timeline | timeline | Ordered confirmed events, decisions, actions, and owners. |
| Impact assessment | impact_assessment | Confirmed and possible technical, data, customer, financial, and operational impact. |
| Notification owner | notification_owner | The qualified owner deciding internal, customer, regulator, insurer, or authority notices. |
| Recovery baseline | recovery_baseline | The known-good code, configuration, policy, and access state selected for recovery. |
| Validation tests | validation_tests | Tests used to confirm containment, credential replacement, and constrained operation. |
| Monitoring window | monitoring_window | The defined period, signals, and owner for heightened monitoring. |
| Residual risk and actions | residual_risk_and_actions | Unresolved questions, accepted risks, follow-up owners, and deadlines. |
| Closed time | closed_at | When the incident coordinator completed the response record. |
| Approver | approver | The person who reviewed closure evidence and accepted remaining risk. |
Primary-source boundaries
Available evidence depends on the system and configuration.
Check the exact provider, plan, retention window, trace setting, identity model, and application in use. These sources describe response controls; they do not prove that a specific incident was contained or resolved.
| Source | Control | Documented boundary | Checked |
|---|---|---|---|
| NIST | SP 800-61 Rev. 3 incident response | NIST integrates incident response across cybersecurity risk management and the Detect, Respond, and Recover functions. The publication is organization-wide guidance, not an AI-agent product test, certification, or substitute for a response plan tailored to the organization. | 2026-07-30 |
| NIST | AI RMF Manage function | The AI RMF calls for documented response and recovery, the ability to disengage or deactivate AI systems, post-deployment monitoring, incident communication, and tracked recovery. It is voluntary, use-case agnostic guidance and does not certify this checklist. | 2026-07-30 |
| CISA | Cybersecurity Incident and Vulnerability Response Playbooks | The CISA playbooks cover detection and analysis, coordination, evidence collection, containment, eradication, recovery, and post-incident work. They were written for U.S. federal civilian agencies; their agency reporting steps are not general requirements for every organization. | 2026-07-30 |
| OpenAI | Agents SDK tracing | The Agents SDK can trace generations, tool calls, handoffs, guardrails, and custom events, but tracing can be disabled and is unavailable under Zero Data Retention. Trace inputs and outputs can contain sensitive data, so an absent or privacy-reduced trace is not proof that an action did not occur. | 2026-07-30 |
| GitHub | Review and export an organization audit log | GitHub organization audit logs identify recorded actors, actions, and times and can be searched or exported as JSON or CSV. The documented web view covers events from the last 180 days and export limits apply; the log is not a complete record of activity outside GitHub. | 2026-07-30 |
| GitHub | Respond to sensitive data in repository history | GitHub says to revoke or rotate an exposed password, token, or credential before considering history rewriting. Rewriting history has coordination and recontamination risks, and removing repository history does not prove that local or downstream copies were deleted. | 2026-07-30 |
| Microsoft | Revoke Microsoft Entra user access | Microsoft documents disabling an account, revoking refresh tokens, and disabling registered devices, while warning that access-token expiry and application-issued sessions affect revocation timing. An application must revoke sessions issued under its own authorization policy. | 2026-07-30 |
Continue the evidence trail
Rebuild the boundary with the relevant evidence.
Audit AI-agent permissions
Rebuild the approved access baseline after containment.
Open evidenceOffboard people and agents
Close identity, session, repository, connector, and shared-secret paths.
Open evidenceRuntime gate
Review the documented containment and residual boundary.
Open evidenceDelegation boundary benchmark
Inspect signed authority attenuation, replay, and binding evidence.
Open evidenceWhen repository scope is part of the incident
Preserve first. Then assess the authorized repository boundary.
After the response owner confirms that scanning will not destroy evidence, CapitalGuard can assess an authorized repository for exposure paths. It does not inspect every external service, prove compromise, contain an active attacker, satisfy notification duties, or replace a qualified incident responder.
Method: direct NIST, CISA, OpenAI, GitHub, and Microsoft documentation checked on July 30, 2026. Limitations: this checklist is not legal, privacy, compliance, notification, forensic, insurance, or emergency incident-response advice. A completed register does not prove that every action was observed, every copy was deleted, every credential was revoked, or the affected environment is secure.