Our editorial model
AI security layers: an 8-layer model for LLM apps and agents
AI Security Layers sorts the controls for LLM apps and agents into eight budget lines, from knowing which AI you run to stopping a misbehaving agent, and maps each line to OWASP, MITRE ATLAS and NIST AI RMF. All 111 tools in the directory are placed in at least one layer.
Executive summary
- What it is
- AI Security Layers sorts the controls for LLM apps and agents into eight budget lines, from knowing which AI you run to stopping a misbehaving agent, and maps each line to OWASP, MITRE ATLAS and NIST AI RMF.
- The risk
- Buying by product category leaves blind spots: an input filter does not limit what an agent's tools can do, and no tool protects AI that nobody has found. Mapping spend to layers shows which risks have no owner or control.
- What to buy or do
- Fund layers 1 and 2 first: an AI register with owners and automated discovery of the AI in use. Then add testing and runtime guardrails for exposed apps, agent access controls before agents act, and send every layer's logs to the security operations center.
Our editorial model, not a standard
AI Security Layers is AI Defense Stack's own model for organizing AI security controls and the tools that provide them. It is not a standard, and OWASP, MITRE and NIST did not create or endorse it. Each link to their frameworks is labeled: Source states means their text names the control or outcome; Our analysis means we drew the link. Placing a tool in a layer is our analysis and rests on a capability the tool's own sources document.
OWASP published a 2026 edition of its Top 10 for LLM Applications on August 3, 2026 Source, checked October 21, 2026: genai.owasp.org (opens in a new tab) . Its resource page does not list the ten 2026 entries, and OWASP's list page still shows LLM01:2025 to LLM10:2025 Source, checked October 21, 2026: genai.owasp.org (opens in a new tab) , so this model and every tool mapping use the 2025 ids. We will switch to the 2026 list once its final entries are on OWASP's list and risk pages.
The 8 layers in four phases
Each layer is a budget line a buyer funds separately. The numbers count tools that have the layer as their primary placement, plus tools from other categories that also document a capability in it. Select a layer to see its controls, standards and tools.
-
Know what you run
-
Secure what you build and buy
-
Protect what runs
-
Detect and respond
What each layer answers
Our analysis The question, the budget line and the tool counts are our analysis. Compare products with Coverage Scores on the category hubs. Monitoring and response has no category of its own: a tool is placed there when its main documented job is AI detection and response.
| Layer | The question it answers | Budget line | Category | Tools |
|---|---|---|---|---|
| L1Governance and risk | Which AI systems do we run, who approved them, what risk does each carry, and can we prove it? | An AI governance, risk and compliance platform, often shared with privacy, legal and compliance. | Governance | 7 primary, 0 also cover it |
| L2Discovery and posture | What AI is running in our clouds, SaaS apps and endpoints, and which of it is exposed or misconfigured? | AI security posture management, usually an add-on to a cloud security (CNAPP or CSPM) or data security (DSPM) platform; workforce shadow AI discovery often comes with browser or DLP products. | AI-SPM | 8 primary, 20 also cover it |
| L3Model and supply chain | Can a model, dataset or AI component we pull in run code or hide a backdoor, and can we prove where it came from? | AI and ML supply chain security, usually inside application security, software supply chain or artifact registry budgets. | Supply chain | 9 primary, 8 also cover it |
| L4Testing and red teaming | Have we attacked this model, app or agent the way an adversary would, and do we repeat it after each change? | AI red teaming tools or a managed red team service, usually in offensive security or application security testing; evaluation frameworks often sit with ML teams. | Red teaming | 24 primary, 9 also cover it |
| L5Data protection | What sensitive data reaches AI tools and models, and can we block, mask or tokenize it first? | Data loss prevention for AI (browser and endpoint DLP, prompt inspection), PII redaction services and tokenization vaults, usually in the data security budget. | Data protection | 10 primary, 17 also cover it |
| L6Runtime guardrails | When a prompt attack or unsafe output hits a live AI app, what catches it and what happens next? | An LLM firewall, guardrail API or AI gateway, often bought from an API gateway, edge, WAF or cloud provider. | Guardrails | 25 primary, 11 also cover it |
| L7Agent and tool access | What can our AI agents do with the tools, data and credentials we gave them, and who approves risky actions? | An agent security platform or MCP gateway, next to identity and access management and API security. | Agent security | 26 primary, 12 also cover it |
| L8Monitoring and response | If an AI system or agent is attacked or misbehaves, will we see it, and can we respond and prove what happened? | An AI detection and response product, or an extension of the SIEM, EDR or XDR a security operations center already runs. Log storage often shares the budget. | None of its own | 2 primary, 24 also cover it |
How the layers map to standards
Source states means the framework's own text names the control or outcome that layer delivers. Our analysis means we drew the link. A blank cell means we map nothing. Each layer page lists every row with where the source says it.
OWASP Top 10 for LLM Applications (2025)
| OWASP LLM Top 10 (2025) | Layer 1, Governance and risk | Layer 2, Discovery and posture | Layer 3, Model and supply chain | Layer 4, Testing and red teaming | Layer 5, Data protection | Layer 6, Runtime guardrails | Layer 7, Agent and tool access | Layer 8, Monitoring and response |
|---|---|---|---|---|---|---|---|---|
| LLM01Prompt Injection | S Source states | S Source states | S Source states | |||||
| LLM02Sensitive Information Disclosure | S Source states | A Our analysis | A Our analysis | S Source states | S Source states | |||
| LLM03Supply Chain | S Source states | A Our analysis | S Source states | S Source states | ||||
| LLM04Data and Model Poisoning | S Source states | S Source states | S Source states | S Source states | ||||
| LLM05Improper Output Handling | A Our analysis | S Source states | A Our analysis | S Source states | ||||
| LLM06Excessive Agency | A Our analysis | A Our analysis | A Our analysis | S Source states | ||||
| LLM07System Prompt Leakage | A Our analysis | A Our analysis | S Source states | S Source states | ||||
| LLM08Vector and Embedding Weaknesses | A Our analysis | S Source states | S Source states | |||||
| LLM09Misinformation | S Source states | A Our analysis | S Source states | |||||
| LLM10Unbounded Consumption | S Source states | S Source states | S Source states |
OWASP Top 10 for Agentic Applications (2026)
| OWASP Agentic Top 10 (2026) | Layer 1, Governance and risk | Layer 2, Discovery and posture | Layer 3, Model and supply chain | Layer 4, Testing and red teaming | Layer 5, Data protection | Layer 6, Runtime guardrails | Layer 7, Agent and tool access | Layer 8, Monitoring and response |
|---|---|---|---|---|---|---|---|---|
| ASI01Agent Goal Hijack | S Source states | S Source states | S Source states | S Source states | ||||
| ASI02Tool Misuse and Exploitation | A Our analysis | S Source states | S Source states | |||||
| ASI03Identity and Privilege Abuse | A Our analysis | S Source states | ||||||
| ASI04Agentic Supply Chain Vulnerabilities | S Source states | S Source states | S Source states | |||||
| ASI05Unexpected Code Execution (RCE) | A Our analysis | S Source states | S Source states | |||||
| ASI06Memory & Context Poisoning | S Source states | S Source states | S Source states | |||||
| ASI07Insecure Inter-Agent Communication | S Source states | |||||||
| ASI08Cascading Failures | A Our analysis | S Source states | S Source states | S Source states | ||||
| ASI09Human-Agent Trust Exploitation | S Source states | S Source states | S Source states | |||||
| ASI10Rogue Agents | S Source states | S Source states |
NIST AI Risk Management Framework (functions and subcategories)
| NIST AI RMF function | Layer 1, Governance and risk | Layer 2, Discovery and posture | Layer 3, Model and supply chain | Layer 4, Testing and red teaming | Layer 5, Data protection | Layer 6, Runtime guardrails | Layer 7, Agent and tool access | Layer 8, Monitoring and response |
|---|---|---|---|---|---|---|---|---|
| GOVERNGovern | S Source states 1.1, 1.2, 1.6, 2.2, 6.1 | S Source states 1.6 | S Source states 6.1 | S Source states 4.3 | S Source states 4.3 | |||
| MAPMap | S Source states 1.1 | A Our analysis 4.2 | S Source states 4.1, 4.2 | S Source states 3.5 | ||||
| MEASUREMeasure | A Our analysis 2.7 | S Source states 1.3, 2.7, 2.11 | A Our analysis 2.10 | S Source states 2.4 | ||||
| MANAGEManage | S Source states 1.2 | S Source states 3.1, 3.2 | A Our analysis 1.3 | A Our analysis 1.3 | S Source states 2.4 | S Source states 2.3, 4.1, 4.3 |
MITRE ATLAS techniques and mitigations are listed on each layer page, and the ATLAS hub holds the data version we read. The OWASP LLM matrix uses the 2025 ids until the 2026 list is final: see the OWASP hub.
Gaps we can see
- Only 2 tools in this directory have AI detection and response as the main documented job. The other tools placed in the monitoring and response layer document logging or monitoring as one feature among others, so check each tool's capabilities before you rely on it for incident response.
- Only 3 tools (Protecto, Pangea AI Guard, Lakera Red) are mapped to OWASP LLM08 Vector and Embedding Weaknesses. No listed tool documents posture checks of vector store access.
- No tool in this directory documents MITRE ATLAS mitigation AML.M0007 Sanitize Training Data.
- No tool in this directory documents signing or mutual authentication of agent-to-agent messages, which is the gap against OWASP ASI07 Insecure Inter-Agent Communication.
- Some governance platforms also describe runtime features. Their capabilities carry governance tags, which are not evidence for layers 5, 6 or 7, so we do not place those platforms there.
The LLM08 count comes from the tool files. The other statements are our reading of the tool files on October 21, 2026.
Tools whose documented capabilities span three layers
Our analysis Spanning more layers is not a quality signal. Check each layer's capabilities on the tool page before you rely on a secondary placement.
How we place tools in layers
- The category comes first. A tool sits in the layer of the category that matches its main documented job, so its primary layer is never a judgment call.
- A tool gets at most two more layers, and only when its own sources document a capability that does that layer's job. A matching tag in our vocabulary is not enough: the capability has to describe the layer's work.
- We never reword a capability, change a tag or move a category to reach a layer, and sponsorship or an affiliate link never places a tool.
- When more than two layers qualify, we keep the two with the most qualifying capabilities. On a tie, a layer the vendor sells as a named product or module wins, then the lower layer number.
- Archived and deprecated tools keep their layers. Layer pages list them last, with their badge.
- A tool whose main job fits no layer, for example deepfake or voice fraud detection, is not forced into one. We log it, and three or more such tools would trigger a proposal to change the model. Detection and response for a security operations center has been layer 8 since tools documenting it as their main job were added.
- Monitoring and response has no category, so it is a tool's primary layer only when the tool documents at least two capabilities that match the layer and its description names detection and response as its main job. Otherwise it is a secondary layer, like any other.
- Layers never change the Coverage Score. The score measures what a vendor documents inside its own category.
Read the full scoring and sourcing rules on the methodology page.
AI security layers FAQ
Is AI Security Layers a standard?
No. It is our editorial model for sorting AI security controls and the tools that provide them. OWASP, MITRE and NIST did not create or endorse it. Every link from a layer to their frameworks is labeled Source states, when their text names the control, or Our analysis, when we drew the link.
Which layer should we fund first?
Our analysis: governance and discovery, because every other layer needs a list of the AI systems in use, their owners and their risk tier. NIST AI RMF calls GOVERN a cross-cutting function that enables the other functions, and says that once a governance structure is in place the other functions may be performed in any order. After that, follow your exposure: testing and runtime guardrails for public LLM apps, and agent and tool access controls before agents act on real systems.
How is a layer different from a tool category?
A category is where we compare products with Coverage Scores, for example guardrails. A layer is a budget line and a set of controls. Each tool category sits under one layer, and a tool can cover up to two more layers when its own sources document a capability that does that layer's job. Monitoring and response is the one layer with no category of its own.
Does a tool that spans three layers cover more risk?
Not necessarily. A secondary placement rests on one or more documented capabilities, not on depth. A dedicated product may document far more controls in a layer than a platform that offers the same layer as one module. Read the capabilities behind each placement on the tool page before you count on it.
Why does the model still use the 2025 OWASP LLM ids?
OWASP's Top 10 for LLM Applications list page still shows the 2025 entries, LLM01:2025 to LLM10:2025, and the directory's mappings and scores use those ids. OWASP published a 2026 edition on August 3, 2026, but its resource page does not list the ten 2026 entries and does not say whether the list is final. We will switch the model and the tool mappings to the 2026 list once its final entries are on OWASP's list and risk pages, and the OWASP hub says so.
Framework sources & last reviewed
OWASP Top 10 for LLM Applications 2025 (list page)
- genai.owasp.org/llm-top-10 checked
OWASP LLM01:2025 Prompt Injection
OWASP LLM02:2025 Sensitive Information Disclosure
OWASP LLM03:2025 Supply Chain
OWASP LLM04:2025 Data and Model Poisoning
OWASP LLM06:2025 Excessive Agency
OWASP LLM07:2025 System Prompt Leakage
OWASP LLM08:2025 Vector and Embedding Weaknesses
OWASP LLM10:2025 Unbounded Consumption
OWASP GenAI LLM Top 10 2026 (resource page, dated August 3, 2026)
OWASP Top 10 for Agentic Applications for 2026 (resource page)
OWASP Top 10 for Agentic Applications 2026 (PDF, December 2025)
- genai.owasp.org/download/52117 checked
MITRE ATLAS (ids and names from the published ATLAS data file, version 2026.09)
- atlas.mitre.org checked