TL:DR
- Traditional AI governance frameworks rely on human-led oversight that cannot keep pace with the speed and scale of autonomous agent actions in enterprise environments.
- A federated governance architecture — combining AI harnesses, guardian agents and AI firewalls — addresses the risk of both over-restricting and under-restricting agents with different autonomy levels.
- Deploying agentic AI governance at neutral interconnection hubs enables real-time policy enforcement, sovereign geofencing and multicloud observability without backhauling traffic.
As enterprises ramp up agentic AI adoption, traditional governance processes are no longer good enough.
These processes typically rely on humans to make all the major decisions. A committee gets together throughout the year to define what secure, compliant operations look like, and then sends those decisions to be enforced throughout the company.
This approach won’t work with autonomous agents, because they operate much too quickly. In the time it takes the committee to discuss what agents did last month, those same agents will perform hundreds of new actions.
It’s impossible to manually enforce governance in an environment where agents can take actions much faster than humans can even register them, let alone understand and vet them. This could limit the effectiveness of AI agents going forward. In fact, “Gartner® predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents due to governance gaps identified only after production incidents occur.”[1]
It’s clear that enterprises need a new approach to governance for the agentic AI era, but many of them won’t even know where to start.
Why now is the time to change AI governance
There was a time when traditional, human-led governance made sense, but we’re no longer living in that time.
Agents move so quickly that it can obscure the true impact of their actions. Each individual action might seem small and inconsequential if you look at it in isolation, but all the different actions across all the different agents could add up to a major shift in the way organizations operate. It could also create new risks that they aren’t prepared for.
The governance team would stop this if they could see the full scope of the changes, but the problem is that they aren’t able to see it until after the changes have already been made.
Enterprise leaders need to address this issue now, since agentic AI adoption is just beginning to ramp up. As agents are deployed into production, they’ll create connections and dependencies throughout the organization. If they go without appropriate governance for long enough, risk will become ingrained. It will be very difficult and expensive to undo that damage.
Different agents have different governance requirements
Agents don’t all operate the same way, and thus don’t have the same governance requirements. This is a challenge that will grow increasingly complex as the AI agents themselves grow more differentiated and specialized:
“Gartner predicts 40% of enterprise apps will feature task-specific AI agents by 2026, up from less than 5% in 2025.”[2]
When organizations apply a one-size-fits-all approach to governing agents, it will lead to under-restriction for some agents and over-restriction for others:
- Under-restriction means that more powerful agents are allowed to shift away from their original scope. When this happens, their actions can become increasingly unpredictable and risky.
- Over-restriction means that simpler agents may not be allowed to perform the basic tasks they were designed to perform. This could limit the business value of deploying those agents in the first place.
Today’s enterprises need a way to avoid both under-restriction and over-restriction for their AI agents. Different agents have different levels of autonomy, so they need governance that’s customized for their needs.
Enterprises need governance controls that run at agent speed
To provide governance controls for agents, architects usually employ a combination of the following approaches:
| Governance location
(relevant persona) |
Pros | Cons |
| 1. Inside the agent/model itself (application architect) |
· Low latency (no extra network hops)
· High contextual awareness · Simplifies architecture for standalone apps |
· Couples safety logic with application logic
· Increases prompt bloat and token costs · Agent behavior drifts off-course from intended goals · Easier to bypass via prompt injection |
| 2. AI harness
(application architect and IT architect) |
· Governance logic and code is separate from the agent’s AI model
· AI harness runs inside agent sandbox as part of frameworks like NVIDIA OpenShell · Store harness at a cloud-neutral location to easily pivot between different AI models |
· Maintenance overhead of keeping the harness rules up to date
· Higher operational costs if the solution uses multiple agents across different providers |
| 3. Guardian agent (domain subject matter expert) |
· Keeps the primary agent focused on its task
· Highly adaptable to complex, multi-step workflows · Can perform deep reasoning over agent outputs · Customized for industry verticals like healthcare and finance; usually provided by domain-expert companies |
· Increases latency
· High operational cost (runs multiple LLM calls) · Needs complex state synchronization |
| 4. AI firewall (infosec personnel) |
· Centralized safety policies across all company apps
· Decoupled from application code · High performance (often uses fast, specialized models) |
· Less access to specific application context
· Can be rigid and block valid custom use cases |
In these examples, agents are typically deployed in proximity to the data source. Guardian agents and AI firewalls also need to be strategically deployed to optimize cost and performance.
The case for a federated observability platform
As shown in the diagram above, guardian agents will typically need to access and process distributed logs of multiple agents in the agentic pipeline. Therefore, it’s critical to have an observability platform that can stitch together insights from logs distributed and stored across multiple providers.
Storing or aggregating logs at a central location doesn’t scale in the agentic world. This is primarily due to the high egress costs of moving logs from clouds, as well as the need to analyze agent interactions in real time.
It’s desirable to store the log-analysis engine, consisting of GPUs that analyze guardian agent queries, at a cloud-neutral location that has high-speed and low-latency connectivity to hyperscalers, SaaS vendors, enterprises, neoclouds and Model as a Service providers. These are the locations where most agents will run. This log analysis engine, consisting of an AI model and metadata context catalog, breaks down the guardian agent query into sub-queries across distributed agent logs, and then aggregates the insights. Thus, guardian agents can leverage such a federated data platform.
If enterprises are using agents invoked from triggers (by humans, other agents, or external signals) from the edge, then it makes sense to decouple the agent’s harness from the AI model, and store the harness logic at a cloud-neutral interconnection hub like an Equinix data center. This gives the agent the flexibility to switch between AI models from different providers without also having to move the AI harness.
NVIDIA OpenShell and NVIDIA Sentry aim to set safer boundaries for AI agents
The NVIDIA OpenShell framework provides a run-time execution framework for running the AI agent harness in an agent sandbox.[3] Each agent’s sandbox has kernel-level controls over the file-systems and networks the agent accesses. The OpenShell framework also has a supervisor that checks outbound agent requests against policies. It essentially keeps service credentials outside the workload. Finally, the OpenShell framework also has a gateway: the control plane that manages the lifecycles and policies of many agent sandboxes.
NVIDIA also proposed an in-silicon, out-of-band monitor called NVIDIA Sentry that runs on NVIDIA BlueField chips.[4] This extra hardware extends agent behavior monitoring and policy enforcement to the hardware level.
Best practices for a federated AI firewall architecture
As shown in the diagram above, it’s important to take the following points into consideration when deploying an AI firewall:
- Apply security policies at the edge: Enterprises have deployed thousands of Performance Hubs (network nodes) at Equinix to apply network security policies near data sources, rather than back-hauling it to a central location. In the AI world, it also makes a lot of sense to apply security policies locally.
- Employ a multicloud global control plane: Because AI is now a multi-provider affair, a governance control plane is increasingly important to enable AI guardrails and gateways across multiple clouds, both public and private. For example, traffic scrubbing should be kept local for agents and applications running inside a particular cloud. This helps avoid hair-pinning traffic for observability or auditing. Global control planes also help enforce policies across a chain of agent interactions spanning multiple providers.
- Adopt tiered governance model hosting: There’s also a growing need for private appliances that can be hosted on private infrastructure for maximum control and compliance, as well as cloud versions of these solutions that can run with quick setup and maintenance. This ensures that enterprises experience a consistent management plane across both public and private governance deployments.
The value of a neutral interconnection hub
In a multi-agent world, more customers are deploying federated governance architectures. Equinix interconnection hubs play a strategic role in these architectures by providing:
- Governance at the edge: Equinix data centers are within 10 milliseconds of end devices in more than 80 metros. In many metros, more than 90% of traffic flows from the edge via network service providers (NSPs) through Equinix. For cost, performance and privacy reasons, enterprises are deploying their AI firewalls and guardian agents in the metro where the data is generated, instead of backhauling traffic to a centralized location.
- Sovereign geofencing: Equinix can host agents in data centers across more than 35 countries, while Equinix Fabric® Geo Zones can geofence the network traffic between agents to ensure it does not leave a country or region.
- Ecosystem of more than 10,000 companies: All the major hyperscalers, SaaS vendors, NSPs, and enterprises interconnect at neutral Equinix interconnection locations. This offers a network-level observability platform customers can leverage as part of the agent traffic-monitoring and log-processing platform.
- Equinix Managed Solutions: Enterprises are deploying their log data-storage platforms, AI firewall platforms, and agent compute platforms at Equinix. We provide managed services for customers to consume these capabilities from leading storage, network security and GPU/CPU server vendors in a cloud-like manner.
Learn more about how Equinix Fabric Intelligence™, our AI-native network control plane, enables observability and automated control for AI workloads: Read the white paper, “Why intelligent networks are essential in the AI era.”
[1] Gartner press release, Gartner Says Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure, May 26, 2026.
[2] Gartner press release, Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026, Up from Less Than 5% in 2025, August 26, 2025.
GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.
[4] NVIDIA press release, NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment, September 28, 2026.

