tools for securing and observing multi-agent AI systems in the enterprise
Enterprises lag far behind the shadow AI threats already spreading through their systems.
Multi-agent AI systems break the old rules of enterprise security. The questions that mattered for a single model, is this prediction accurate, is it fair, don't cover what happens when a dozen agents start delegating tasks, calling APIs, and remembering things across sessions. Securing this stuff takes several distinct layers of tooling: identity control, threat detection, and observability each solve a different failure mode, and none of them cover for the others. Gartner surveyed 360 IT application leaders between May and June of 2025 and found that 74% believe AI agents represent a genuinely new attack vector, not a rebrand of old risk with a shinier name. Only 13% strongly agreed they had the right governance in place to manage it, which tells you almost everyone answering that survey knows they're behind.
Old-school model governance asked narrow questions about accuracy and robustness. Agent governance has to ask what objective the agent got handed, which tools it can call, whether it can delegate to other agents (and how far that chain runs), what it remembers between sessions, and how much it can spend before someone yanks the cord. Multi-agent setups stack complexity on complexity. Agents talk to each other sideways, pass context back and forth, and take real actions against APIs, SaaS tools, and databases, and every handoff between them is a trust boundary nobody drew on purpose. The perimeter security built for a human clicking through a VPN never modeled any of this. It shows.
How fast ungoverned AI is already inside enterprise systems
Shadow AI stopped being an edge case a while back. It's the default now. Projections for 2026 put 76% of organizations flagging shadow AI as a definite or likely problem, up from 61% in 2025, and 98% of organizations already report unsanctioned AI use somewhere inside the building. Half of those organizations expect a shadow AI incident within the next twelve months, which is a strange thing to be able to predict about your own company and still do nothing about. SpeakeasyAPI, for instance, is built as an AI governance and observability platform precisely because that gap between knowing and acting is where enterprises keep getting burned.
Harmonic Security ran a 2025 analysis across 22.4 million enterprise AI prompts and found 579,113 sensitive data exposures spread across 665 distinct generative AI tools. Nearly 98,000 of those exposures, about 16.9%, happened on personal free-tier accounts that IT has zero visibility into. That traffic touches no CASB, DLP appliance, or SIEM unless somebody built browser-level monitoring specifically to catch it, and most companies never got around to that.
The lag makes it worse. IBM's 2025 analysis found shadow AI breaches take 247 days to detect on average, six days longer than a standard breach. Customer PII showed up in 65% of shadow AI breaches versus 53% of standard ones, and intellectual property exposure ran higher in the shadow cases too. Among organizations that reported an AI-related breach, 97% didn't have proper AI access controls in place, according to that same IBM data. Nearly everyone who got burned was running with the door unlocked, which is less a security failure than an admission nobody checked if the door had a lock at all.
Banning the tools doesn't fix it, either. Roughly half of employees keep using personal AI accounts after a company prohibits them outright, because the productivity gain beats the risk of getting caught. Meanwhile the surface keeps growing: Gartner projects AI agents will sit inside 40% of enterprise applications by the end of 2026, up from under 5% in 2025. Security teams are chasing a target that speeds up every time they close the distance.
A memo won't close this gap. What closes it is detection infrastructure that watches AI activity as it happens, instead of surfacing the problem weeks later when someone stumbles onto it by accident.
Shadow AI detection tools: finding what's already running in your environment
Traditional shadow IT discovery doesn't map onto AI cleanly. Most AI usage runs through the browser, through OAuth-connected agents with standing data access, and through API tokens scattered across a dozen services, and none of that shows up in a firewall log or a DNS record. MCP servers can hand internal APIs to agents without leaving anything resembling a normal network signature. Finding it is a bit like hunting for a needle that keeps moving because it knows you're looking.
Good shadow AI detection scans browser traffic and SaaS OAuth grants continuously, catching unapproved connections as they happen instead of during a quarterly audit that arrives three months too late to matter. It finds the API tokens and credential chains giving agents quiet, persistent access nobody signed off on. It sorts what it finds by actual risk, because a coding assistant reading public documentation and an agent with write access to your CRM are not the same problem wearing different clothes. And it feeds all of that into the SIEM and CASB pipelines security teams already watch, so it adds to an existing workflow instead of becoming one more dashboard nobody opens.
Most tools on the market weren't built for this job. They were built to catch SaaS sprawl, someone signing up for a new project management tool with a corporate email address. Agents calling tools programmatically, leaving behind no audit trail a human could actually read, sit well outside that original design. IBM found that shadow AI incidents add $670,000 to average breach cost. That's a real number to put in front of whoever controls the detection budget, not a scare figure.
A control plane like Speakeasy puts a governed connection layer in place so every agent and MCP server interaction is visible in real time, by construction, rather than something a security team has to go digging for after the damage is done.
Identity and access control tools: enforcing who — and what — can act on enterprise systems
Identity in a multi-agent system is a structurally different animal. Old-school IAM deals with human users or service accounts holding static roles that barely change year to year. Agentic systems don't work that way: an agent might act on behalf of a person, spawn sub-agents to handle pieces of a task, hand authority further down that chain, and pick up permissions across a string of tool calls, none of which role-based access control was ever built to track. NIST launched its AI Agent Standards Initiative in February 2026 aimed squarely at identity, authorization, monitoring, and interoperability for agents. That alone tells you the standards world already agrees existing identity tooling comes up short here.
So what actually has to change? Permissions get assigned and enforced per agent, per skill, per tool call, not a blanket "this person is allowed to use AI" checkbox. Agent identity needs to tie back into the identity providers companies already run, Okta, Entra ID, SAML or OIDC, so access decisions inherit the role structure that already exists instead of spinning up a second permission system nobody has time to maintain. Least privilege has to be the default, not a nice-to-have goal on a slide somewhere: a customer support agent should not carry the same access as one writing to financial systems. Delegation needs hard limits, so an agent can't hand its own permissions off to a sub-agent it just spun up on the fly. And sensitive operations get just-in-time access, granted for the moment it's needed, rather than a standing grant sitting open indefinitely like a door propped with a brick.
The OWASP Top 10 for Agentic Applications 2026 lists excessive agency and insecure permissions as core threat categories right alongside prompt injection. That's a formal admission that access control failures count as attack surface now, not a box the audit team checks once a year and forgets about.
Speakeasy runs RBAC through the identity providers a company already has, so every agent and MCP server interaction gets governed by the same policy the rest of the stack answers to. No second permission system to babysit.
Prompt injection defense tools: protecting agents that consume untrusted content
Prompt injection is a harder problem than standard input validation, for one specific reason: it attacks the instruction layer of the model itself. The exact thing that makes a language model useful, its willingness to follow instructions, is the thing an attacker turns into a weapon. In a multi-agent setup the damage compounds, because a compromised agent can pass its poisoned instructions downstream to every agent it coordinates with. One bad injection becomes a chain reaction, and nobody notices until the third or fourth agent down the line does something it really shouldn't.
This threat is live, not hypothetical. Pillar Security's research from late 2024 found roughly one in five jailbreak attempts succeed, and 90% of successful prompt injections lead to sensitive data leaking out. Through 2025, Brave's security team disclosed indirect injection flaws in agentic browsers, where hidden instructions buried in a webpage tricked an agent into leaking data from a user's other logged-in sessions. OpenAI launched Lockdown Mode in February 2026, following an admission in December 2025 that prompt injection in AI browsers "may never be fully solved." That's about as blunt as this industry gets. Full prevention may need real architectural tradeoffs, not just a smarter filter bolted on after the fact.
Defense tools work both ends of the pipe. Input scanning checks content entering an agent's context window for instruction-like patterns before the model processes any of it. Output monitoring flags responses that look like they're acting on injected instructions rather than the task the user actually asked for. Context isolation keeps trusted system prompts walled off from untrusted external content, whether that's a document, a webpage, or the output of another tool. Real-time alerting lets a team block, quarantine, or route suspicious activity to a human for a second look, which is still, for now, the last line of defense that actually works.
Speakeasy builds real-time prompt injection detection into its governed connection layer, so individual agents don't each need to be hardened one by one. Protection sits at the infrastructure level, regardless of which model or framework is doing the work underneath.
PII and secrets leakage prevention tools: keeping sensitive data from leaving through the AI layer
Data loss in agentic systems looks different from data loss in the DLP playbook most security teams grew up on. Agents pull context from a handful of places at once, CRM records, code repos, internal wikis, and stitch it together before handing it to a model, often one running on someone else's servers entirely. That combined context can carry PII, credentials, API keys, or proprietary data that wouldn't trip a DLP rule if any single source got checked on its own. The danger lives in the combination, not any one ingredient.
LayerX's 2025 report puts numbers on how bad the habit already is: 77% of workers paste sensitive data into generative AI tools, 82% of those pastes happen from personal accounts sitting outside IT's view, and 40% of file uploads to these tools contain PII or payment card data. Sit with that last figure for a second. Two out of every five files.
Traditional DLP was built to inspect email attachments and file transfers, leaving natural language prompts and API payloads headed to an external model endpoint largely unexamined. Personal free-tier accounts don't generate any signal in corporate monitoring at all, which means for a huge chunk of this traffic, nobody's even watching the door, let alone guarding it.
An AI-aware version of this tooling inspects prompt content in transit, not just file metadata after the fact, catching PII patterns, credentials, and secret formats as they're typed. It runs entity recognition at inference time: names, account numbers, Social Security numbers, API tokens, private keys. It redacts or blocks before the request leaves for the external model, not after the fact when the damage is already done. And it logs what got caught and what happened next, because compliance teams and incident responders both need that trail eventually.
Speakeasy's real-time threat detection handles PII blocking and secret detection as part of its control plane, intercepting at the governed connection point before anything reaches an outside service, with every catch logged for audit.
MCP gateways: the governed distribution layer for agent-to-tool connections
MCP made it dramatically easier to wire agents into tools like Slack, Jira, Datadog, Outlook, and internal APIs through one shared protocol. That's the whole appeal, and it's also the whole problem. The same low friction that makes MCP powerful means developers can spin up custom MCP servers fast, often with zero security review, leaving a company with fragmented infrastructure and no central view of what's connected to what. Every MCP server is, functionally, a production API surface, whether anyone treats it that way or not. Most organizations still treat it like a side project.
A gateway fixes the structural gap. It gives you one point of entry for every agent-to-tool connection, with traffic visibility, authentication, and policy enforcement living in a single layer instead of scattered across a dozen ad hoc integrations built by different teams at different times. It logs every tool call centrally, no matter which agent or model made it. It lets IT curate an approved catalog of MCP servers, with RBAC governing who on which team gets access to what. And it handles traffic management and rate limiting, so a runaway agent doesn't rack up a surprise cloud bill or fire off a bulk operation against a production database because nobody put a speed bump in its way.
Gartner's emerging practices guidance recommends treating MCP with the same gateway-centric architecture used for any API surface. That's the right frame, because MCP servers are API surfaces. They just happen to be agent-facing ones, which somehow keeps getting treated as a technicality instead of the whole point.
The 2025-2026 field has a few notable entries. Kong shipped MCP capabilities in its AI Gateway version 3.12 in October 2025, adding an MCP Proxy plugin with OAuth 2.1 support, a sensible move for anyone already running Kong as their API gateway. TrueFoundry landed as a Representative Vendor in the 2025 Gartner Market Guide for AI Gateways, the only MCP-capable platform in that cohort, which matters to organizations that want analyst validation before they buy anything. Obot's MCP Gateway targets Kubernetes deployments and lets IT curate an approved server catalog with centralized usage monitoring. Docker's MCP offering does container-native isolation per server with cryptographic image signing, solid for supply chain security during development, though it lacks the production RBAC and audit logging an enterprise deployment actually needs.
Speakeasy functions here as an enterprise control plane that governs MCP servers right alongside agents, skills, and assistants, enforcing identity, access policy, and real-time threat detection at the connection layer instead of treating MCP as its own separate problem to solve.
Before buying any gateway, ask one question: does it plug into the identity provider you already run, or does it ask you to stand up a whole new permission system from scratch? The first path holds up over time. The second is just sprawl wearing a nicer name.
