Updated August 10, 2026
TL;DR: Agent sprawl creates visibility gaps that perimeter firewalls and external gateways cannot intercept. Autonomous agents invoke databases and external APIs without system-level oversight, exposing regulated enterprises to data leakage and privilege escalation. This article gives you the technical and regulatory arguments to justify a runtime control plane to CISO and Legal stakeholders. This guide maps ungoverned tool call risks to the NIST AI Risk Management Framework and AIUC-1 requirements, and shows how self-hosted runtime enforcement closes the gap without requiring developers to change application code.
Writing AI governance policies in a corporate wiki is not a control. This applies whether your agents call self-hosted models exclusively or also reach out to third-party model endpoints: the control plane governs both the same way. It is a liability waiting to surface in your next CISO review, when an autonomous agent executed a tool call against your production database at 2 AM and no structured record exists of what it accessed, under which policy, or whether any governance check ran at all.
The problem is not simply that AI is spreading across the organization. It is that autonomous agents operate differently from every other piece of software your security team has ever governed. They translate natural-language inputs into dynamically generated tool calls, accumulate credentials as they integrate with more systems, and make decisions mid-session that no static access control policy can anticipate. Understanding exactly why this breaks conventional governance, and what actually fixes it, is what this article covers.
Understanding the governance gap starts with the mechanics of how agents generate and execute tool calls, and why that architecture breaks every control your security team currently relies on.
Traditional software executes fixed, hardcoded pathways. When a developer writes an API call, the destination endpoint, the parameters, and the authorization scope are all defined at build time and reviewable in version control. An autonomous agent works differently. It receives a user prompt, reasons about what actions to take, selects tools from its registered set, constructs parameters for those tools at runtime, and executes them, all without a human reviewing the intermediate steps.
Function calling protocols formalized this pattern as a de facto industry standard, with models generating structured JSON objects that invoke external systems. When an AI application moves from a single model call to a sequence of tool executions, every intermediate step becomes an attack surface your security team never explicitly reviewed or approved. Every tool an agent can call is an outbound action your security team never explicitly approved for that specific context, initiated by a non-human identity, at any time of day, against any data the agent has access to. Each new tool integration creates its own credential, its own permission scope, and its own outbound call path, and most enterprises have no centralized inventory of these surfaces.
Perimeter firewalls inspect network packets. They enforce rules at the transport layer, controlling which IP addresses and ports can communicate. They have no mechanism to evaluate the semantic content of a model-generated tool call, detect whether a prompt injection in a user message is redirecting an agent to exfiltrate data, or block a mid-session privilege escalation where an agent requests broader access than its original scope authorized. A firewall is excellent at controlling network traffic, but most agent-driven threats are not malformed packets. They are valid HTTPS calls carrying dynamically constructed payloads that traditional transport-layer inspection cannot evaluate.
A growing share of enterprise credentials now belong to non-human identities, and when attackers compromise a service account or steal an OAuth token, they gain persistent, MFA-free access that operates continuously without raising traditional security alarms.
Static API keys do not prevent mid-session privilege escalation either. Without a centralized control plane enforcing which tools and endpoints agents are permitted to call, nothing prevents an agent from exercising broader access than its original scope intended, because there is no single configuration point that defines and holds those boundaries uniformly. The OWASP Top 10 for Agentic Applications addresses these patterns explicitly, covering tool misuse (ASI02), identity and privilege abuse (ASI03), and the broader class of code execution risks that autonomous agents introduce when tool calls are constructed dynamically at runtime. Traditional identity and access management was built for human users following predictable workflows, not for agents that reason autonomously and construct new requests each session.
Two failure modes surface consistently in CISO reviews: missing AI asset inventories and absent runtime enforcement evidence. Both trace back to the same structural gap.
The AIUC-1 standard organizes AI governance requirements across six pillars: Data and Privacy, Security, Safety, Reliability, Accountability, and Society. Its crosswalk view maps each pillar to corresponding requirements in other frameworks your assessor may reference, including the NIST AI Risk Management Framework, so a single registration and enforcement posture can produce evidence relevant across multiple review contexts simultaneously.
From an AIUC-1 Accountability perspective, an AI agent audit requires more than a model inventory. It requires knowing which tool calls each agent can make, under which policies, against which data sources, and what structured evidence demonstrates that those policies were enforced at the moment of each call. The NIST AI RMF, as one of the frameworks AIUC-1 maps to, calls for documenting models, data sources, versions, access modes, known issues, and human oversight roles for every deployed AI system. Both requirements converge on the same structural gap: most enterprises enter CISO reviews without a centralized system that tracks model changes, versioning, and decision logs across their agent deployments, because engineering teams shipped agents faster than governance processes captured them.
The core problem is that agents make decisions. A CISO review does not just need to know which models are deployed. It needs to know which tool calls those models can make, under which policies, against which data sources, and what structured evidence exists to prove those policies were enforced at the moment of each call.
Every external model endpoint an agent calls is a supply chain dependency. If a third-party model updates without notice, if its output characteristics shift, or if it is compromised, the downstream effects propagate through every agent workflow that depends on it. The OWASP Top 10 for Agentic Applications identifies supply chain vulnerabilities as a first-order concern in multi-agent architectures, where an upstream compromise can cascade across an entire automated workflow before any human is aware. Unmonitored integrations do not just expose the enterprise to data leakage. They introduce dependencies that security teams cannot audit because the assets were never registered in the first place.
CISOs, AIUC-1 assessors, and CMMC third-party assessment organizations (C3PAOs) look for verifiable evidence that policies were enforced at runtime, not policy documents. A policy document describes intent. A structured audit log with a timestamp, a model identifier, a tool call record, and an enforcement decision is evidence of what actually happened.
Ungoverned agent interactions are not just unmonitored, they are actively executing tool calls that touch regulated data, without any structured record of what was called, what data was accessed, or what policy governed the decision. That absence is exactly what surfaces as a finding in a CMMC or AIUC-1 assessment.
The attack surface is not theoretical. Specific risk patterns recur across regulated enterprise deployments when autonomous agents operate without runtime policy enforcement at the tool call level.
Consider a concrete scenario. An agent built for internal knowledge retrieval receives a user query about contract terms. Lacking precise internal data, the agent calls an external API to supplement its response. Because no runtime policy inspects the outbound call, the request payload includes the original user query, which contains PII and proprietary negotiation details. The external endpoint receives that data before any network control can evaluate it. The exposure completes before any log entry captures it.
This is the core problem with external governance approaches. If every outbound model call passes through a vendor service for policy enforcement, sensitive data in that call transits infrastructure outside your perimeter before the governance decision is made. For manufacturing IP, controlled unclassified information (CUI), or regulated financial data, that transit is itself a compliance violation, regardless of whether the vendor enforces the right policy.
The fragmentation problem is operational as much as it is technical. Multiple engineering teams deploying separate agent implementations, whether using LangChain, CrewAI, or custom tool-calling frameworks, each configure their own model endpoints, their own tool registrations, and their own credential management. This creates overlapping, conflicting, and unauditable surfaces within a single organization.
When a CISO asks which agents have access to the customer database, the answer is not in a dashboard. It is scattered across individual repositories, environment variable files, and oral knowledge held by engineers who may have since moved teams. Practical AI Episode 358 covers how MCP infrastructure and Kubernetes-based orchestration handle identity management across agent fleets at scale, including the architectural decisions that determine whether identity boundaries hold when multiple agents are running simultaneously against shared tool configurations.
Manual asset tracking fails at the moment an agent is updated. When a team swaps model endpoints, adds a new tool, or changes an MCP server configuration, a spreadsheet does not update. By the next audit cycle, the documented inventory no longer reflects the running system. The only inventory that stays current is one generated automatically as a byproduct of the governance system that is actually running.
Centralized inventory is not a documentation exercise. It determines whether your governance system can enforce policy on the right assets and produce evidence an assessor can validate.
An AI asset is not just the model. It is the full set of components an agent interacts with: the primary model, any secondary models in a multi-agent chain, the tools registered for function calling, the datasets the agent retrieves from, and any MCP servers the agent connects to. Governance systems that cover only the model and ignore the tools leave a structural gap, because the tool calls are where most of the risk lives.
The CycloneDX AIBOM specification provides the machine-readable format for representing this full inventory, capturing models, datasets, dependencies, and provenance in a structure that an assessor can validate without relying on vendor summaries. Prediction Guard registers all of these components into AI Systems, and the AI Bill of Materials (AIBOM) is the exportable view of that inventory in CycloneDX format, generated as a byproduct of the registration that active runtime enforcement already requires.
Registering assets into a centralized system produces a defensible architecture for three reasons:
Agent sprawl risks vs. framework controls
The mapping below reflects how these agent sprawl risks align to AIUC-1's pillar structure based on the framework's definitions, not an officially published AIUC-1 crosswalk.
| Agent sprawl risk | AIUC-1 pillar | NIST AI RMF function |
|---|---|---|
| AI agents operating outside the centralized asset inventory | Data and Privacy | GOVERN 1.6: AI system inventory |
| Agent tool calls executing outside IAM authorization boundaries | Security | MEASURE: Security risk evaluation |
| Agent outputs without factual consistency checking | Safety | MEASURE: Output validation |
| Enforcement decisions executed without retrievable, structured audit records | Accountability | GOVERN: Accountability and documentation |
| Model endpoints swapped without governance review | Reliability | MAP: Dependency tracking |
| Customer-facing agent calls executing without a registered asset record or active runtime policy enforcement | Society | MAP: Impact assessment |
The AIBOM provides the asset inventory that assessors require. The runtime enforcement layer demonstrates whether each registered asset operates within defined policy on every call. These are distinct capabilities, and both are required for a complete compliance posture.
CISO approval requires more than a policy document. It requires demonstrable, architecture-level evidence that enforcement happens uniformly across every registered agent, independent of individual developer implementation choices.
When governance logic lives inside application code, it is only as reliable as the developer who wrote it and only as current as the last time that developer updated it. Requiring every engineering team to implement prompt injection defense, PII masking, and factual consistency checking (probabilistic, not deterministic) in their own codebases produces inconsistent results and creates a maintenance burden that compounds as agent complexity grows.
A centralized control plane enforces policies uniformly across every registered agent, regardless of which framework the developer chose or which engineer originally wrote the code. The enforcement decision happens at the API level before the call completes, not retrospectively after logs are analyzed.
The OWASP Top 10 for Agentic Applications frames defense in depth as the appropriate response to agentic security risk: tool misuse (ASI02) and identity abuse (ASI03) are most effectively mitigated when controls operate at multiple layers simultaneously, including runtime monitoring between the agent and the tool, access controls, and infrastructure security measures, because application-layer safeguards alone cannot anticipate the full scope of dynamically constructed tool calls.
Consistent policy enforcement across all registered agents means prompt injection defense, PII detection and masking, output filtering, and factual consistency checking all apply from a single configuration point. Security and GRC teams configure these policies on the Govern page of the Admin Console. The control plane enforces content-layer and access-control policies on every model call, and every tool an agent can invoke must be registered and permitted in the Admin Console before it is callable, regardless of which team deployed the agent.
This separation of duties matters for regulated enterprises because a security team can change policy coverage without touching application code, and a developer can ship new agent features without rebuilding the governance logic that applies to them.
As Noblis CEO Mile Corrigan described when announcing Noblis Ventures' investment in Prediction Guard:
"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."
Governance embedded in application code is fragile in a specific way: it depends on institutional knowledge. When the engineer who implemented the policy validation logic leaves, the next developer may not understand why the check exists, and under delivery pressure, may remove or bypass it. Governance enforced at the control plane level is decoupled from individual codebases entirely. The policy exists in the Admin Console configuration and enforces uniformly, regardless of staff changes in the engineering team. This is the structural argument that resonates with Legal stakeholders: a policy document that relies on individual engineers remembering to follow it is not a control. A control plane that enforces it on every call regardless of who wrote the code is.
Runtime enforcement produces evidence. Turning that evidence into audit-ready documentation requires mapping each enforcement capability to the specific framework control it addresses for your assessor.
The AIUC-1 standard organizes AI governance requirements across six pillars: Data and Privacy, Security, Safety, Reliability, Accountability, and Society. Each pillar maps to specific runtime enforcement capabilities that a control plane provides. Data and Privacy requires sensitive data to be identified and handled within defined boundaries. Security requires access controls and audit mechanisms to be active at runtime. Accountability requires structured evidence that enforcement happened. A control plane enforces each of these from a single infrastructure deployment, rather than requiring separate point solutions that generate inconsistent evidence trails. The AIUC-1 crosswalk view shows how this maps across other standards.
The NIST AI RMF Govern function requires establishing organizational policies for AI risk. Map requires identifying AI assets and their risk profiles. Measure requires evaluating whether controls are working. Manage requires responding to identified risks. A control plane that enforces policy at the API level, generates structured audit logs, and registers all AI assets in a centralized inventory addresses all four functions from a single deployment. The NIST AI RMF playbook provides the capability-to-function mapping in detail.
Prediction Guard generates structured audit logs inside the customer's perimeter, formatted to match the native field schema of Splunk, Datadog, CrowdStrike, or syslog, so the evidence trail lives inside your infrastructure and the SIEM your security team already uses. For full configuration steps, see the dedicated SIEM integration guide.
Start with a runtime enforcement layer that generates its own evidence, not a spreadsheet and not a policy wiki. Book a deployment scoping call to assess how a self-hosted control plane fits your infrastructure and risk requirements, or download the AIUC-1 and NIST AI RMF capability mapping whitepaper to review which specific framework controls the system addresses at the API level.
Register all models, tools, and MCP servers as assets within the Prediction Guard Admin Console. This centralized registration generates an exportable AIBOM in CycloneDX format as a byproduct of active governance.
Unmonitored tool calls allow autonomous agents to execute database queries or call external APIs without security oversight, exposing the enterprise to data leakage, privilege escalation, and compliance violations. Because agents construct these calls dynamically at runtime, traditional IAM controls and perimeter firewalls cannot inspect or block them.
Yes. Developers only need to repoint their SDK base_url to the Prediction Guard control plane endpoint. The control plane then enforces all configured security and risk policies transparently at runtime, and existing OpenAI-compatible, Anthropic-compatible, or LangChain-based code continues working unchanged.
The NIST AI Risk Management Framework requires a documented AI system inventory covering models, data sources, versions, and oversight roles. Registering assets in Prediction Guard produces an inventory that supports these requirements, runtime enforcement of policies on every agent call addresses the operational control requirements, and SIEM-formatted audit logs provide the structured evidence of control effectiveness.
Agent sprawl: The unmanaged proliferation of autonomous AI agents across an enterprise without centralized visibility or runtime policy enforcement.
Non-Human Identity (NHI): The digital credentials and permissions assigned to autonomous agents or service accounts, which traditional IAM systems fail to monitor dynamically because agents accumulate and exercise these credentials at runtime without human review.
AI Bill of Materials (AIBOM): A structured, machine-readable inventory of every component in an AI system, including models, datasets, tools, and dependencies, typically exported in CycloneDX format as a byproduct of centralized asset registration.
Sovereign AI control plane: A self-hosted infrastructure system that intercepts AI API calls at runtime to enforce security, privacy, and risk policies within the organization's perimeter, generating structured audit logs as evidence of enforcement without routing data through external vendor systems.
Factual consistency checking: A probabilistic capability that evaluates generated content against trusted data sources to flag potential grounding failures. Probabilistic means it surfaces risk signals rather than guaranteeing factual accuracy.
AIUC-1: A cross-framework compliance standard that maps AI governance requirements across six pillars: Data and Privacy, Security, Safety, Reliability, Accountability, and Society. Provides a unified view of how multiple regulatory frameworks align.
CMMC (Cybersecurity Maturity Model Certification): A unified standard for implementing cybersecurity across the defense industrial base. C3PAOs (CMMC Third-Party Assessment Organizations) conduct formal assessments to verify compliance with CMMC requirements.
SIEM (Security Information and Event Management): A system that aggregates and analyzes security logs from across an organization's infrastructure. Examples include Splunk, Datadog, and CrowdStrike.
MCP (Model Context Protocol): A standard protocol that allows AI agents to connect to external data sources and services. MCP servers provide structured interfaces for agents to retrieve context and invoke tools.
PII (Personally Identifiable Information): Data that can identify a specific individual, such as names, addresses, Social Security numbers, or email addresses. Regulations like GDPR and HIPAA require specific protections for PII.