Incident Response

Security Objective

Incident response for prompt injection is the coordinated, evidence-driven process used when suspicious or confirmed model influence may have affected a workflow, tool action, data flow, credential, resource, agent or sub-agent, or downstream system. Its objective is to establish what actually happened, stop ongoing effects with the narrowest reliable control, repair the failed control boundary, restore known-good operation and feed lessons back into prevention.

Threat Model

The response process assumes that some injected content will reach model context, that model behavior is variable, and that probabilistic detectors will miss some events and flag some benign ones. It also assumes that telemetry may be incomplete, that model-influenced state can persist beyond one run, and that delegated agents and third-party connectors extend the scope of any event.

Defense Control, Not the Incidents Database

This page describes an operational defense control: how a team responds to its own prompt-injection-related security events. The top-level Incidents area is different. It catalogs publicly documented real-world cases, research demonstrations and advisories with their sources and classifications. Nothing on this page is a case record, and the scenarios below are fictional.

Boundaries With Other Controls

See Prompt Injection Detection, Plan Drift Detection, Tool-Chain Analysis, Data Provenance, Agent Authorization, Human-in-the-Loop, Sandboxing / Containment, Network / Egress Restrictions, Information Flow Control, Least Privilege and Output Validation.

Evidence States

Evidence states describe what the record shows, from weakest to strongest. Each state needs its own evidence; a higher state is never inferred from a lower one.

Security Event Versus Confirmed Incident

A security event is any observation worth triage, for example a detector alert on retrieved content. An incident, in this engineering model, is an event where evidence shows a policy or control violation with actual or credibly possible security impact. A confirmed incident impact requires evidence of execution and effect. Organizations should align these terms with their own incident policy; the definitions here are engineering guidance.

Severity and Triage

Severity follows actual or credibly possible impact, not detector confidence. A high-confidence alert on content that reached no tool is usually lower severity than a low-confidence signal next to an executed privileged action.

Preparation

Most response quality is decided before the event. Teams that cannot correlate a model output with the tool request it produced cannot scope an incident.

Evidence Preservation

Preserve evidence before destructive cleanup such as resetting memory, rotating logs or redeploying workers. Once a cache is flushed, lineage for affected runs may be gone.

Timeline Reconstruction

For each action, record whether it was proposed, attempted, executed, succeeded, failed or unobserved. A proposal in a transcript is not evidence of a request; a submitted request is not evidence of a completed effect.

Scoping

Scope grows with evidence. Do not declare other users or tenants affected without evidence that they consumed the relevant content or state.

Containment Options

Prefer the narrowest control that reliably stops ongoing impact, and escalate scope when evidence warrants it. Tightening a control during response is a precaution, not a finding of malicious intent.

Credentials, Tokens and Secrets

Rotate or revoke when exposure is confirmed or credible risk justifies it. Do not claim exposure merely because a secret existed somewhere in the environment, and do not skip rotation for a credential that was credibly exposed.

Data Exposure and Modification

Distinguish readable, accessed, sent, received, modified and deleted. "Readable" means a permission existed; "accessed" needs a read record; "sent" needs a request record; "received" needs destination-side evidence; "modified" and "deleted" need downstream audit evidence where available. Claims of completed transfer or change should rest on the strongest available evidence.

Persistence and State

Model-influenced content can persist in caches, memory, vector stores, tool state, files, queued jobs, stored agent plans and shared workspaces. Treat retained model-influenced state as untrusted input until it is reviewed or reset, and trace which later runs consumed it.

Multi-Agent and Delegated Workflows

Trace delegation through parent and child task IDs, inherited capabilities, returned results and cross-agent provenance. A finding in a sub-agent does not automatically establish compromise of the parent, and a parent finding does not automatically implicate every child. Each link in the delegation chain needs its own evidence.

Third-Party, SaaS and Connector Coordination

Request provider audit data, revoke specific grants where needed and preserve provider-side identifiers such as request IDs. Do not assume a provider-side event without evidence, and do not assume the provider has no records of relevance.

Eradication and Remediation

Remove unsafe content and state, fix the broken trust or control boundary, and update policy, configuration, credentials and integrations as required.

Recovery

Communications and Escalation

Use factual language tied to evidence states: affected scope, what is known and unknown, actions taken, and customer or user impact where verified. Avoid "breach", "exfiltration" or "compromise" unless evidence supports them. Legal and regulatory notification decisions belong to the responsible owners under the organization's policy.

Post-Incident Analysis

Map the root cause to the failed or missing control planes: provenance, authorization, privilege, information flow, egress, containment, detection, output handling or human approval. Record contributing conditions such as missing telemetry, stale grants or unclear ownership.

Lessons Learned and Control Updates

Turn findings into detection rules, regression tests, playbook updates, policy changes, data-handling guidance and vendor follow-up. Fix deterministic controls where possible rather than only adding prompts or classifiers.

Evidence and Reason Codes

The following codes are engineering guidance for consistent records, not a standard.

NO_IMPACT_OBSERVED should be paired with EVIDENCE_INCOMPLETE when telemetry gaps exist.

Worked Scenarios

All scenarios use fictional systems and data.

A: Detector Alert Without Changed Behavior

Instruction-like text appears in a retrieved page and a detector alerts. Plan and actions are unchanged. Triage as a suspicious event, preserve provenance for the source and review whether the source should stay eligible for retrieval. Outcome: SUSPICIOUS_CONTENT_OBSERVED, no confirmed incident impact.

B: Plan Drift Blocked Before Submission

The plan drifts and proposes a privileged cross-tool action. Authorization denies it before submission. Preserve plan, proposal and decision records and investigate the source and why the proposal arose. Outcome: MODEL_INFLUENCE_OBSERVED and ACTION_PROPOSED; no downstream action occurred.

C: Executed Request With Confirmed External Change

An allowed tool request executes and the downstream audit log confirms an unintended external change. Contain the workflow and tool grant, preserve request, response and audit evidence, scope affected runs, remediate the boundary and recover in stages. Outcome: ACTION_EXECUTED and DOWNSTREAM_EFFECT_CONFIRMED; confirmed impact.

D: Scoped Token in an Outbound Request

A scoped token is present in a worker, and logs show it was included in an outbound request to an unapproved destination. Treat this as confirmed exposure and transfer evidence for that token: revoke and rotate it, remove the egress path and scope any use with the provider. Other secrets are not declared exposed without their own evidence. Outcome: CREDENTIAL_EXPOSURE_CONFIRMED, DATA_TRANSFER_CONFIRMED, TOKEN_REVOKED.

E: Influenced State in a Shared Store

Model-influenced content persisted in a shared vector memory and affected a later run. Quarantine or reset that state, scope runs and users that consumed it, preserve lineage and restore known-good state. Unrelated tenants are not called affected without evidence. Outcome: persistence and cross-run impact confirmed for the traced runs; STATE_RESET.

What the Scenarios Prove and Do Not Prove

Testing and Tabletop Exercises

To practice classifying evidence states on synthetic records, try the Incident Investigation lab.

For systematic, authorized testing of your own system beyond tabletop exercises, see Adversarial Testing.

Metrics

These are operational measures, not proof of security.

Common Mistakes

Implementation Checklist

Standards and Sources

Source scope: NIST SP 800-61 Rev. 3 is general incident-response guidance integrated with cybersecurity risk management; it is not specific to prompt injection or AI systems. The NIST SP 800-53 IR controls are cited only for general control orientation. The OWASP agentic list provides agent and tool risk context, and LLM01:2026 is prompt-injection risk context only. No cited source defines this prompt-injection incident response model as a complete standard. Evidence states, severity dimensions, reason codes, scenarios and metrics on this page are engineering guidance.

Frequently Asked Questions