OWASP AI Exchange: Build a Threat-to-Control Ownership Map

The OWASP AI Exchange gives practitioners a wide catalog of AI threats and controls, along with privacy concerns and implementation guidance. Its breadth is useful, but it creates an immediate operating question: which parts apply to this system, and which component can change the outcome? The answer is a system-specific ownership map. Select the relevant threats, assign each control to an enforcement point, test it on the real path, and retain the observed result.

TL;DR

• Use the OWASP AI Exchange as a living body of knowledge, not as a checklist to copy into an assessment.
• Scope one deployed AI system and select threats that match its assets and lifecycle, along with its data flows and authority.
• Assign every chosen control to the component that can prevent or detect the event, with containment assigned where needed.
• Give each control a test procedure, expected result, evidence fields, owner, and retest trigger.
• DeepInspect covers only authenticated HTTP model traffic deliberately routed through its boundary, not the complete Exchange.

The OWASP AI Exchange is broader than a top-ten list

OWASP describes the AI Exchange overview as a comprehensive resource for the security and privacy of AI and data-centric systems. It covers analytical and discriminative systems as well as generative, agentic, and heuristic systems. The project organizes AI-specific threats and controls while pointing readers to conventional security resources for the rest of the software system.

That scope distinguishes the Exchange from a short awareness list. A top-ten list helps a team discuss a compact set of common risks. The Exchange supports deeper threat analysis across development, model inputs, runtime behavior, data, privacy, testing, and governance. It is also a living publication. A control map therefore needs a source date and a review trigger rather than a claim that the organization has permanently "implemented OWASP."

Start by naming the deployed use case. "Customer support agent" is still too broad. Record the users and model route; the retrieval sources and memory; the tools and output destinations; and the actions the system may take. The NIST AI RMF implementation guide can provide the wider governance process. The Exchange can supply the technical threat and control detail for the system inside that process.

Scope the system before selecting threats

The Exchange's risk-analysis guidance says relevance and severity depend on the use case and architecture, along with the deployment and context. That is the practical starting point. Draw the components and data flows for one production-like path, then mark the assets that could be harmed or manipulated. Include model behavior and model parameters. Include training and augmentation data; credentials and prompts; outputs and memory; and tool permissions where they exist.

Next, separate the lifecycle phases represented in the architecture. A poisoned training corpus is a development-time problem. Direct prompt injection arrives through input at inference time. A vulnerable API around the model is conventional runtime security. Those risks may appear in one application, but they have different owners and test environments.

A useful threat statement names the actor and action, then the asset and effect. "Prompt injection" alone is a category. "An external document inserts instructions that cause the claims agent to expose another customer's retrieved record" gives the team something it can assign and test. The existing AI agent post-authentication gap matters when an authenticated user is later represented by an overpowered service identity.

Build the threat-to-control ownership map

For each relevant threat, create a record with the threatened asset and preventive control; the detective control and containment action; and the owning component and accountable team. Add the evidence expected from each control. The owner must have enough authority to alter the event.

Consider a retrieval agent that can call a refund tool. Document validation at ingestion owns one part of indirect prompt injection. Permission-aware retrieval belongs at the index or retrieval service. The tool or its authorization service owns the final refund permission. A model request gateway can inspect the prompt and destination only when traffic crosses that gateway. Incident response owns credential revocation and queue cancellation after abuse is confirmed.

This assignment avoids the most common framework failure: labeling one product as the answer to every row. The confused deputy control guide shows why the downstream tool needs the original identity and delegated purpose. A gateway decision cannot replace authorization for money or permissions, including access to records.

The Exchange connects governance and security controls

The Exchange's general controls page calls for an AI program that inventories AI initiatives and performs impact analysis, includes AI in risk management, and assigns responsibilities. It separately calls for a security program that covers the whole AI lifecycle and AI-specific concerns.

Use those controls to define the operating system around the threat map. The AI inventory identifies what needs assessment. Architecture and data-flow records establish scope. Named owners select and implement controls. A risk register records residual risk and acceptance. Change management triggers reassessment when the model or data source changes, or when a tool permission or deployment route changes.

The output is not a certificate. It is a versioned review packet. That packet should contain the system diagram and selected Exchange threats; control owners and test results; exceptions and residual-risk decisions; and the source version or access date. It should also state which Exchange sections were considered but found irrelevant, with the reason. Explicit exclusions are more defensible than blank rows.

Every selected control needs an executed test

A control description becomes evidence only after the team observes it on the production-like path. Write one permitted case and one denied or adversarial case for each enforcement point. Define the expected system state after both. Then retain the request and configuration version; the observed result and reviewer; and the time.

For an indirect prompt-injection test, place a known instruction in a retrieval document and ask the application a question that retrieves it. The expected result may be a block, sanitized context, constrained output, or refusal to invoke a tool. The evidence should show which control acted and whether the sensitive action occurred. "Guardrails enabled" does not show either fact.

For a delegated-action test, send the same tool request under two identities with different authority. Confirm that the allowed user succeeds and the other is denied at the tool boundary. Preserve the policy and identity chain used for the decision. AI policy enforcement at the HTTP layer covers the narrower request-path test when the model call itself is the enforcement point.

Retest the controls after meaningful changes to the application or its dependencies. A new retrieval source can introduce a different trust boundary. A larger context window can change attack behavior, while a newly connected tool expands the possible impact. A model upgrade can alter the effectiveness of probabilistic defenses. The review date belongs beside the result, not buried in meeting notes.

Map the HTTP slice without overstating it

For an authenticated application calling a model endpoint over HTTP, the request boundary can own several controls. It can verify that the caller context reaches the policy point. It can classify prompt content and restrict destinations, apply an identity-bound policy, and log the decision before forwarding allowed traffic. Response controls can inspect the returning content when the response follows the same route.

That slice is important because it sits on a repeatable path. It is also incomplete. Training-data integrity lives in the data and training pipeline. Retrieval authorization lives at the retrieval layer. Local and STDIO execution do not cross an HTTP gateway. Tool-side authorization belongs at the tool. Memory write policy and purge behavior belong to the memory service. Model evaluation and red-team results have their own owners.

Use the Exchange to keep those owners visible. A system can pass every gateway test and still fail because a vector store ignores tenant permissions. It can also fail because a tool accepts a broad service credential or because generated code runs without isolation. Framework coverage and product coverage are different maps.

A practical first review

A small team can begin with one architecture workshop and one test session. Inventory the components and trust boundaries. Select five to ten threats that fit the use case, then assign controls and evidence before expanding the scope. Resolve ownership gaps first, because an unowned control will not improve when the spreadsheet grows.

End the review by recording control status and residual-risk decisions. Mark controls that passed and are ready for operation. Put failed controls into remediation with an owner. An accountable person must explicitly accept any residual risk. Schedule the next review around a change trigger and a maximum interval. This creates a working security process instead of a one-time framework exercise.

DeepInspect

DeepInspect can serve as the enforcement and evidence point for authenticated HTTP model traffic deliberately routed through it. It can evaluate identity-bound policy and prompt classification before forwarding a request. It can also restrict approved destinations and retain a per-decision record with the route, policy version, outcome, and event time.

DeepInspect does not implement the complete OWASP AI Exchange. It does not control training pipelines, vector-store permissions, local or STDIO execution, tool-side authorization, or organization-wide governance. Assign those Exchange controls to components with authority over them, and give DeepInspect only the HTTP request-path tests it can actually execute. Book a technical deep dive at deepinspect.ai.