Updated August 21, 2026
TL;DR: Delegating AI policy enforcement to a model provider or external gateway creates a compliance blind spot because audit logs and telemetry transit outside your trust boundary. True AI governance requires active runtime enforcement operated within your own infrastructure, where policy decisions happen before the model call completes. Prediction Guard enforces AIUC-1, ISO/IEC 42001, and EU AI Act policies at the system level, generates audit logs within your environment for Security Information and Event Management (SIEM) ingestion, and produces an exportable AI Bill of Materials (AIBOM) in CycloneDX format, evidence your organization owns, not evidence you request from a vendor.
When a regulatory examiner asks for the complete, unbroken audit log for your production AI agents, your team should not need to open a vendor dashboard, file a data-access request, or explain that the provider handles that part. Pointing outside your perimeter during an examination is the fastest way to surface a finding. Yet most enterprise AI governance programs are built on exactly that assumption: that model providers bear meaningful responsibility for securing the interactions they facilitate. AI governance ownership does not transfer to a provider when you send a request to their API. It stays with the deployer, and so does the audit liability.
Architecture dictates audit success, and the organizations that understand this before a regulatory review are the ones whose compliance teams walk out of examination cycles without remediation orders.
Compliance requirements have grown more complex over the last three years, and AI governance has landed on top of that complexity curve. Most compliance programs were not resourced to absorb it.
A sovereign AI control plane is the enforcement infrastructure that answers this problem structurally. It sits inside your own environment, intercepts every AI interaction before the model call completes, and applies your organization's policies on every request. It is not a monitoring tool. It decides, in real time, whether a given input or output is allowed, blocked, or rewritten, then generates a structured audit record of that decision before the response returns. That distinction, enforcement versus monitoring, is the structural divide separating defensible governance from optimism dressed as compliance.
The compliance value of a log is entirely conditional on what generated it. A log produced by runtime enforcement is evidence that a governance decision happened at the moment of the request. A log produced by retrospective monitoring is evidence that a violation occurred and was detected later, meaning the policy was breached, the output reached a downstream system, and the finding already existed before anyone knew to look.
For high-risk AI deployments in financial services, defense-adjacent manufacturing, or aerospace, retroactive remediation is not a viable control. The Open Worldwide Application Security Project (OWASP) agentic security standard identifies ASI01 (Agent Goal Hijack) as one of the primary agentic risks precisely because hijacked agent objectives propagate through downstream systems before any log-based alert surfaces. Runtime enforcement blocks the violation before it propagates. The audit log is then evidence that the block happened, not that a breach occurred.
In a self-hosted deployment, the control plane runs within your own Virtual Private Cloud (VPC), air-gapped environment, or on-premises infrastructure. The control plane evaluates every model interaction, policy decision, and enforcement action locally. Nothing transits a vendor's network for governance purposes.
This matters because the EU AI Act, a directly applicable EU regulation, places log retention obligations on deployers of high-risk AI systems under Article 26(6), which requires keeping automatically generated logs to the extent they remain under the deployer's control. "Remain under their control" is not satisfied by a vendor-managed dashboard you access via a web portal. It requires that the log-generating infrastructure and the logs themselves stay inside the organization's custody. A self-hosted control plane satisfies this requirement structurally. An external gateway or provider-managed guardrail does not.
For a practical walkthrough of how this architecture works in high-trust regulated environments, watch the EP12 self-hosted sovereignty video and read the Scaling Agentic AI blog post. Both cover the governance trade-offs at enterprise scale.
Prediction Guard formats audit log output natively for Splunk, Datadog, and Grafana ingestion without holding or managing your SIEM credentials. The four-step flow on the Monitor page of the Admin Console activates the integration:
The compliance blind spot that surfaces most often in regulated industries is not the primary model call. It is everything around it: the tool invocations, the Model Context Protocol (MCP) server interactions, the database retrievals, and the multi-agent handoffs whose governance telemetry routes to vendor-controlled infrastructure outside your trust boundary, rather than generating audit evidence inside your own environment. By the time a compliance team becomes aware that a new AI-integrated workflow has been deployed, it has often already processed regulated data through components that no governance review has touched.
MCP servers introduce a new category of agentic AI exposure. An MCP server is a third-party component that an agent integrates with at runtime to access tools, data sources, and external APIs. The compliance risk is not the tool itself, it is that agents discover and integrate MCP components dynamically, meaning the supply chain is live and constantly shifting.
A tampered MCP server does not need to break the API contract. It can stay within authorized privileges while silently redirecting what the agent does with the data it retrieves. Provider guardrails evaluate content passing through their own model endpoint, and any telemetry they generate routes to vendor-controlled infrastructure outside the customer's perimeter. In a multi-provider deployment, each provider's guardrail applies only to its own endpoint, leaving no shared policy plane across the full agent workflow and no audit log the deployer owns. Effective governance of MCP server interactions requires system-level enforcement applied across every component registered in the AI system.
Any telemetry a provider-managed filter generates routes to vendor-controlled infrastructure outside your perimeter by design. The governance record for your AI interactions is held in a vendor dashboard under the provider's retention policy, not inside your own environment under your custody.
Amazon Bedrock Guardrails covers content filtering and PII redaction for traffic that lands on Bedrock. Azure AI Content Safety adds prompt injection detection for Azure-mediated requests. Both are point-solution filters tied to their respective cloud providers.
An enterprise running models from multiple providers, which describes most regulated-industry AI deployments of any complexity, needs a single policy plane covering all of them uniformly. Provider guardrails cannot provide that. Each adds its own logging standard, its own dashboard, and its own retention policy, creating exactly the audit fragmentation that examiners exploit when they ask for a complete interaction trace.
Governance, Risk, and Compliance (GRC) teams in regulated enterprises need to prove that developers building AI applications cannot override the policies governing them. Separation of duties is the control that satisfies that requirement, and it requires architecture, not documentation.
In a self-hosted control plane, GRC teams configure governance policies on the Govern page of the Admin Console. Developers connect existing OpenAI-compatible or Anthropic-compatible SDK calls by changing only the base_url. They do not touch policy configuration and cannot bypass governance rules inside their application code because the control plane sits outside their codebase entirely.
Audit evidence is only as strong as the chain of custody behind it. Evidence generated inside your infrastructure and never transmitted to a vendor is evidence you produce without a discovery request or a vendor data-access form. Evidence generated in a vendor's infrastructure is evidence you request.
The tables below map Prediction Guard's runtime controls to specific requirements across three instruments compliance teams in regulated industries currently manage: AIUC-1 (a voluntary AI governance standard), the EU AI Act (a directly applicable EU regulation), and ISO/IEC 42001 (an AI management system certification standard).
Runtime controls aligned to AIUC-1 and EU AI Act
| Runtime control | AIUC-1 pillar | EU AI Act alignment |
|---|---|---|
| Prompt injection defense | Security | Article 15 (Accuracy, Robustness and Cybersecurity), Article 9 (Risk management) |
| PII detection and masking | Data and Privacy | Article 10 (Data governance) |
| Toxicity filtering | Safety | Article 9 (Risk management) |
| Factual consistency checking | Reliability, Accountability | EU AI Act alignment (article mapping subject to deployer risk classification) |
| SIEM-ready audit log generation | Accountability | Article 12 (Record-keeping), Article 26(6) |
Runtime controls for comprehensive audit logging
| Runtime control | Audit log record type |
|---|---|
| Prompt injection defense | AI system input recording |
| PII detection and masking | Sensitive data field interaction recording |
| Toxicity filtering | Content safety enforcement outcome recording |
| Factual consistency checking | Reliability check outcome recording |
| SIEM-ready audit log generation | Replayable trace bound to sessions and data sources |
ISO/IEC 42001 Annex A Control A.6.2.8 requires that event logs record prompts, tool invocations, outputs, and affected resources as a replayable trace bound to users, sessions, and data sources. A self-hosted control plane that enforces policy on every call and records governance events and enforcement decisions on every interaction supports A.6.2.8 alignment by keeping that evidence inside the deployer's own infrastructure, rather than aggregating model-side telemetry in a vendor dashboard. AIUC-1's crosswalk at aiuc-1.com/crosswalks confirms alignment across EU AI Act, NIST AI RMF, ISO/IEC 42001, MITRE ATLAS, and the OWASP Top 10 for LLM Applications, giving compliance teams a cross-framework view from a single conformity point.
Model providers update underlying weights, safety policies, and alignment tuning without changing API endpoints or issuing formal change notifications. From the deployer's perspective, the API contract remains identical. From the governance perspective, the model's behavior has changed, and the deployer has no visibility into what changed or how it affects their specific use cases.
This is control drift: the gap between the policy documented in your governance framework and the policy actually enforced at the model layer, which shifts silently with every provider update. Runtime enforcement applied at the control plane keeps governance consistent regardless of that drift, because enforcement happens at the system level, not inside the model, regardless of what the underlying model does or does not filter. You own the policy. It does not depend on the provider's alignment choices, and it does not change when the provider updates the model.
Vendor-provided logs are generated inside vendor infrastructure and transit vendor networks before they reach any customer-controlled system. The custody chain begins outside your perimeter. For a regulated deployer, that means the evidence record existed under a vendor's control before it existed under yours.
For a forensic audit tied to a regulated data exposure incident, that gap often triggers a finding because the examiner cannot reconstruct the full interaction chain from model-side logs alone. A Federal Financial Institutions Examination Council (FFIEC) examiner or CMMC third-party assessment organization (C3PAO) will ask for a complete, sequential trace of every component interaction, from the initial user input through every tool call, retrieval operation, and policy enforcement decision. That trace can only exist if the governance infrastructure generates audit evidence inside the deployer's own environment, under unbroken custody, rather than aggregating telemetry from separate vendor dashboards each operating under its own logging standard and retention schedule.
The architecture comparison below maps key differences across the vectors that matter for a Chief Compliance Officer's (CCO) vendor due diligence review.
| Vector | Internal control plane (Prediction Guard) | External gateway (Noma) | Provider-managed controls |
|---|---|---|---|
| Data routing | All traffic stays inside customer VPC or air-gapped environment | Requires outbound HTTPS to api.noma.security:443 for telemetry | Traffic processed within the provider's own infrastructure. Routing is determined by the provider's architecture |
| Telemetry storage | Customer's SIEM, under customer custody | Noma's platform, outside customer perimeter | Provider's platform, outside customer perimeter |
| Multi-model support | Model agnostic, single policy plane across all vendors | Broad, with Copilot Studio and Salesforce AgentForce integrations | Scoped to provider's own models and services |
| MCP server governance | Registered as AI System components, governed at system level | Not independently verified from public documentation. Confirm scope directly with vendor | Not independently verified from public documentation. Confirm scope directly with provider |
Noma Security offers a comprehensive platform with genuine strengths, including Copilot Studio integrations and broad discovery capabilities for Microsoft-centric enterprises. For organizations where Cybersecurity Maturity Model Certification (CMMC) or International Traffic in Arms Regulations (ITAR) obligations prohibit data transiting external infrastructure for any purpose, including governance, the outbound port 443 requirement of Noma's Kong Gateway plugin creates a structural incompatibility. Prediction Guard enforces all policies locally, with no outbound dependency for governance function.
Prediction Guard generates structured, SIEM-ready audit log output inside your environment. Your SIEM stores and retains it. Prediction Guard holds no SIEM credentials and has no log retention capability. The log-generating infrastructure runs inside your environment and the log-storage infrastructure is yours, so the chain of custody is unbroken and entirely within your control. This architecture supports ISO/IEC 42001 A.6.2.8 alignment, EU AI Act Article 26(6), and AIUC-1's Accountability pillar, as reflected in AIUC-1's published cross-framework crosswalk at aiuc-1.com/crosswalks.
Registering AI assets (models and MCP servers) into AI Systems within Prediction Guard produces an exportable AIBOM in CycloneDX format. The AIBOM answers the examiner or assessor's asset inventory question: which AI components are in production, what data sources do they connect to, and what policies apply to each. The runtime audit log answers the examiner or assessor's enforcement question: which policy decisions were made on which interactions, and when. Neither artifact can be produced without an internal control plane that has visibility across the full system. The Prediction Guard EP10 AI system composability video covers how the asset registration architecture works in practice.
A model-agnostic control plane lets you change the underlying model without rewriting governance configuration or losing audit history. When a provider's model is deprecated, you repoint to a new model endpoint. The policies in the Admin Console Govern page do not change. The audit log format does not change. The SIEM integration does not change. Your compliance posture does not reset. This is operationally significant for regulated organizations that need to demonstrate continuous governance, not governance that restarts every time a vendor makes a product decision.
Policy enforcement, prompt evaluation, and audit log generation all run inside infrastructure your organization controls. Nothing routes outside your perimeter.
The control plane is CPU-only. Policy enforcement, prompt injection defense, PII detection, and audit log generation all operate on CPU resources and deploy inside your existing container infrastructure without GPU overhead for the governance control plane itself. Models can run on GPU or CPU depending on workload requirements. Self-hosting the control plane does not require GPU resources and does not demand significant new infrastructure for the enforcement control plane.
Developers do not change their code. Existing OpenAI-compatible or Anthropic-compatible SDK calls continue to work unchanged. Only the base_url is repointed to the local control plane endpoint. The control plane enforces governance transparently on every call, with no developer-side configuration required and no ability for developers to bypass the policies your GRC team configured.
ISO/IEC 42001 A.6.2.8 requires that event logs record prompts, tool invocations, outputs, and affected resources as a replayable trace bound to users, sessions, and data sources. Audit log generation covers every model call and agent interaction passing through the control plane, recording governance events and enforcement decisions inside your own infrastructure.
Because AIUC-1 crosswalks to EU AI Act, NIST AI RMF, ISO/IEC 42001, and OWASP Top 10 simultaneously, one internal control plane, one audit log format, and one SIEM integration produce evidence that addresses multiple framework requirements without duplicating compliance infrastructure. The Practical AI episode 332, featuring Donato Capitella, illustrates why this kind of system-level visibility matters in practice: agents can be exploited through prompt injection, data exfiltration, and tool misuse, and Capitella's real-world penetration tests show how easily these failures slip past defenses that only watch the model layer rather than the full agent-tool interaction chain.
Three governance gaps consistently surface in pre-audit reviews across financial services, defense-adjacent manufacturing, and aerospace organizations moving AI from pilot to production:
A CCO preparing for a CMMC assessment by a C3PAO, an FFIEC examination, or an EU AI Act conformity review needs three categories of artifacts that only an internal control plane can produce:
For EU-exposed organizations, EU AI Act Article 26(6) requires deployers to retain automatically generated logs to the extent they remain under the deployer's control. For defense-adjacent manufacturers handling Controlled Unclassified Information (CUI) under CMMC and ITAR, data processing and policy enforcement must remain within authorized boundaries. External governance infrastructure that receives data transmissions for filtering purposes may violate those boundary requirements regardless of the vendor's contractual commitments.
These are structural requirements answered by architecture, and the architecture has to be decided before the assessment, not during it. Book a deployment scoping call to assess how a self-hosted AI control plane fits your infrastructure and compliance requirements, or review the AIUC-1 and NIST AI RMF capability mapping whitepaper to see which framework functions we address at the system level.
Provider-managed guardrails generate telemetry inside vendor-controlled infrastructure, outside the deployer's trust boundary, regardless of the specific vendor. In a deployment that spans multiple model providers, each provider produces its own logs in its own format under its own retention schedule, with no unified policy plane or shared audit record the deployer owns.
Control drift occurs when a model provider updates underlying model weights or safety policies without changing the API endpoint or issuing a formal notification. The result is a gap between the governance posture documented in your compliance program and the policy the model actually enforces, which shifts silently with every provider update.
OWASP ASI04 (Agentic Supply Chain Vulnerabilities) covers risks from third-party tools, MCP servers, plug-ins, registries, and update channels that agents integrate with at runtime. A tampered or malicious MCP server can introduce unsafe behavior while staying within authorized API contracts, which is why provider guardrails operating at the model boundary cannot address this risk class.
An internal control plane produces three categories of audit evidence: a real-time AI asset inventory with an exportable AIBOM in CycloneDX format, runtime enforcement logs showing every policy decision for every interaction generated inside the organization's infrastructure, and SIEM-ready formatted output forwarded to your SIEM under your retention controls.
Prediction Guard configures audit log output formatting to match the field structure of the target SIEM (Splunk, Datadog, Grafana, or syslog) without holding SIEM API keys, HEC tokens, or endpoint credentials. Your existing log ingestion pipeline handles delivery, so the control plane generates and formats the log while your SIEM stores it.
Sovereign AI control plane: Infrastructure deployed inside the customer's own environment to enforce governance policies on every AI system interaction in real time, generating audit logs that remain within the customer's custody.
Active runtime enforcement: Policy enforcement applied to each AI interaction before the model call completes, resulting in the interaction being allowed, blocked, or rewritten rather than flagged retrospectively.
Control drift: The gap between governance policies documented in a compliance program and the policies actually enforced at the model or system level, which shifts when providers update model behavior without API changes.
AIBOM (AI Bill of Materials): An exportable inventory of all AI system components, including registered models and MCP servers, formatted in CycloneDX and produced as a byproduct of AI System registration in the control plane.
ASI04 (Agentic Supply Chain Vulnerabilities): OWASP Top 10 for Agentic Applications 2026 category covering risks from malicious or compromised third-party tools, MCP servers, plug-ins, registries, and update channels integrated by agents at runtime.
ISO/IEC 42001 A.6.2.8: The Annex A control requiring AI system event logs to record prompts, tool invocations, outputs, and affected resources as a replayable trace bound to users, sessions, and data sources.
AIUC-1: A published AI governance standard organized around six pillars (Data and Privacy, Security, Safety, Reliability, Accountability, Society) with published crosswalks to EU AI Act, NIST AI RMF, ISO/IEC 42001, MITRE ATLAS, and OWASP Top 10 for LLM Applications.
Structural ambiguity: The compliance condition that arises when audit evidence is split between vendor-controlled and deployer-controlled infrastructure, making it impossible to produce a complete, custody-verified evidence chain during a regulatory examination.