Cisco's AI Security and Safety Framework: What It Covers for AI Agents (2026)

In December 2025, Cisco published the Cisco Integrated AI Security and Safety Framework as a formal research report (arXiv:2512.12921). It is not a product datasheet and not a marketing pillar diagram - it is a lifecycle-aware taxonomy that tries to classify the full range of AI risk in one structure, the way MITRE ATT&CK did for enterprise intrusions. For security leaders drowning in partial standards, that ambition is the point.

The framework's defining move is merging two communities that usually talk past each other: AI security (protecting AI systems from unauthorized use, availability attacks, and integrity compromise) and AI safety (ensuring systems behave ethically, reliably, fairly, and in alignment with human values). Cisco argues that for agentic systems - software that plans, calls tools, and acts - the line between a safety failure and a security breach has effectively dissolved, so the taxonomy treats them as one. This guide walks through what the framework actually contains, how it maps onto AI agents and MCP servers, and how a security team puts it to work.

What the Cisco AI security framework is (and is not)

The framework is a taxonomy and operationalization model, authored by Cisco researchers Amy Chang, Tiffany Saade, Sanket Mendapara, Adam Swanda, and Ankit Garg, and released as version 1. Its stated goal is to classify AI risks across modalities, agents, pipelines, and the broader ecosystem in a single, structured reference rather than a checklist of point fixes.

One clarification matters before anything else: the framework is not the same thing as Cisco AI Defense, the commercial product. Cisco ties the framework to AI Defense operationally, alongside open-source MCP Scanner and A2A Scanner tools, but the framework itself is the published research artifact. When someone says "the Cisco AI security framework," they should mean arXiv:2512.12921, not the product brochure.

Cisco explicitly positions the framework as broader than the existing reference points. It argues that MITRE ATLAS, the NIST AI 100-2 adversarial ML (AML) taxonomy, and the OWASP Top 10s for LLM and Agentic AI applications each cover only a partial "slice" of AI risk, and that none of them integrate security with safety or treat the full lifecycle from data through runtime. The framework also maps its own items back to those references, so adopting it does not mean abandoning them - it means subsuming them under one structure.

The four-layer threat taxonomy

The core of the framework is a four-layer structure modeled directly on MITRE ATT&CK. It moves from intent down to observed behavior:

The 19 objectives are organized into three risk groups, which is the most useful mental model for triage:

• Common Manipulation Threats - objectives such as Goal Hijacking (OB-001), Communication Compromise (OB-004), jailbreaks, impersonation/obfuscation, and persistence.
• Data-Related Threats - objectives covering data privacy violations, integrity degradation and sabotage, supply-chain compromise, model theft and extraction, and adversarial evasion.
• Downstream Threats and Impact Risks - objectives covering action-space and integration abuse, availability abuse, privilege compromise, harmful or misleading content, surveillance, and cross-modal risks.

Techniques sit beneath objectives (labeled in an AITech-x.y scheme) - direct and indirect prompt injection, jailbreaks, memory corruption, tool exploitation, supply-chain tampering, and environment-aware evasion among them - and subtechniques (AISubtech-x.y.z) capture variants. Procedures are the bottom layer: documented, observed implementations attackers have actually used, which the report notes are not comprehensively cataloged. This ATT&CK-style nesting is what makes the framework usable for detection mapping rather than just awareness.

Five design elements

Cisco frames the whole structure around five deliberate design choices. They are worth naming because they explain why the taxonomy is shaped the way it is:

1. Integration of AI security threats and content/safety harms into one taxonomy.
2. AI lifecycle awareness, spanning data, training, and runtime rather than a single stage.
3. Multi-agent coordination as a first-class concern, not an afterthought.
4. Multimodality, covering text, image, audio, and cross-modal attack surfaces.
5. An audience-aware utility that presents the same taxonomy at different depths for executives, security leaders, engineers, and red teams.

The embedded taxonomies

Beyond the four-layer core, the framework embeds supporting taxonomies for the surfaces that generic AI risk lists tend to flatten. These are where most of the agent- and infrastructure-specific detail lives.

The 14-threat MCP taxonomy

The most agent-relevant component is a dedicated Model Context Protocol (MCP) taxonomy of 14 threats across four groups: Injection & Interpretation (3), Tool Integrity (3), Data Exfiltration & Access (4), and Execution & Payload (4). It covers how an LLM interprets tools, prompts, metadata, and execution environments through MCP. Cisco treats MCP as critical agentic infrastructure and a major attack surface - consistent with what we see in the field and with the existence of Cisco's own MCP Scanner. For deeper grounding on this surface, see MCP Server Security: The Complete Guide and our writeup on MCP tool poisoning.

The 17-threat agent-to-agent (A2A) taxonomy

Cisco pairs the MCP taxonomy with a companion agent-to-agent (A2A) taxonomy of 17 threats, addressing the protocols that govern how agents discover, message, and delegate to one another - where impersonation, poisoned inter-agent messaging, and orchestration abuse live. It is published as a standalone taxonomy and operationalized through Cisco's open-source A2A Scanner, alongside the MCP Scanner. The v1 report text frames the agentic taxonomies as actively expanding, so expect the A2A items to keep evolving - but the 17-threat set is real and usable today, not merely promised.

The 22-threat supply-chain taxonomy

A separate supply-chain taxonomy enumerates 22 threats across four categories: artifact and format vulnerabilities, model manipulation and tampering (poisoning, malicious adapters), dependency and distribution compromise (typosquatting, CI/CD attacks), and operational/runtime threats (code execution, exfiltration). This is the layer that governs whether an MCP server or model artifact is safe to adopt in the first place - adjacent to our AI Supply-Chain Attacks: A Defender's Guide.

The 25-category content-safety harm taxonomy

Finally, a content-safety harm taxonomy spans 25 categories grouped into five families: cybersecurity and hacking, safety harms and toxicity (hate, self-harm, CBRN and similar), integrity compromise (hallucination, unauthorized financial/legal/medical advice), intellectual-property compromise, and privacy attacks (PII/PHI/PCI). This is the "safety" half of the integration made concrete and measurable.

How it applies to AI agents and MCP servers

Agentic surfaces are well covered across the framework: the core objectives carry the autonomy and tool-access risks, the MCP taxonomy carries the infrastructure risks, and the A2A taxonomy carries the inter-agent and orchestration risks. Read the agentic coverage as the union of those three places rather than a single dedicated layer.

With that in mind, the mapping from framework items to real agent risk is direct. The table below is our reading, intended as an operational bridge:

Two of these deserve emphasis. Persistence and impersonation objectives map cleanly to the shadow-agent problem - agents and MCP servers that run without anyone knowing they exist. That is the same blind spot we describe in Why AI Agents and MCP Servers Are the New Shadow IT: you cannot tag a risk to an OB-ID for an agent your inventory has never seen. And multi-agent and A2A risks - collusion, orchestration abuse, poisoned delegation - only surface with fleet-wide cross-agent visibility; single-agent monitoring misses emergent behavior by construction. Our analysis of multi-agent prompt injection and credential theft shows how quickly that compounds.

How a security team operationalizes it

A taxonomy earns its keep when it changes what you do on Monday. A practical adoption path:

1. Inventory first. Map your real AI footprint - agents, coding assistants, MCP servers - to the objectives and the MCP and A2A taxonomies. You cannot classify risk for assets you have not discovered.
2. Tag detections to OB-IDs. Use the four-layer Objectives → Techniques → Subtechniques → Procedures structure as the labeling scheme for alerts. This gives GRC a consistent vocabulary and aligns red-team findings with defensive coverage.
3. Prioritize by risk group. Triage with the three groups - Common Manipulation, Data-Related, Downstream/Impact - so leadership sees coverage gaps at a glance.
4. Gate adoption with the supply-chain taxonomy. Vet MCP servers and model artifacts against the 22 supply-chain threats before they reach the fleet.
5. Govern continuously, not at review time. The objectives describe runtime risks (drift, persistence, privilege creep) that a point-in-time audit cannot catch.

Step five is where most programs break. For coding agents specifically, the operational detail is heavier than a taxonomy can carry - see Securing AI Coding Agents and CLIs and Governing AI Coding Assistants Across Your Fleet for what that monitoring looks like in practice.

Where continuous agent and MCP visibility fits

The Cisco framework is a strong reference for *what* can go wrong. It does not, and is not meant to, tell you *which* agents and MCP servers exist on your endpoints and fleet right now - that is an inventory problem, not a taxonomy problem. The objectives that depend most on it (persistence, impersonation, privilege compromise, the entire MCP and A2A taxonomies) are exactly the ones that assume you already have continuous discovery in place.

This is the category Anomity works in: discovering and inventorying every AI agent and MCP server, monitoring their permissions and behavior, alerting on anomalies, and producing an audit trail. The four-layer structure gives that audit trail a ready vocabulary - alerts tagged to OB-IDs and techniques for GRC reporting and red-team alignment. The framework supplies the taxonomy; continuous visibility supplies the subjects it classifies. If you want to see what that discovery surfaces in real environments, what we find when we scan AI agent configs is a candid starting point.

Adopt the Cisco framework as your shared language for AI risk. Then make sure your fleet is actually visible enough to use it - because, as ever, you can't govern what you can't see.