OWASP AI Exchange Guide: Threats, Controls, Standards

Most AI security programmes start from a short risk list and then discover it does not tell them which controls to build, who owns them or how they relate to the standards their auditors will use. The OWASP AI Exchange is the open knowledge base that fills that gap: a threat and control framework for all kinds of AI, from predictive models to agents, that has also fed text into ISO/IEC 27090 and the draft European cybersecurity standard for the EU AI Act. This guide explains how the Exchange is organised, how to navigate its threats and controls, how to turn it into a working risk process, and where it sits beside the other frameworks. It is written for security architects, AI platform owners and risk leads who need a control catalogue rather than another top ten. Facts were checked against owaspai.org on 8 November 2026.

Key takeaways

It is a control framework, not a top ten. The Exchange describes threats across the whole AI lifecycle and names specific controls for each, with a ten-step risk analysis process to select them.
Three threat families organise everything. Threats through use (input attacks such as prompt injection and evasion), development-time threats (such as data and model poisoning) and other runtime threats to the system around the model.
It shapes formal standards. The project states that it contributed around 70 pages each to ISO/IEC 27090 and to prEN 18282, the CEN/CENELEC cybersecurity specification for AI systems, so aligning with it now eases later conformance work.
Agents are covered as an attention point. The Exchange treats agentic AI as conventional AI threats with more reach, assumes prompt injection will sometimes succeed, and focuses on least model privilege, blast radius control and observability.
It is free to reuse. The content is published under CC0 1.0, so you can copy controls into policies and tooling without licence friction, while crediting the source as the project asks.

What it is and who it applies to

The OWASP AI Exchange, at owaspai.org, is an OWASP Flagship project (status granted in March 2025) that describes itself as a framework of AI security and privacy threats, controls and related practices. It was founded in 2022 by Rob van der Veer, who remains lead editor; it started life as the "AI security and privacy guide" and was renamed AI Exchange about a year later. The project says its author group has more than 170 experts who go through a screening process, and the home page lists 383 pages of content, edited openly through a GitHub repository and also published as a PDF snapshot.

Three features distinguish it from the better known OWASP lists:

Scope: it covers all AI, including heuristic systems and classic machine learning as well as large language models, not only generative AI.
Depth: it is written as a complete threat and control framework, with controls grouped by purpose and mapped to threats, plus testing and privacy chapters.
Relationship to the GenAI Security Project: the OWASP GenAI Security Project, which owns the Top 10 for LLM Applications and the Top 10 for Agentic Applications, is a separate OWASP project. The Exchange positions itself as the core framework on AI security fundamentals and points to GenAI project material where relevant. Use the top tens for awareness and test scoping, and the Exchange for control selection. See the OWASP Top 10 for LLM Applications Guide.

It applies to anyone who builds, buys or operates AI: model creators, teams integrating third-party models through APIs, platform teams running retrieval and agent infrastructure, and risk and compliance functions that need a vocabulary aligned with emerging standards.

Structure and key requirements

The Exchange is one resource split into numbered chapters. Knowing the map saves time, because most questions land in one chapter.

Chapter	What it covers	Use it when
0. AI Security Overview	Threat model, controls overview, the periodic table, risk analysis, agentic AI	Starting a programme or a threat model
1. General controls	Governance, data limitation, limiting unwanted behaviour (for example oversight and least model privilege)	Writing policy and organisation-wide controls
2. Input threats and controls	Evasion, prompt injection, sensitive data disclosure through use, model exfiltration, resource exhaustion, culture-sensitive alignment	Securing inference endpoints and applications
3. Development-time threats	Model poisoning, development data leaks, development environment security	Training, fine-tuning and model sourcing
4. Runtime conventional security threats	Runtime model poisoning and leaks, output containing conventional injection, input data leaks, augmentation data leaks and manipulation	Hardening serving, retrieval and plugin infrastructure
5. AI security testing	Threats to test for, red teaming tools for generative and predictive AI	Planning assurance and red team scope
6. AI privacy	Use limitation, fairness, data minimisation, transparency, privacy rights, accuracy, consent, model attacks	Joint security and privacy reviews
7. References	Overviews of threats and incidents, learning resources, an index	Finding further reading

The threat model

The overview groups threats into three families: development-time threats (while data is obtained and prepared and the model is trained or sourced), threats through use (an attacker supplies input and reads output, for example prompt injection or evasion) and other runtime threats (attacks on the system around the model that do not go through inference, such as stealing model input). Impacts fall under three attacker goals: disclose, deceive and disrupt.

The controls

Controls carry short names that the Exchange writes in capitals, and the Essentials section groups them by purpose:

Manage: governance and compliance (AI PROGRAM, SEC PROGRAM, SECDEV PROGRAM, CHECK COMPLIANCE, SEC EDUCATE), supply chain (SUPPLY CHAIN MANAGE), development-time (DEV SECURITY, SEGREGATE DATA, DISCRETE) and runtime controls such as MODEL ACCESS CONTROL, RUNTIME MODEL INTEGRITY, RUNTIME MODEL CONFIDENTIALITY, ENCODE MODEL OUTPUT, LIMIT RESOURCES and AUGMENTATION DATA INTEGRITY.
Have resilient models: model-level measures such as MODEL ALIGNMENT, CONTINUOUS VALIDATION, POISON ROBUST MODEL, EVASION ROBUST MODEL, TRAIN ADVERSARIAL and DATA QUALITY CONTROL.
Watch: input and output handling such as PROMPT INJECTION I/O HANDLING, ANOMALOUS INPUT HANDLING, SENSITIVE OUTPUT HANDLING, RATE LIMIT and MONITOR USE.
Limit: reducing exposure and impact, such as DATA MINIMIZE, ALLOWED DATA, SHORT RETAIN, OVERSIGHT, LEAST MODEL PRIVILEGE, AI TRANSPARENCY and EXPLAINABILITY.

The periodic table and the AI security matrix

The periodic table maps every threat category to its controls in one view. Its clickable companion, the AI security matrix, lists each threat with three attributes: the asset and impact (for example model behaviour integrity or training data confidentiality), the attack surface and lifecycle stage (runtime input, a deployed system, the engineering environment or the supply chain) and the threat category itself. The table below shows how four common threats resolve to controls.

Threat	Asset and attack surface	Typical Exchange controls
Direct and indirect prompt injection	Model behaviour integrity, runtime input	PROMPT INJECTION I/O HANDLING, INPUT SEGREGATION, LEAST MODEL PRIVILEGE, OVERSIGHT
Data poisoning of training or fine-tuning data	Model behaviour integrity, engineering environment and supply chain	DATA QUALITY CONTROL, SUPPLY CHAIN MANAGE, POISON ROBUST MODEL, DEV SECURITY, SEGREGATE DATA
Model exfiltration through input and output harvesting	Model confidentiality, runtime input	MODEL ACCESS CONTROL, RATE LIMIT, MONITOR USE, RUNTIME MODEL CONFIDENTIALITY
Sensitive data disclosure in output	Training, input or augmentation data confidentiality	DATA MINIMIZE, ALLOWED DATA, SHORT RETAIN, SENSITIVE OUTPUT HANDLING, AUGMENTATION DATA CONFIDENTIALITY

The risk analysis process

The overview sets out ten steps: identify risks (with a decision tree that produces a threat model), evaluate risks by likelihood and impact, decide risk treatment, communicate and monitor risk, arrange responsibility, verify external responsibilities, select controls, accept residual risk, manage the selected controls, and reassess continuously. Steps five and six matter most when you consume models from a provider: the Exchange expects you to know which controls the supplier owns and to verify them.

Identity and NHI requirements

Identity runs through the Exchange mainly via two controls, and both concern non-human identities: the models, agents and services that call each other.

LEAST MODEL PRIVILEGE: limit what the model or agent can do so that a manipulated model cannot do much harm. The agentic guidance under this control describes deny-by-default access, policy enforced by infrastructure rather than by the model, task-bound tokens, a distinct agent identity, signed delegation chains and scope that never expands as a task passes between agents.
MODEL ACCESS CONTROL: restrict who and what can query a model. For machine-to-machine calls between agents and services the Exchange points to scoped tokens, session binding and mutual authentication.
OVERSIGHT: human or automated checks on consequential actions, the backstop when least privilege still leaves a risky capability in place.

In practice this means every agent and model-serving workload needs its own registered identity, short-lived credentials scoped to the task, and an owner. A shared API key used by several agents defeats both controls, because you can neither scope it to a task nor attribute an action. See the Agent Identity and Access Guide and the Non-Human Identity (NHI) Guide.

Agentic AI in the Exchange

The Exchange defines agentic AI as systems where model inference can trigger actions without per-action human approval, and describes a spectrum from mildly to very agentic using four properties: action, autonomy, complexity and operation across multiple systems. It treats prompt injection as the key agent threat, highlights the "lethal trifecta" of untrusted data, access to sensitive data and an outbound channel, and groups agent controls into prevention, blast radius control and observability. Its stance is that agents do not need a separate threat landscape; they raise the stakes on existing threats. See the Agentic AI Security Guide.

Implementation steps

The following rollout is NHI Mgmt Group's recommended way to adopt the Exchange; adjust the pace to your AI estate.

Inventory AI systems and their identities. List each model, retrieval pipeline and agent, whether it is built, fine-tuned or consumed through an API, the data it touches and the credentials it uses. Without this the Exchange's decision tree has nothing to run against.
Run the threat model per system. Use the overview's decision tree to decide which of the three threat families apply. A team calling a hosted model through an API will drop most development-time threats but keep input and runtime threats.
Assign responsibility. For each applicable threat, record whether you, the model provider or the platform owns the control (steps five and six). Request evidence from suppliers for the controls they own.
Select controls from the periodic table. Copy the control names into your control register so policies, tickets and test cases share one vocabulary. Start with the Limit and Manage groups, which give the biggest reduction for agents.
Pilot on one high-exposure system. Pick an agent with tool access or an internet-facing assistant. Implement least model privilege, input segregation and monitoring first, then test with the threats listed in chapter 5.
Accept and record residual risk. Have the system owner sign off what remains, with a review date.
Scale and keep current. The Exchange changes continuously, so record the date you last aligned and review quarterly. If a new control version conflicts with your implementation, keep your current control in place until the replacement is tested; nothing in adoption requires a hard cut-over.

Small and large organisations

A small team consuming third-party models can work from the Essentials control list and the agentic section in a few days. A large organisation building models should adopt the full ten-step process, give each chapter an owner and map the control names into its governance, risk and compliance tooling.

Evidence and assessment

The Exchange is not a certification scheme, so evidence is whatever demonstrates that the selected controls work. Useful artefacts:

Threat model record: the decision tree outcome per system, with excluded threats and the reason.
Control register: Exchange control names mapped to owners, implementation status and your framework of record.
Test results: prompt injection, evasion and data leakage tests drawn from chapter 5. See the OWASP AI Testing Guide.
Identity evidence: agent identity inventory, credential lifetimes and scopes, and logs that attribute each tool call to an agent and its delegating user.
Supplier evidence: responses from model and platform providers for the controls they own.

Metrics that show the programme is working (our suggestions):

Percentage of AI systems with a recorded threat model and residual risk sign-off.
Percentage of agents with a unique identity and task-scoped credentials, against a target of 100%.
Prompt injection test pass rate per release, tracked over time.
Median credential lifetime for agent and model-serving identities.
Number of high-exposure systems with MONITOR USE alerts tuned and reviewed.

Mapping to other frameworks

The Exchange links to many standards through OpenCRE and states complete alignment with the SANS Critical AI Security Guidelines. The table maps its main elements to common frameworks; coverage is partial unless stated. See the AI Security Frameworks Crosswalk Guide for the wider picture.

Exchange element	ISO/IEC and EU	NIST	MITRE ATLAS
Whole threat and control framework	ISO/IEC 27090 (Final Draft International Standard, stage 50.00 on iso.org when checked); prEN 18282 (CEN/CLC/JTC 21 WG 5)	SP 800-53 RA-3 Risk Assessment	Tactics and techniques as attack detail
Prompt injection	EU AI Act Art. 15 robustness and cybersecurity	SI-4 System Monitoring	AML.T0051 LLM Prompt Injection
Data poisoning	ISO/IEC 27090 poisoning guidance	SR-3 Supply Chain Controls and Processes	AML.T0020 Poison Training Data
Model exfiltration	ISO/IEC 27001:2022 access control controls	AC-6 Least Privilege	AML.T0024 Exfiltration via AI Inference API
Least model privilege, model access control	EU AI Act Art. 14 human oversight (high-risk)	AC-6, IA-9 Service Identification and Authentication; CSF PR.AA-05	AML.T0053 AI Agent Tool Invocation
Supply chain management	ISO/IEC 42001 AI management system processes	CSF GV.SC-01	AML.T0010 AI Supply Chain Compromise

For the standards themselves see the ISO/IEC 27090 AI Security Guide, the EU AI Act Conformity Assessment and Harmonised Standards Guide and the MITRE ATLAS Guide. The project also says it feeds ISO/IEC 27091 on AI privacy. Draft standards change during approval, so check the current stage on the ISO and CEN pages before citing them in a compliance statement.

Common pitfalls

Treating a top ten as the control set. The project notes that the LLM Top 10 is deliberately not complete. Teams that stop there miss development-time and runtime infrastructure threats the Exchange covers.
Skipping responsibility steps. Consumers of hosted models often assume the provider handles poisoning and model integrity without asking for evidence. Steps five and six exist to stop that.
Relying on the model to enforce policy. The agentic guidance expects infrastructure-enforced authorisation. A system prompt that says "never delete records" is not a control.
Shared credentials for agents. One API key for several agents breaks least model privilege and attribution. Issue an identity per agent.
Copying controls without dating them. The Exchange is updated continuously. A register without an alignment date drifts silently.
Ignoring privacy. Chapter 6 sits alongside security for a reason; data minimisation and short retention reduce disclosure impact as much as output filtering does.

Practitioner checklist

Inventory every model, retrieval pipeline and agent with its data, credentials and owner.
Run the Exchange threat model decision tree for each system and record excluded threats.
Record who owns each control: you, the model provider or the platform, and collect supplier evidence.
Adopt Exchange control names in your control register, mapped to your framework of record.
Give every agent its own identity, task-scoped short-lived tokens and an accountable owner.
Enforce agent authorisation in infrastructure, with deny-by-default and no scope expansion across delegation.
Test for prompt injection, evasion and data leakage using chapter 5 before each major release.
Monitor use and rate-limit model endpoints to detect exfiltration and resource abuse.
Sign off residual risk per system and review the alignment date every quarter.

Standards and references

Related NHI Mgmt Group resources: AI Security Frameworks Crosswalk Guide · OWASP AIVSS Guide · ISO/IEC 27090 AI Security Guide · Agentic AI Security Guide

OWASP AI Exchange Guide: The Open AI Security Knowledge Base