79% of Enterprises Run AI Agents in Production, and the First MCP Flaw Is Already on CISA's Exploited List

Most enterprise conversations about AI agent risk start with the agent: what it might be tricked into saying, which prompt might turn it against its owner. The evidence gathered over the past six weeks points somewhere less glamorous. The real exposure is the plumbing underneath, the model gateways that hold every provider key, the Model Context Protocol (MCP) servers that hand agents their tools, and the configuration files that wire it all together. That plumbing is now in production at most large organizations, and almost none of them govern it with tools designed for the job.

Agents Went Live Before Anyone Built the Controls

SailPoint's fifth annual Horizons of Identity Security report, released October 6, surveyed 340 senior identity, IT, cybersecurity, and risk leaders. It found 79% of organizations are already running AI agents in production, while just 2% use identity security tools designed to manage and govern them, a gap SailPoint puts at 40 to 1. Agents now account for 22% of all non-human accounts, yet 85% of organizations still rely on legacy identity tools that were never built for agentic identities, and 54% sit at the lowest maturity tier for agent identity. Only 15% can provision non-human access in real time, and only 43% feel prepared to produce verifiable evidence in an AI-related audit. "You cannot bridge this gap by asking human-speed tools to work faster," said Wendy Wu, SailPoint's chief marketing officer.

Those numbers describe a governance problem in the abstract. The incidents of the past quarter show what it looks like on the wire, and they cluster in exactly the components that let agents reach models, tools, and data at scale.

The Gateway That Accepted Any Token

LiteLLM is an open source proxy that sits between applications and model providers, which makes it a natural home for every provider API key an organization owns. Wiz Research published its analysis on September 9: when a bearer token failed validation, LiteLLM's MCP authentication handler fell back to an empty authentication object instead of rejecting the request, so a single garbage token such as "Bearer a" produced a valid MCP session. The flaw, CVE-2026-59822, is fixed in version 1.84.0. Wiz saw it exploited against its honeypots on July 7, and CISA added it to the Known Exploited Vulnerabilities catalog on September 2. A separate flaw, CVE-2026-59821, let custom code guardrails run through exec() without a sandbox and execute commands as root until version 1.82.0. A third issue, pass-through endpoints that can reach cloud metadata services such as AWS IMDS, remains unfixed because the vendor considers it working as intended for admins.

The exposure is not hypothetical. Wiz scanned 3,074 internet-facing LiteLLM instances in February and found 294, or 9.6%, accepted the default master key "sk-1234" or required no authentication at all, with 191 requiring none. By Wiz's own data, about one-third of cloud environments contain a LiteLLM deployment. Adversa AI's October MCP security roundup describes the LiteLLM bug as the first MCP vulnerability to reach CISA's catalog, a milestone that moves agent tooling from research curiosity into the same patch-or-be-breached category as VPN gateways and edge firewalls.

Hardcoded Keys and Scanners That Look the Other Way

The configuration layer is no healthier. Hush Security's August research parsed roughly 82,000 public MCP configuration files across more than a dozen coding agents. It found 12% of credential slots hardcode a credential literal, 55% of those hardcoded secrets have no vendor-recognizable token shape (so pattern-based secret scanners may miss them), and 24% of all hardcoded literals are both broad in scope and non-expiring. Hush describes the counts as lower-bound estimates, because GitHub code search covers only default branches and excludes forks. Every one of those files is a set of standing credentials an agent can use, sitting in a repository where anyone who reads it can use them too.

Organizations that try to vet MCP servers before installing them face a further problem. Pluto Security reported on September 15 that it built two working malicious servers, both presenting themselves as weather tools. One read SSH, AWS, and Kubernetes credentials on every call while still returning a normal forecast; the other fetched and ran shell commands from a remote server. Tested against five scanners, including Cisco's mcp-scanner, Snyk's agent-scan, and NVIDIA SkillSpector, every scanner returned a clean or zero-finding result for at least one malicious server in at least one configuration. The evasions were mundane: honest-looking metadata over malicious handler code, files padded past a size limit, servers that showed scanners a benign description, and commands fetched only at run time, after the scan had finished.

Taken together, the pattern is consistent. Agents are being connected to enterprise systems through components that hold broad, long-lived credentials, that are reachable from the internet, and that cannot be certified safe by a one-time scan. Identity programs that track people and service accounts do not see these connections as identities at all, which is precisely the gap SailPoint measured.

• Inventory the plumbing, not just the agents. List every model gateway, MCP server, and agent configuration file in use, including developer laptops and test clusters, because LiteLLM appears in about a third of cloud environments.
• Patch and lock down LiteLLM now. Move to version 1.84.0 or later, replace any default master key, review guardrails for unexpected entries, and restrict container egress so pass-through endpoints cannot reach cloud metadata.
• Get secrets out of MCP configs. Replace hardcoded literals with references to a secrets manager, rotate anything that has ever been committed, and give every token a scope and an expiry.
• Treat a clean scan as one signal. Pin MCP servers to a reviewed version and hash, test new ones in isolation with fake credentials, and count an incomplete scan as a failed gate.
• Give agents their own identities. Register each agent as a governed non-human identity with an owner, least-privilege access, and real-time revocation, rather than letting it borrow a gateway's master key.
• Prepare the audit trail before you need it. With only 43% ready to produce evidence in an AI audit, log which agent called which tool with which credential, and keep those logs where investigators can reach them.

The first wave of agent security spending has gone toward guarding the model's front door. The LiteLLM bypass, the leaked MCP keys, and the scanners fooled by a weather app all sit behind it, in infrastructure that IT teams installed quickly and rarely revisit. With agents already in production at four out of five organizations, the plumbing deserves the same inventory, patch discipline, and identity governance as any other system that holds the keys to the estate.