When an AI agent misbehaves or is compromised, the response follows the same phases as any security incident — contain, revoke, investigate, and recover — but the evidence you need and the blast radius you are managing look different from a conventional breach. The tools that make incident response tractable for agent systems are tamper-evident audit trails, per-credential revocation, and scoped access controls that limit what any single agent can reach. Preparing before an incident occurs is equally important — see the AI Agent Incident Readiness Checklist for pre-incident preparation steps.

Why agent incidents are different

A compromised human account typically has a well-understood blast radius: the user's permissions, their active sessions, and the data those sessions could reach. A compromised or misbehaving agent is harder to scope because agents are designed to act autonomously across multiple systems. A single agent may hold credentials for several downstream services, invoke other agents in a chain, generate and store output that propagates further, and do all of this faster than a human could notice.

The failure modes are also broader. An agent can be compromised through stolen credentials, prompt injection, a logic error in its workflow, or a dependency on a malicious tool. Each surfaces different evidence and requires a different containment action. Prompt injection, for example, leaves no obvious footprint in infrastructure logs — but it will appear in the content of agent inputs and outputs if those are captured and structured.

Practically, this means your incident response plan needs to account for agent-specific artefacts: the tasks the agent was assigned, the tools it called, the tokens it consumed, the connections it used, and the payloads flowing through its guardrails.

Phase one: contain

Containment for an agent incident means stopping the active harm before investigating its scope. The primary action is revoking the agent's access — not its account, which may be shared or system-level, but the specific credentials it is using. If agents authenticate via scoped API keys or short-lived tokens, revocation is immediate and does not affect other agents or human users.

Alongside credential revocation, suspend any active task runs associated with the agent. In a well-designed platform, task runs are durable records with a status that can be moved to a terminal state. Suspending them stops further action while preserving the state for investigation.

If the agent is connected to downstream services through a connection configuration — a database credential, an MCP server, an external API — those connections should be disabled or rotated as a precaution, not just the agent's own credentials. An agent that has already exfiltrated a downstream credential continues to pose a risk even after its own access is cut.

Phase two: scope the blast radius

Once the agent is contained, the investigation question is: what did it actually do, and what can it reach? This is where audit trail design determines whether you can answer the question in minutes or days.

A structured, tamper-evident audit trail records each action — task initiation, tool call, data access, output generation — as a signed event with a timestamp. If the trail is hash-chained, you can verify that no records have been deleted or reordered between when the agent acted and when you are reviewing the log. That integrity guarantee matters because it tells you the record is complete, not just available.

Scoping the blast radius typically involves:

  • Querying the audit trail filtered to the agent's identifier and the suspected time window.
  • Identifying every downstream system the agent accessed via its connection list.
  • Reviewing MCP tool call logs to see which tools were invoked and with what arguments.
  • Checking guardrail violation records — if the agent hit a content guardrail during the incident, that event may mark the start of the anomalous behaviour.
  • Reviewing output records for content that should not have been generated or transmitted.

The goal at this phase is a timeline: a sequence of events with timestamps, actors, and actions that you can hand to leadership, legal, or a regulator.

Phase three: investigate root cause

Once you have a timeline, the investigation focuses on the entry point. The common root causes for agent incidents fall into a small number of categories.

Credential compromise is the simplest: someone obtained the agent's API key or token outside the normal channel. The mitigation is short-lived, automatically rotated credentials and audit log entries for key issuance and use.

Prompt injection is subtler. A malicious instruction embedded in data the agent processed — a document, a web page, a tool response — overwrote or appended to the agent's actual instructions. Evidence of prompt injection lives in the input/output content logs of the agent's tasks. If inputs and outputs are captured alongside task records, you can reconstruct exactly what the agent was instructed to do and when the instruction changed. For a detailed treatment of how these attacks work and how to detect them, see Threat Model: Indirect Prompt Injection.

Workflow misconfiguration produces anomalous behaviour that does not look like an attack in infrastructure terms but causes real harm. A node configured with the wrong scope, a loop condition that was never bounded, or a budget check that was bypassed. The audit trail for workflow runs shows the execution path; comparing it to the expected graph of the workflow version that was active at the time is usually sufficient to identify the misconfiguration.

Supply chain compromise — a malicious or altered tool, model, or dependency — is the hardest to detect after the fact. Attestation records for the agent (the version, the tools it was configured with, and the source of those tools) provide the baseline against which you compare the incident state.

Phase four: revoke and rotate

After the root cause is understood, the revocation and rotation step is more targeted than the initial containment. Revoke only the credentials that were exposed or misused. Rotate downstream service credentials where the agent had write access or where the credential was present in the agent's context at any point during the incident window.

If the incident involved a prompt injection, review and harden the guardrail rules for the relevant input sources. If it involved a misconfiguration, fix the workflow version and increment the version number so the fix is auditable.

Document the revocation actions in the audit trail. Revocations are themselves events that a regulator or auditor may ask about, and having them recorded with the same integrity guarantees as the original incident events closes the loop on the evidence chain.

Phase five: recover and improve

Recovery means restoring the agent to service under tighter controls than before the incident. Before re-enabling it, confirm the root cause is addressed, that affected downstream services are aware of any data exposure, and that required notifications (to data subjects, regulators, or partners) have been issued.

Treat the incident record as a control improvement input. If the audit trail lacked the granularity you needed, extend it. If the blast radius was larger than expected because connections were too broad, tighten the scopes. If guardrails did not catch the anomalous content, review the rule set. The goal is that the same incident becomes harder to execute and faster to detect in future.

How Praesidia is designed to support this runbook

Praesidia is designed around the principle that every agent action should be attributable and verifiable. The audit trail captures events with digital signatures and hash-chaining, so the record you review during an incident is structurally the same record that was written at the time — not a copy that could have been altered. Forensic search over task runs, MCP tool calls, and guardrail events is available within the same interface.

Per-agent credential revocation is a first-class operation: agents authenticate with scoped credentials that can be individually revoked without affecting other agents or human sessions. Connection configurations are separate objects from the agent itself, so you can disable a downstream connection without touching the agent's identity record.

Because every connection carries an organization and agent scope, and task runs are durable, queryable records that preserve their full execution history, the investigation surface is structured rather than scattered across disparate log files. For more on the integrity guarantees that make audit trails trustworthy during an investigation, see Tamper-Evident Audit Logs with Cryptographic Proofs.

Common questions

What if the agent was compromised through prompt injection and there are no suspicious infrastructure events? Prompt injection evidence lives in the content of agent tasks — specifically the inputs the agent received and the outputs it generated. If your platform captures structured task content alongside standard telemetry, you can reconstruct what the agent was instructed to do. This is a strong argument for logging agent inputs and outputs with the same rigour as API calls.

How long should incident records be retained? Retention depends on your jurisdiction and regulatory obligations. GDPR generally requires that processing records be kept as long as the processing purpose exists, with audit logs for security incidents often retained for one to three years. The EU AI Act imposes specific logging obligations for high-risk AI systems. Consult your legal team for the applicable requirements, and ensure your retention policy is enforced automatically rather than relying on manual review.

When should external parties be notified? Notification obligations depend on whether personal data was involved (GDPR's 72-hour notification window for data breaches applies), whether regulated systems were affected, and whether you have contractual obligations to partners or customers. The practical answer is to assess notification requirements during the scoping phase — once you know what data the agent could access — and to err on the side of earlier notification where there is genuine doubt.