SecOps / Frameworks
OWASP LLM Top 10 and MITRE ATLAS: mapped to platform controls
Two lists, one working vocabulary: what the OWASP Top 10 for LLM Applications and the OWASP Top 10 for Agentic Applications mean in practice, and which control addresses each.
OWASP and MITRE give security teams a shared way to talk about AI risk. OWASP ranks what goes wrong; MITRE ATLAS catalogues how adversaries do it. This page lists the current OWASP entries by name and shows how the platform is designed to address them. "OWASP-aligned" here means mapped by design, not certified or audited by OWASP.
The problem: a list is not a control
The OWASP Top 10 for LLM Applications, published by the OWASP GenAI Security Project, is the most cited checklist of language-model risk. The 2025 edition names ten: Prompt Injection, Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation and Unbounded Consumption. Most teams have read it. Fewer can say which of their controls answers which entry.
Agents widened the problem. In December 2025 OWASP released a separate Top 10 for Agentic Applications, for systems that plan, hold memory, call tools and act on delegated authority. Its ten entries are Agent Goal Hijack, Tool Misuse and Exploitation, Identity and Privilege Abuse, Agentic Supply Chain Vulnerabilities, Unexpected Code Execution, Memory and Context Poisoning, Insecure Inter-Agent Communication, Cascading Failures, Human-Agent Trust Exploitation and Rogue Agents.
MITRE ATLAS plays a different role. It is a knowledge base of adversary tactics and techniques against AI systems, modelled on ATT&CK and updated frequently, with recent releases adding agent-focused techniques. SOC teams use it to label what they observe and red teams use it to plan what to try. The sensible approach is to use all three: OWASP for what to prevent, ATLAS for how to describe an attack and your own controls for the rest.
The agentic list in brief, and where it lands
The Agentic Top 10 (ASI01 to ASI10) is newer and less widely mapped, so it gets its own short list here. The LLM Top 10 table is in the section below.
ASI01 Agent Goal Hijack
Goals and permissions are held outside the model context and cannot be rewritten by retrieved content. See prompt injection defense.
ASI02 Tool Misuse and Exploitation
Per-tool policy, scoped credentials and approval on write actions. See MCP and tool security.
ASI03 Identity and Privilege Abuse
A distinct identity and least-privilege access per agent, with an owner. See agent runtime security.
ASI04 Agentic Supply Chain Vulnerabilities
Approved registry, version pinning and review of changed tool definitions and models.
ASI05 Unexpected Code Execution
Bounded execution environments and policy that denies forbidden commands before they run.
ASI06 Memory and Context Poisoning
Controlled retrieval through Cortex access rules, with provenance for what an agent remembers.
ASI07 Insecure Inter-Agent Communication
Agent-to-agent calls pass through the same identity and policy layer as tool calls.
ASI08 Cascading Failures
Rate limits, budgets, action caps and a kill switch to stop a runaway chain.
ASI09 Human-Agent Trust Exploitation
Approval screens show the evidence and the risk, not only the agent's summary, so a person is not asked to rubber-stamp.
ASI10 Rogue Agents
Inventory and discovery, so an unregistered or drifting agent is visible and can be revoked.
Where it sits on the platform
One platform with several entry points. Each product below plays a defined part in this capability.
| Platform entry point | Role in this capability |
|---|---|
| Nexus | Runtime enforcement, inventory, identity graph and audit: the controls behind most entries. |
| Studio | Scoped tools, approval gates and versioned agent definitions. |
| BuildX | Model gateway for input and output screening, logging and consumption limits. |
| Cortex | Access-controlled retrieval, relevant to disclosure and embedding weaknesses. |
| Connect | Scoped, brokered access to external systems. |
What a governance-check agent can and cannot do
Mapping controls to a list is repetitive and suits an agent that gathers evidence while a person judges it. A Trust Profile for one.
Control-Mapping Agent
Collects evidence for each framework entry and drafts a coverage view for the owner.
| Can | Cannot | Requires approval | Records |
|---|---|---|---|
|
|
|
|
Controlled autonomy for framework mapping
Evidence gathering can run at higher autonomy than judgment. Declaring something satisfied remains a human act.
- L1 Assist
The agent lists framework entries and the evidence it found for each.
- L2 Approve
The agent drafts the mapping; a security owner approves each entry.
- L3 Supervise
The agent refreshes evidence on a schedule and flags drift or stale tests for review.
- L4 Autonomous
Routine re-collection and gap alerts run independently within policy. Acceptance of risk is never automated.
- L5 Adaptive
Mapping rules are refined from reviewer corrections, with gated, versioned changes.
The five-level model is described in full on the controlled autonomy page.
OWASP Top 10 for LLM Applications (2025) mapped to controls
The names below are the 2025 edition entries, LLM01 to LLM10. The right-hand column is what the platform is designed to provide for each. It is a mapping of intent, not an assessment, and the OWASP project itself does not certify products.
| Framework | Entry | How the design addresses it |
|---|---|---|
| LLM01:2025 | Prompt Injection | Scoped tools, approval gates, untrusted-content handling and egress control. Filtering helps but is not relied on. |
| LLM02:2025 | Sensitive Information Disclosure | Data classification, access-controlled retrieval, output filtering at the model gateway and per-model data rules. |
| LLM03:2025 | Supply Chain | Approved model and tool registry, version pinning, and supply-chain events for agent-initiated installs. |
| LLM04:2025 | Data and Model Poisoning | Provenance and access control on knowledge sources and fine-tuning data; testing for poisoned retrieval paths. |
| LLM05:2025 | Improper Output Handling | Model output is validated before it reaches a shell, a query or another system; policy denies unsafe commands. |
| LLM06:2025 | Excessive Agency | Minimal tools and permissions, per-action limits, controlled autonomy levels and human approval on high-impact actions. |
| LLM07:2025 | System Prompt Leakage | Secrets and policy are kept out of prompts; authority comes from runtime policy, not from instructions in the prompt. |
| LLM08:2025 | Vector and Embedding Weaknesses | Per-tenant and per-user access control on retrieval, and testing for cross-boundary leakage. |
| LLM09:2025 | Misinformation | Citations to sources, human review where decisions depend on output, and evaluation of answers against known material. |
| LLM10:2025 | Unbounded Consumption | Rate limits, token and spend budgets, per-agent caps and cost attribution. |
| MITRE ATLAS | Tactics and techniques (versioned; for example AML.T0051 LLM Prompt Injection, AML.T0010 AI Supply Chain Compromise) | Findings and runtime events are labelled with ATLAS techniques so SOC and red-team work share a vocabulary. Check atlas.mitre.org for the current release. |
EU angle: frameworks as a bridge to the regulations
OWASP and ATLAS are not law, but they give concrete content to open-ended legal duties. Mapping to them helps produce evidence that supports, and does not replace, the legal analysis.
| Instrument | Reference | Supports evidence for |
|---|---|---|
| EU AI Act | Art. 15 accuracy, robustness and cybersecurity | Art. 15 refers to resilience against attempts to alter a system's use, outputs or performance, and to measures against data poisoning. The OWASP and ATLAS entries give those duties a concrete vocabulary. Supports evidence; harmonised standards may add detail. |
| NIS2 | Art. 21 risk-management measures | Supports evidence that AI-specific risks sit inside your risk analysis and measures. |
| DORA | ICT risk management framework | Supports mapping of AI-specific threats into the ICT risk register of an in-scope entity. |
| GDPR | Art. 32 security of processing | Supports evidence that disclosure and poisoning risks to personal data were considered. |
Swfte is built compliance-by-design. It provides the technical controls, governance mechanisms and evidence required to deploy AI within an organisation's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration. Nothing on this page is legal advice. Swfte's own security attestations are listed on the trust page.
What this page does not claim
- Mapping is not certification. OWASP does not certify products and Swfte makes no such claim.
- The lists are versioned. The names here are the 2025 LLM edition and the 2026 Agentic edition as published; check genai.owasp.org for the current text.
- ATLAS changes frequently, and technique counts differ between releases. We cite no counts.
- Nothing here claims that your use of the platform is compliant with any regulation. Swfte's own security attestations are listed on the trust page.
Frequently asked questions
What is the OWASP Top 10 for LLM Applications?
A ranked list of the most critical security risks for applications built on large language models, maintained by the OWASP GenAI Security Project. The 2025 edition lists Prompt Injection, Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation and Unbounded Consumption.
What is the difference between the LLM Top 10 and the Agentic Top 10?
The LLM list covers applications that use a model. The Agentic list, released in December 2025, covers systems that plan, keep memory, call tools and act with delegated authority, adding risks such as goal hijack, rogue agents and cascading failures.
What is MITRE ATLAS?
ATLAS, the Adversarial Threat Landscape for Artificial-Intelligence Systems, is a MITRE knowledge base of tactics and techniques used against AI systems, built on the ATT&CK model. It is updated frequently and has been adding agent-focused techniques.
Is Swfte OWASP compliant or certified?
No such certification exists for OWASP lists, and we do not claim one. Our controls are mapped to the entries by design, and the mapping is something you can test with the red-teaming workflow.
Where do I start?
With Excessive Agency and Prompt Injection, because limiting what an agent can do contains several other entries as a side effect. Then add output handling, disclosure and consumption limits.
The rest of SecOps
Nine pages cover both halves. Each has a different job.
AI for security operations
Security for AI
Frameworks and evidence
Back to the SecOps hub.
Build OWASP LLM Top 10 with Swfte
Start with one agent and one policy, or talk to the team about your environment, your data and your regulators.