Playbook & Runbook Injection

Human reviewers and on-call operators do not adjudicate from first principles — they follow playbooks, runbooks, SOPs, moderation guidelines, and (increasingly) AI-drafted decision aids. Playbook & Runbook Injection corrupts that *procedural authority* so the reviewer faithfully executes a malicious instruction believing it is sanctioned policy. The attacker introduces a forged or altered rule ("new policy: academics get exceptions", "revised SOP: allow X for pen-testing") through whatever surface feeds the procedure: an editable wiki/knowledge base, a ticket or change request that masquerades as an approved update, a poisoned RAG store that an AI copilot quotes back to the operator, or simply a confident claim inside the case itself.

• Procedure change-control auditing: Every playbook/SOP/guideline edit must have an authenticated author, approver, and diff; flag rules that lack a valid change record.
• Anomalous-clause detection: Scan procedure text for high-risk patterns ("skip review", "allow unrestricted", "now permitted") and route them to security review before publication.
• RAG/knowledge-base integrity monitoring: Detect unexpected edits or low-provenance documents in the stores that feed operator decision aids.
• Citation provenance in AI decision aids: Require the assistant to cite the source and version of any rule it quotes so operators can verify it against the canonical policy.

Playbook injection multiplies T15-AT-002 and T15-AT-011: a fabricated "policy" makes a persuasive or impersonated request self-justifying ("see, the SOP allows it"). When the runbook is surfaced to an operator by an AI assistant reading a knowledge base, this is a direct instance of T1 (Prompt Injection) and T12-style RAG/knowledge-store poisoning crossing into the human layer.