How to see every AI agent in your enterprise, prove what it’s allowed to do, and stop it when it goes wrong
MuleSoft announces new governance and security capabilities for Omni Gateway, giving CISOs and IT teams a single layer of visibility, identity and containment for enterprise AI agents. See what’s running across your whole estate, give every agent a verifiable identity, keep provider credentials out of agent hands, catch an agent going off the rails, enforce guardrails across AWS, Azure, and F5, and halt any agent in seconds, with an audit trail built in.
–
There’s a new labor pool cropping up across your enterprise, and most of it was never onboarded.
Autonomous agents now update core systems, execute transactions, and act across the tools your business relies on. Because building an agent no longer requires writing code, business teams are creating them faster than IT and security teams can account for them. What began as shadow AI has become a shadow workforce.
Standing up an autonomous agent takes an afternoon. Getting security, FinOps, and operations to sign off on running it in production is the real bottleneck, because the controls that make sign-off possible haven’t traditionally existed. Security leaders know how to manage non-human identities. Non-deterministic ones are a different problem entirely.
You could build those controls yourself, and some teams will certainly try. But every hour spent building bespoke agent security is an hour not spent defending the enterprise.
The alternative is a platform where those controls are native. Omni Gateway, MuleSoft’s governance layer for both APIs and AI, already sits in the path of your agent, MCP, and LLM traffic. Building governance and security at that layer means the same controls apply to every agent, whatever it was built on and whatever model it calls, organized around the questions CISOs are actually asking.
What’s running, and where?
Universal Policy Catalog
A single point of control for every AI interaction changes what governance & security teams can know. Sitting between your agents, models, and systems, Omni Gateway observes, policies, and logs every call in one place.
Most enterprises run more than one gateway across Kong, Apigee, AWS, and Azure, and each provider speaks its own policy syntax. That fragmentation is where drift creeps in, as the same rule gets hand-authored separately for every gateway and enforced a little differently each time.
Universal Policy Catalog closes the gap: define a canonical policy once and push it to any connected gateway from a single control plane, with translation into each provider’s native format handled automatically on the way. It ships with around 10 policies covering an estimated 80% of enterprise APIM use cases, and every push is logged, so consistent enforcement across the estate comes with a full audit trail rather than a fragmented map with gaps where agents like to hide.
What can this agent actually do?
Trusted Agent Identity, MCP Authentication & Tool Governance, Secret References and External Vault Support
Every agent that touches your systems should carry an identity you can verify, with privileges you deliberately granted. Trusted Agent Identity gives each agent exactly that: a verifiable identity that travels with it, so access decisions rest on who the agent is and what it’s permitted to do rather than on whatever credentials it happens to hold.
An agent is only as safe as the tools it can reach. MCP Authentication centralizes access for every MCP server connection and enforces the allowlist at the gateway, not inside the agent’s prompt. If a tool isn’t approved, the agent can’t use it, regardless of what its instructions say. An agent talked into calling an unapproved tool by a prompt injection has that request blocked before it ever reaches the server.
Just because agents require autonomy, doesn’t mean they should get the keys to the kingdom; provider credentials too often sit in plaintext configs or scattered across platforms, and every copy is an attack surface.
With External Vault Support, secrets stay in the vaulting infrastructure you already trust, including AWS Secrets Manager, Azure Key Vault, and HashiCorp Vault, with more sources on the way. Credentials are fetched just-in-time, held only in volatile memory, and wiped the moment access is revoked.
Developers will also never touch raw keys. Utilizing Secret References, they’ll work with a stable, abstract URI, and the raw credential never reaches the proxy, your code, or your logs. Rotate a key in your vault and every consumer picks up the new value on its next call, with no code changes and no redeployments. Every resolution is logged with the calling identity and timestamp, so the audit trail is complete without a single plaintext value in it.
What stops it mid-flight?
F5 Calypso Guardrails, Akamai integration, Agent Kill Switch and Rogue Agent Detection
Identity and policy set the boundaries before an agent runs. Guardrails and containment hold the line while it does.
Runtime protection now extends across the environments where your agents actually operate, with Calypso Guardrails enforcing behavior on AWS, Azure, and F5.
And through our Akamai Security Integration, agent traffic gains the same edge-layer defense that protects your most critical web infrastructure, screening threats before they reach an agent or the systems behind it.
Operators can’t override what they can’t see, and at fleet scale a rogue agent can burn budget or breach its scope faster than a human notices. Rogue Agent Detection watches agent behavior across the estate and surfaces the anomalies that warrant intervention: sudden spend spikes, credential misuse, access outside an agent’s normal scope, and runaway request loops. Each alert names the agent, the scope, and the trigger, and routes to the MuleSoft console, Slack, or Microsoft Teams, so an operator moves straight from signal to action without hunting for what went wrong.
That action is the kill itself. Redeploying an entire runtime to stop one misbehaving agent is too slow, so Agent Kill Switch gives operators a precise override instead. Halt a single request, a session, an individual agent, or, in a true break-glass scenario, an entire tenant. Choose a soft stop that lets in-flight work drain cleanly or a hard stop that cuts traffic instantly. Trigger it from the console, Slack, Microsoft Teams, or the API, wherever the incident finds them.
What sets this apart is where it acts. Enforcement reaches down to the credential and identity layer, not just the network gateway, and detection runs at that same layer, so the signals that flag an agent are the signals used to contain it. Every intervention is reversible with a single Restore command that returns the agent to its exact prior state, so a false positive costs you seconds, not a weekend of remediation. And every action writes a tamper-evident, hash-chained record of who intervened, at what scope, and what it affected, the kind of documentation strict standards like the EU AI Act demand.
The bottom line
Boards and regulators don’t accept “the agent decided to” as an answer. Because every interaction flows through the gateway, every interaction leaves a record: which agent acted, under what identity, against which policy, with what outcome. Kill actions go further, writing tamper-evident, hash-chained records of who intervened, at what scope, and what it affected, the kind of documentation strict standards like the EU AI Act demand. When something goes wrong, your team investigates with lineage, not reconstruction.
Your agents weren’t all built on one platform, and your security controls shouldn’t assume they were. See what’s running, verify what each agent is, contain the ones that turn, and prove every step, all from the gateway your traffic already runs through.
The enterprises that scale agents safely will be the ones that made visibility, identity, containment, and evidence the foundation rather than the retrofit. That foundation is available now.
