Summary: An open-source framework from the Coalition for Secure AI (an OASIS Open Project) mapping the NIST IR lifecycle onto AI systems, with machine-readable CACAO playbooks and per-architecture threat mappings to MITRE ATLAS.
Sources: raw/AI-incident-response/Defending AI Systems_ A New Framework for Incident Response in the Age of Intelligent Technology.md
Last updated: 2026-07-28
Announced 30 October 2025 by Mary Beth Minto. The framework PDF is at coalitionforsecureai.org; the project lives at github.com/cosai-oasis/ws2-defenders (source: Defending AI Systems…md).
Note: the source here is the announcement blog post, not the framework itself. The detail below is what the announcement describes. The framework PDF is not in raw/ and should be ingested separately.
The autonomy ladder
The framework’s organising idea is that security requirements change with agentic sophistication, across four levels (source: Defending AI Systems…md):
- Perceptively autonomous assistants
- Reactively autonomous agents — “observe independently but act under human direction”
- Partially autonomous systems — “operate independently while seeking approval for critical decisions”
- Fully autonomous agents — “requiring no human supervision”
This is a more useful axis for IR planning than model capability. It determines what containment even means: you can pause a level-2 agent by withholding direction; a level-4 agent needs an actual kill switch. Compare OECD Principle 1.4(b) on override and decommissioning.
The threats it names
- Prompt injection — “manipulate AI behavior through cleverly crafted input”
- Memory poisoning — “corrupts an AI agent’s long-term context”
- Context poisoning — “attackers inject malicious content into the knowledge bases AI systems reference”
- Model extraction
- Jailbreaking
“These aren’t theoretical concerns. The framework documents real-world case studies, including attacks on major financial institutions and demonstrations of how AI systems can be systematically compromised without ever touching the underlying infrastructure.”
Cross-references: retrieval and memory poisoning (T13, T32, T64), weight-level attacks (T58, T59), and the whole of PITAX.
The NIST lifecycle, adapted
1. Preparation — “inventory their AI assets, establish specialized response teams, and implement comprehensive monitoring.” Emphasises capturing AI-specific telemetry: “prompt logs, model inference activity, tool executions, and memory state changes.”
That four-item telemetry list is the most actionable line in the source. Tool executions and memory state changes are the two most teams do not capture, and they are exactly what an agentic incident is made of.
2. Detection and analysis — monitoring for “unexpected model drift, suspicious prompt patterns, and unusual retrieval behaviors in RAG systems.”
Unusual retrieval behaviour is the detection signal for T64 retrieval ranking manipulation — a document that starts winning retrieval for queries it should not.
3. Containment, eradication, recovery — “Should you roll back to a previous model version? Purge poisoned memory? Rebuild your vector database? The framework offers architecture-specific guidance for different AI system types.”
4. Post-incident — “understanding both technical root causes and how to prevent similar attacks across different AI architectures.”
CACAO playbooks
The framework’s distinctive deliverable: a library of playbooks in the OASIS Collaborative Automated Course of Action Operations (CACAO) standard. “These aren’t abstract guidelines, they’re detailed, actionable workflows” (source: Defending AI Systems…md):
- Detecting training data poisoning
- Responding to multi-channel prompt injection
- Handling memory injection attacks (MINJA)
- Mitigating RAG poisoning
- Addressing cloud credential abuse through SSRF vulnerabilities
“Each playbook includes detection methods, triage criteria, containment steps, and recovery procedures.”
CACAO is machine-readable, which means these are executable in a SOAR context rather than being documents. That is the meaningful difference from every other IR guidance in this corpus.
MINJA is the Memory Injection Attack (arXiv 2503.03704), listed as an alias under PIT-T-13 Memory Exploitation.
Architecture patterns mapped to ATLAS
The framework covers “five common AI architecture patterns, from basic LLM applications to complex agentic RAG systems.” For each it maps:
- “Specific components and their functions”
- “MITRE ATLAS techniques that apply to each component”
- “Targeted mitigation strategies”
- “Real-world attack scenarios”
ATLAS itself is now ingested — see MITRE ATLAS, including its 35 mitigations and 63 case studies. What remains missing is CoSAI’s per-component mapping of ATLAS techniques onto the five architecture patterns, which lives in the framework PDF rather than this announcement post.
Audiences
CISOs (executive summaries, regulatory guidance), security analysts and responders (detection methods, forensic guidance, response workflows), AI/ML engineers (architecture-specific considerations), compliance officers (“regulatory communication templates and information-sharing guidelines”).
Assessment
Of the four IR sources here, CoSAI’s is the one that is actually operational — architecture-specific, machine-readable, ATLAS-mapped. Microsoft’s pattern is better on organisational and human factors; CoSAI is better on technical execution. They are complementary, and neither is a substitute for the other.