Incident Response Playbooks

Good news, everyone! You will have a security incident. The question is not whether — it is when, and how prepared you are when it happens. An incident response playbook is a pre-defined, step-by-step procedure for handling a specific type of security event. You write it before the incident, when you can think clearly. You follow it during the incident, when you cannot. The playbook removes decision-making from a situation where adrenaline and time pressure produce the worst decisions of your career.

Agent-specific incidents fall into five categories, and each category needs its own playbook. Compromised agent credential: an agent's identity has been stolen or leaked. Prompt injection attack: an agent is executing instructions from an attacker embedded in input data. Unauthorized data access: an agent is accessing resources outside its authorized scope. Self-modification anomaly: an agent's self-modification process has produced unexpected behavior changes. Supply chain compromise: a dependency used by an agent has been found to contain malicious code. Each playbook follows the same four-phase structure: contain, investigate, remediate, communicate.

1. Phase 1: Contain Stop the bleeding. Revoke the compromised credential, isolate the affected agent from the network, pause self-modification, or block the malicious input — whatever stops the incident from spreading. Containment happens in the first five minutes. Speed matters more than completeness. You can investigate later; you cannot un-breach data.
2. Phase 2: Investigate Determine what happened. Pull audit logs, SIEM correlations, and agent decision logs for the affected time window. Identify the root cause, the scope of impact, and whether other agents are affected. The investigation answers three questions: how did this happen, how far did it spread, and what data was exposed.
3. Phase 3: Remediate Fix the root cause, not just the symptom. Patch the vulnerability, rotate all potentially compromised credentials, update detection rules to catch this pattern in the future, and verify the fix with a targeted security test. Remediation is not complete until you can explain why this specific incident cannot recur.
4. Phase 4: Communicate Notify stakeholders: internal security team, affected clients, compliance officers, and — if required by regulation — data protection authorities. Communication happens on a defined schedule with pre-approved templates. Do not draft incident notifications during the incident — write the templates before you need them.