OWASP LLM Top 10: Complete risk-to-control mapping for enterprise AI applications

Updated August 10, 2026

Summary: The OWASP Top 10 for LLM Applications defines ten vulnerability classes that threaten production AI systems, from prompt injection to unbounded resource consumption. Translating those risks into enforceable controls requires runtime enforcement at the API level, inside your own infrastructure, not a perimeter-based filter sitting outside your trust boundary. This guide maps all ten OWASP risks (LLM01-LLM10) to their corresponding AIUC-1 pillars and NIST AI RMF functions, with concrete developer and system-level controls for each, and explains why a self-hosted control plane is the architecture that keeps enforcement logic, audit logs, and telemetry inside your own perimeter.

A security policy written in a PDF is not a control. If your AI security strategy depends on developers remembering to sanitize inputs or manually reviewing outputs, a Defense Counterintelligence and Security Agency (DCSA) assessor or a Federal Financial Institutions Examination Council (FFIEC) examiner will find that gap before your next review cycle is complete. Most enterprise AI security failures originate from governance architectures that treat probabilistic AI applications with static, perimeter-based tooling that sits outside the customer's trust boundary, reviewing traffic after it has already left your environment.

Translating the abstract vulnerabilities in the OWASP Top 10 for LLM Applications into deterministic, system-level controls is the engineering work that separates deployable AI from auditable AI. This guide maps each risk to concrete architectural requirements and shows how a self-hosted control plane enforces those boundaries at runtime without adding developer friction or sending your telemetry outside your perimeter.

Translating OWASP risks into buildable controls

The NIST AI Risk Management Framework organizes AI risk across four core functions: Govern, Map, Measure, and Manage. OWASP LLM Top 10 risks map across all four, which means a complete governance program cannot address prompt injection in isolation from supply chain or resource controls. It has to cover all ten categories with system-level enforcement, not point solutions stitched together with documented guidelines.

The shift from advisory compliance to system-level enforcement is structural. A policy written in a wiki tells a developer what to do. A control plane enforced at the API level does it automatically, on every call, before the response returns, and generates a structured audit log as evidence.

Determining your AI security requirements

Three questions define your enforcement surface before you map controls:

1. What data classes does your AI application process? Personally identifiable information (PII), protected health information (PHI), controlled unclassified information (CUI), and financial non-public personal information each carry distinct regulatory obligations that the control plane must enforce at runtime.
2. Where does model inference happen? Self-hosted models inside your VPC, third-party API endpoints, or a hybrid of both: each introduces different trust boundaries that enforcement must span.
3. What is your agent topology? AI applications with tool use, Model Context Protocol (MCP) server integration, and multi-model orchestration face LLM-level risks alongside additional attack surfaces specific to autonomous decision-making, cross-context action, and tool integration, as defined by the OWASP Top 10 for Agentic Applications. Episode 271 of the Practical AI podcast features Congressman Don Beyer in conversation with Daniel Whitenack and Chris Benson on AI regulation and governance challenges facing America, providing broader policy context for the risk considerations beyond single-model deployments.

Note: model drift monitoring is a separate observability function requiring statistical analysis of output distributions over time. It operates at a different architectural layer than the API-level controls covered in this guide. Drift detection belongs at model evaluation and selection time, not at the API enforcement layer.

Framework mapping: OWASP LLM Top 10 and NIST AI RMF

The table below maps each OWASP risk to its corresponding NIST AI RMF function. AIUC-1 provides an additional crosswalk across its six pillars (Data and Privacy, Security, Safety, Reliability, Accountability, and Society), which enterprise procurement reviewers and AIUC-1 assessors can validate against this same OWASP risk taxonomy. ISO/IEC 42001 alignment is addressed on a per-risk basis in each LLM section below, with hedged notes where specific control area labels could not be confirmed from published primary source documentation.

Framework mapping matrix

Source: aiuc-1.com/crosswalks (author's analysis, per-risk pillar table not confirmed in published primary source documentation)

AIUC-1 pillar mappings in the table above are the author's own analysis derived from the AIUC-1 crosswalk framework at aiuc-1.com/crosswalks, which confirms OWASP Top 10 for LLM Applications as a framework AIUC-1 maps to. A per-risk (LLM01-LLM10) pillar breakdown table was not confirmed in published primary source documentation at the time of writing. Organizations should validate specific pillar applicability against the current AIUC-1 crosswalk directly. ISO/IEC 42001 alignment is addressed on a per-risk basis in each LLM section below. Specific ISO/IEC 42001 control area labels could not be confirmed from published primary source documentation and are not presented as a confirmed mapping table.

LLM01: Prompt injection

Prompt injection (LLM01) occurs when an attacker manipulates input to override the model's intended instructions, either directly through user prompts or indirectly through poisoned content in Retrieval-Augmented Generation (RAG) retrieved documents, emails, or database results. Indirect injection is particularly dangerous in agentic applications because the model cannot distinguish legitimate retrieved content from adversarially crafted instructions without a runtime enforcement layer inspecting the full input before it reaches the model.

Developer-level control: Input validation, heuristic filtering on user-supplied fields, and source document vetting for RAG pipelines.

System-level control: Prompt injection detection enforced at the control plane API level before the model call completes. Developers repoint their OpenAI-compatible or Anthropic-compatible base_url at the control plane, and the check runs transparently on every request without application code changes. For a practical walkthrough of OWASP guidance implementation, see Prediction Guard's OWASP implementation video.

Framework mapping: AIUC-1 pillars: Security. NIST AI RMF: Map (risk identification), Measure (defense evaluation), Manage (treatment). Source: aiuc-1.com/crosswalks (author's analysis, per-risk pillar table not confirmed in published primary source documentation).

ISO/IEC 42001 alignment: Annex A controls on AI system operation, monitoring, and information security are relevant to prompt injection risk. Organizations implementing ISO/IEC 42001 should validate specific control area applicability against their own conformity scope, as explicit mapping to named control areas is not confirmed in published primary source documentation.

LLM02: Sensitive information disclosure

Sensitive information disclosure (LLM02) occurs when AI applications leak PII, PHI, or proprietary data through model responses, training artifacts, or verbose error messages. In regulated environments, a model that outputs a patient name, account number, or trade secret in a response that reaches an unauthorized system triggers reportable incident obligations regardless of developer intent.

Developer-level control: Data anonymization and tokenization in the preprocessing layer before data reaches the model.

System-level control: Automated PII detection, masking, filtering, or blocking at the control plane before data leaves the trust boundary. The enforcement decision is configured once in the Admin Console by the security or GRC team and applies uniformly across every model call, without coding into each individual application.

Framework mapping: AIUC-1 pillars: Data and Privacy, Security. NIST AI RMF: Govern, Map, Measure. Regulatory instruments: HIPAA (OCR), GDPR Article 25 (data protection by design), GLBA Safeguards Rule, ISO/IEC 42001 data governance controls. Source: aiuc-1.com/crosswalks (author's analysis, per-risk pillar table not confirmed in published primary source documentation).

LLM03: Supply chain vulnerabilities

Supply chain vulnerabilities (LLM03) arise because AI applications depend on a stack of third-party components: base models, fine-tuned adapters, open-source orchestration libraries, vector databases, plugins, and external APIs. A weakness or compromise anywhere in that stack can affect the security of the entire application. Attackers target model providers, dependency packages, and plugins, not just the application layer.

Developer-level control: Dependency pinning, vendor vetting checklists, and signed model artifact verification.

System-level control: AI System registration in the control plane. Registering every model, tool, MCP server, and dataset dependency as a named asset produces an AI Bill of Materials (AIBOM) in CycloneDX format (published as ECMA-424). This machine-readable inventory gives an enterprise procurement reviewer or AIUC-1 assessor the supply chain documentation required to evaluate risk across all registered assets.

Framework mapping: AIUC-1 pillars: Data and Privacy, Accountability. NIST AI RMF: Govern (accountability, supplier oversight), Map (system context, risk identification), Measure (risk analysis), Manage (treatment, mitigation). Source: aiuc-1.com/crosswalks (author's analysis, per-risk pillar table not confirmed in published primary source documentation).

LLM04: Data and model poisoning

Data and model poisoning (LLM04) targets the integrity of training data, fine-tuning sets, and vector databases that feed RAG pipelines. Attackers inject malicious content into vector stores that gets retrieved during legitimate queries, or manipulate fine-tuning datasets to introduce backdoor behaviors that activate under specific input conditions.

Developer-level control: Data lineage tracking, dataset versioning, and access controls on vector store write paths.

System-level control: Runtime validation of retrieved context in RAG pipelines and access controls configured in the Admin Console that define which agents and users can read from which knowledge bases. These controls run before retrieved documents reach the model, not after generation.

Framework mapping: AIUC-1 pillars: Security. NIST AI RMF: Measure (risk analysis, impact assessment). Source: aiuc-1.com/crosswalks (author's analysis, per-risk pillar table not confirmed in published primary source documentation).

ISO/IEC 42001 mapping: Integrity controls, training data governance.

LLM05: Improper output handling

Improper output handling (LLM05) refers to inadequate validation of model outputs before they are passed downstream. Unvalidated AI outputs can introduce XSS payloads into web frontends, SQL fragments into query builders, or malformed data into downstream APIs depending on how the application consumes model responses.

Developer-level control: Output schema validation using typed parsers and structured JSON enforcement at the application layer.

System-level control: Toxicity and content policy enforcement run at this output layer, catching content-level violations before they reach downstream systems.

Framework mapping: AIUC-1 pillars: Data and Privacy, Security, Safety, Reliability, Accountability. NIST AI RMF: Manage (response, recovery). Source: aiuc-1.com/crosswalks (author's analysis, per-risk pillar table not confirmed in published primary source documentation).

ISO/IEC 42001 alignment: ISO/IEC 42001 addresses intended use verification, human oversight mechanisms, and output governance within its broader control scope, each of which is relevant to improper output handling risk. Organizations implementing ISO/IEC 42001 should validate specific control area applicability against their own conformity scope, as the terminology "output controls" and "system integrity" as discrete control area labels is not confirmed in published primary source documentation.

LLM06: Excessive agency

Excessive agency (LLM06) occurs when an agent is granted tool permissions or system access that exceed what the task requires. An agent with write access to a CRM, a code repository, and an email system simultaneously is a high-blast-radius vulnerability waiting for an injection attack. The OWASP Top 10 for Agentic Applications documents how blast radius scales with tool access in multi-agent coordination scenarios.

Developer-level control: Least-privilege tool binding, scoping each agent's tool set to the minimum required for its defined task.

System-level control: Governance boundaries for agents and their registered tools are configured in the Admin Console. Agents operate within the boundaries defined on the Govern page, not independently.

Framework mapping: AIUC-1 pillars: Data and Privacy, Security, Reliability, Accountability. NIST AI RMF: Govern (accountability, oversight). Source: aiuc-1.com/crosswalks (author's analysis, per-risk pillar table not confirmed in published primary source documentation).

LLM07: System prompt leakage

System prompt leakage (LLM07) occurs when attackers coax models into exposing system prompts that contain business logic, API credentials, access control instructions, or proprietary process definitions. Leaked system prompts provide a detailed map of application security assumptions and enable targeted follow-on attacks.

Developer-level control: Avoiding inline secrets in system prompts, using references rather than credentials directly in prompt text.

System-level control: Response sanitization at the control plane. Before the model's response is returned, it is evaluated against configured content policies. Responses that reproduce system prompt content in unauthorized contexts can be blocked or rewritten at the API layer without custom developer logic.

Framework mapping: AIUC-1 pillars: Security. NIST AI RMF: Manage (treatment, containment). Source: aiuc-1.com/crosswalks (author's analysis, per-risk pillar table not confirmed in published primary source documentation).

ISO/IEC 42001 alignment: ISO/IEC 42001 addresses broader governance, information security, and data protection obligations relevant to system prompt protection, but the specific control area label "Confidentiality controls" as a discrete ISO/IEC 42001 mapping for system prompt leakage is not confirmed in published primary source documentation. Organizations implementing ISO/IEC 42001 should validate applicable control areas against their own conformity scope and the standard's information security provisions directly.

LLM08: Vector and embedding weaknesses

Vector and embedding weaknesses (LLM08) cover risks in RAG retrieval layers: poisoned or manipulated embeddings that skew retrieval accuracy, adversarially chosen context injected into generation, and tenant boundary failures in multi-tenant vector stores.

Developer-level control: Source document vetting, embedding provenance tracking, and tenant isolation in vector store configuration.

System-level control: Factual consistency checking at the output layer evaluates generated responses against reference documents to flag cases where output is inconsistent with retrieved context. This is a risk-reduction control, not a deterministic accuracy guarantee, and should be scoped accordingly in governance documentation.

Framework mapping: AIUC-1 pillars: Data and Privacy, Security, Reliability. NIST AI RMF: Measure (risk analysis). Note that explicit mapping of LLM08 to the NIST AI RMF Measure function is not confirmed in available primary source documentation. Most available sources address LLM08 primarily through ISO/IEC 27001 controls on access control, data classification, and availability rather than through a named NIST AI RMF function. Organizations should validate the applicable NIST AI RMF function mapping against their own governance scope. Source: aiuc-1.com/crosswalks (author's analysis, per-risk pillar table not confirmed in published primary source documentation).

ISO/IEC 42001 alignment: ISO/IEC 42001 Annex A controls on data for AI systems and information security are relevant to vector and embedding weaknesses. Note that ISO/IEC 27001 (a separate standard) addresses this risk area via access control, data classification, and availability controls. Organizations implementing either standard should validate specific control area applicability against their own conformity scope, as explicit per-risk mapping to named control area labels is not confirmed in published primary source documentation for ISO/IEC 42001.

LLM09: Misinformation

Misinformation (LLM09) refers to generation and propagation of false, misleading, or harmful content. In regulated industries, model-generated misinformation carries direct legal and operational risk: a hallucinated dosage in a clinical decision support tool or fabricated case law in a legal workflow creates liability that manual review processes cannot catch at production scale.

Developer-level control: Training data quality assurance and output review workflows for high-stakes decisions.

System-level control: Factual consistency checking at the control plane verifies generated content against trusted reference data before the response is returned (see LLM08 for the technical mechanism). Because this check is probabilistic rather than deterministic, its correct framing for audit purposes is as a risk-reduction control with documented confidence thresholds.

Framework mapping: AIUC-1 pillars: Security, Safety, Reliability. NIST AI RMF: Measure (risk analysis, evaluation). Source: aiuc-1.com/crosswalks (author's analysis, per-risk pillar table not confirmed in published primary source documentation).

ISO/IEC 42001 alignment: ISO/IEC 42001 Annex A controls on AI system operation, monitoring, and information security are relevant to misinformation risk, and ISO/IEC 42001 addresses misinformation prevention and hallucination detection within its broader governance scope. Organizations implementing ISO/IEC 42001 should validate specific control area applicability against their own conformity scope, as the terminology "factual validation" and "output verification" as discrete named control area labels is not confirmed in published primary source documentation.

LLM10: Unbounded consumption

Unbounded consumption (LLM10) covers excessive or uncontrolled resource usage leading to denial of service, financial exploitation, or unauthorized model replication. Runaway agent loops, oversized context windows from adversarial inputs, and high-concurrency API scraping are all attack vectors under this category. For financial services organizations with per-model cost governance requirements, uncontrolled consumption is a budget risk as well as a security risk.

Developer-level control: Budget allocation per agent, timeouts on long-running calls, and queue management for high-concurrency workloads at the application layer. These are application-level design choices independent of how the control plane enforces rate limits at runtime.

System-level control: Resource consumption boundaries for agents and registered endpoints are configured in the Admin Console. The Prediction Guard blog on scaling agentic AI covers cost governance and compliance trade-offs at enterprise scale.

Framework mapping: AIUC-1 pillars: Data and Privacy, Security, Reliability, Accountability. NIST AI RMF: Govern (resource accountability). Source: aiuc-1.com/crosswalks (author's analysis, per-risk pillar table not confirmed in published primary source documentation).

ISO/IEC 42001 alignment: ISO/IEC 42001 Annex A controls on AI system operation, monitoring, and incident management are relevant to unbounded consumption risk. Organizations implementing ISO/IEC 42001 should validate specific control area applicability against their own conformity scope, as the terminology "resource controls" and "availability" as discrete named control area labels for LLM10 is not confirmed in published primary source documentation. The broader Annex A scope covering system operation and incident management is the verified reference.

Defining essential controls for AI infrastructure

Three system-level capabilities form the foundation of an auditable OWASP-aligned control plane: structured audit logging, centralized policy mapping, and enforced model registration.

With all ten OWASP risks mapped, the implementation question becomes: how do you deploy these controls in a way that is auditable, maintainable, and does not require developers to change their application code?

Standardizing AI system audit logs

Every control decision at the runtime layer needs to produce a structured audit record that your Security Information and Event Management (SIEM) system can ingest. Prediction Guard generates audit logs natively within your environment and formats them to match the ingestion schema of Splunk, Datadog, and other targets via the Monitor page in the Admin Console. Prediction Guard does not hold SIEM API keys, HEC tokens, or any credentials. The system formats the output and your existing ingestion pipeline handles delivery under your own controls. The audit log is the evidence that enforcement happened, not the enforcement mechanism itself. Watch the Prediction Guard overview video for a demonstration of the separation between enforcement and evidence.

Mapping policies to OWASP risks

Prediction Guard separates duties at the architecture level: security and GRC teams configure governance policies once on the Govern page of the Admin Console, and those policies apply uniformly across every model, agent, and API call developers route through the control plane. Developers use their existing OpenAI-compatible or Anthropic-compatible SDK, changing only the base_url to point at the control plane endpoint. Governance policy does not live in application code, and developers do not manage it. The Prediction Guard AI engineers page covers the developer-facing architecture in detail.

Codifying model registration workflows

Ungoverned agent interactions are the primary source of AI audit gaps. When teams deploy models and AI-integrated tools faster than governance processes can capture them, the AI System inventory becomes incomplete, the AIBOM is incomplete, and supply chain risk is unquantified. Prediction Guard requires every model, tool, and MCP server to be registered as an asset within an AI System before it can be governed. The registration step forces enumeration. The AIBOM, exported in CycloneDX format, is the auditable output: a machine-readable inventory your enterprise procurement reviewer can evaluate and your security team can reference in any conformity assessment.

Translating risk frameworks into system design

Two decisions shape the implementation path from OWASP risk mapping to running production controls: whether to build or buy governance infrastructure, and which vendor architecture preserves data sovereignty.

Hidden costs of custom AI governance

The build-vs-buy calculation for AI governance infrastructure is frequently underestimated because initial development cost is visible and ongoing maintenance cost is not. Building a custom AI governance proxy covering all ten OWASP risks, integrating natively with enterprise SIEMs, and maintaining OpenAI and Anthropic API compatibility across quarterly provider updates is a sustained engineering investment with compounding maintenance overhead.

Build vs. buy decision matrix

Open-source frameworks like Guardrails AI can reduce initial development cost for single-model pilots. The Prediction Guard product comparisons page covers these capability differences in detail. For a broader discussion of AI tooling fragmentation and unification strategies, watch the Prediction Guard harmonizing AI tools video which addresses the architectural trade-offs.

Mapping OWASP controls to vendors

The critical architectural differentiator between a self-hosted control plane and an external security service is where enforcement and telemetry actually route. Noma Security's Kong Gateway plugin documentation instructs Kong Gateway nodes to allow outbound HTTPS to api.noma.security and describes streaming AI traffic to the Noma Security Console for audit trails and behavioral analysis, meaning enforcement telemetry routes outside your infrastructure perimeter. For organizations where regulated data cannot leave the internal network under International Traffic in Arms Regulations (ITAR), Cybersecurity Maturity Model Certification (CMMC), or financial services data sovereignty requirements, that outbound dependency is a structural blocker regardless of the vendor's capabilities.

AWS Bedrock Guardrails and Azure AI Content Safety are point-solution filters, not comparable governance platforms. AWS Bedrock Guardrails supports the ApplyGuardrail API to evaluate inputs and outputs for models outside Bedrock, including self-hosted models and third-party endpoints, but extending coverage this way still produces a set of provider-specific filters that must each be configured, maintained, and audited separately. For enterprises running multi-model AI applications across several providers simultaneously, stitching together insufficient point solutions is not a substitute for a single, portable policy framework that governs all endpoints under one control plane.

Prediction Guard deploys the entire control plane inside your own infrastructure. Governance logic runs inside your environment, audit logs are generated inside your environment, and no data transits Prediction Guard's systems. Watch the self-hosted sovereignty video and the air-gapped AI for manufacturing video for a demonstration of what this architecture looks like in practice for defense-adjacent and manufacturing environments.

Deployment architecture and AIBOM checklist

The Prediction Guard control plane is CPU-only. It does not require GPU resources to enforce governance policies. Registered models run on GPUs or CPUs depending on workload requirements, but the governance, policy enforcement, and audit log generation layer runs on standard CPU infrastructure. This makes the control plane deployable in on-premises hardware, private cloud VPCs, and fully air-gapped environments without GPU dependencies, supporting deployment patterns where no data leaves the organization's infrastructure perimeter, relevant for environments operating under strict data residency or air-gap requirements.

For generating an audit-ready AIBOM in ISO/IEC 42001-aligned deployments, the implementation sequence is:

1. Register all AI assets (including models, MCP servers, and datasets, along with any tools and external dependencies in scope) into an AI System via the Admin Console.
2. Classify each asset by data class sensitivity and regulatory scope.
3. Define dependency relationships between models, tools, and the datasets they access.
4. Confirm the AIBOM output in CycloneDX format reflects the current state of the registered AI System, noting that the AIBOM is a living document that updates continuously as models, tools, and datasets within the AI System change.
5. Ingest the AIBOM into your existing vulnerability management and supply chain risk tooling.
6. Update the AIBOM at each model or tool update cycle and retain version history as an evidence record suitable for conformity review purposes.

The AIBOM functions as a living document that updates with changes to the AI System, so your enterprise procurement reviewer always has a current inventory and your security team has a version history for any conformity review. The Prediction Guard NIST AI RMF implementation playbook provides the detailed capability-to-function mapping tables that a DCSA assessor or enterprise procurement reviewer can validate line by line.

Noblis CEO Mile Corrigan describes the governance need that this architecture addresses directly:

"This alignment offers significant opportunities for strategic collaboration on secure deployment of AI systems, including through Noblis' Artificial Intelligence Assurance Implementation (AI2) solution for AI safety, and further strengthens our ability to help customers navigate AI adoption while safeguarding sensitive data." - Verified customer, Noblis investment announcement

Book a deployment scoping call to assess how a self-hosted control plane fits your infrastructure and compliance requirements. Download the NIST AI RMF and OWASP capability mapping whitepaper for the complete control-to-framework tables your CISO and GRC teams need for architectural sign-off.

FAQs

Does Prediction Guard store our SIEM credentials or API keys?

No. Prediction Guard does not hold, store, or manage SIEM credentials, HEC tokens, or API keys of any kind. It configures audit log output formatting to match your chosen SIEM's native ingestion schema, and your existing ingestion pipeline handles delivery entirely under your own controls.

What deployment environments does the Prediction Guard control plane support?

Prediction Guard is fully self-hosted and runs inside your own infrastructure. It supports on-premises hardware, private cloud VPCs, and fully air-gapped environments.

Does the control plane require GPU hardware to run?

No. The Prediction Guard control plane is CPU-only and does not require GPU resources to enforce policies. Registered AI models can run on GPUs or CPUs depending on your workload, but the governance and enforcement layer runs on standard CPU infrastructure.

What is the difference between the OWASP LLM Top 10 and the OWASP Top 10 for Agentic Applications?

The OWASP LLM Top 10 covers risks across AI application deployments, including prompt injection, sensitive data disclosure, and improper output handling. The OWASP Top 10 for Agentic Applications extends to additional attack surfaces introduced by autonomous agent planning, tool use, multi-agent coordination, and persistent memory. Agentic AI systems face both sets of risks simultaneously.

How does a self-hosted control plane address supply chain risk (LLM03)?

Registering every model, tool, MCP server, and dataset dependency into an AI System forces enumeration of the full AI supply chain and produces an exportable AIBOM in CycloneDX format. This gives your security team a machine-readable inventory to scan for known vulnerabilities and gives your enterprise procurement reviewer the supply chain documentation required for conformity assessments.

What does "factual consistency" mean in the context of OWASP misinformation risk?

Factual consistency refers to runtime checks that evaluate whether a model's generated output aligns with trusted reference documents. It flags likely hallucinations before they reach downstream systems. It is a risk-reduction control, not a deterministic accuracy guarantee, and should be scoped accordingly in governance documentation.

Key terms glossary

Sovereign AI control plane: A self-hosted software system deployed within an organization's perimeter to secure, govern, and orchestrate disparate AI models, tools, and services without routing data or telemetry to external vendor infrastructure.

Runtime policy enforcement: The real-time evaluation, blocking, allowing, or rewriting of AI inputs and outputs at the API level before a model call completes, with an audit log generated as evidence of each enforcement decision.

AI Bill of Materials (AIBOM): A machine-readable inventory of all models, datasets, tools, and dependencies used within an AI application, exported in CycloneDX format for supply chain risk assessment and regulatory reporting.

Factual consistency: A probabilistic runtime check that verifies generated model outputs against trusted reference data to detect and flag hallucinations before they reach downstream systems or end users.

OWASP LLM Top 10: A voluntary community guidance document published by the OWASP GenAI project identifying the ten most critical security risks for AI applications built on large language models.

AI System registration: The process of enrolling all AI assets (models, tools, MCP servers, datasets, and external API endpoints) into a central control plane inventory before they can be governed, producing the AIBOM as an exportable audit artifact.