AI Asset Sprawl as an Attack Surface Expansion Vector

Most security teams assume the danger in AI deployment is bad code: a model hallucinates a function, an agent writes something with a flaw in it, and that flaw ships to production. That framing is wrong, or at least incomplete enough to get someone breached. GitGuardian's research cited in The Hacker News states the real fight "isn't in the code anymore, it's in the credentials, tokens, service accounts, and machine identities that AI systems need in order to access data and take action." Attackers don't break in anymore. They log in, using a key someone forgot they left in a config file. The logic of the attack hasn't changed. It's the sheer number of doors now sitting unlocked, and nobody's counted how many there are.

Data has become executable, too. Pillar Security's term for this is "inference-time exploitation": an AI system gets compromised not through its code but through the data it ingests at runtime. A support ticket, a README file, a document in a shared drive, any of these can carry instructions an agent will act on. That's a different threat model than a buggy function. And it stacks directly on top of the identity risk, because the more data an agent can reach and the more systems it can act on, the more damage a single injected instruction can do.

Zooming out, the scale gets clearer. TechTarget's research, cited in finance.yahoo.com's forecast, puts the growth of the enterprise attack surface at more than 67% since 2022. AI is among the drivers of that number.

How AI deployment outpaced visibility: the governance gap that created the problem

Knostic's 2025 AI governance research found that 90% of enterprises already use AI in daily operations, but only 18% have a governance framework actually in place. That's most of the enterprise world running production workloads on a system nobody's fully mapped. That's most of the enterprise world running production workloads on a system nobody's fully mapped.

The gap didn't open overnight. It opened the normal way these things always open: one team adopts a tool, then another team adopts a different one, and none of it goes through a review process because no review process exists yet. By the time anyone in leadership notices, there are dozens of AI applications already live, each one with no assigned owner, no risk rating, and no one watching what it touches.

The numbers on blind deployment back this up. Evidence from 2026 suggests 82% of enterprises already have AI agents or workflows running that their own security teams never signed off on and don't know exist. Cisco's survey of 3,472 CIOs and technology leaders, run between March and April 2026, found the same pattern from a different angle: shadow AI activity, uneven policy enforcement, and poor visibility into AI-driven traffic came up repeatedly, and 71% of respondents said their blind spots are getting worse, not better.

IBM's 2025 Data Breach Report puts a number on the worst version of this: 86% of organizations have no inventory of where their AI connects or what data it can reach. No map. No list. Just a growing web of connections nobody's tracking.

And the trajectory only steepens. Gartner projects that 40% of enterprise applications will carry task-specific AI agents by the end of 2026, up from under 5% in 2025. Every one of those agents needs credentials to do its job. The inventory gap doesn't grow at a steady pace, it compounds. You cannot secure a system you cannot see, and everything covered in the rest of this piece, the identity sprawl, the credential leaks, the MCP vulnerabilities, is a downstream symptom of this one root failure.

The machine identity explosion: how AI tool stacks manufacture credential sprawl

Nobody deploys just one model. A real AI stack is a model provider, plus a retrieval service, plus an orchestration layer, plus a vector database, plus an inference gateway, plus monitoring tools, plus a local agent framework. Each piece needs its own way in: an API key, a token, a service account. Stacking five or six of these together multiplies the credential count fast.

Put simply, the AI boom is also a machine identity boom. Every one of those identities is a new way into the system, and each one has to be created, scoped correctly, rotated, and eventually shut off, none of which happens reliably at the pace AI teams move.

The scale is already visible in public data. GitGuardian's 2026 State of Secrets Sprawl report found 28.65 million new hardcoded secrets sitting in public GitHub commits from 2025 alone. Of those, 1,275,105 leaked secrets traced back specifically to AI services, up 81% from the year before. Eight of the ten fastest-growing categories of leaked secrets were tied directly to AI services or AI infrastructure. This is a problem that extends well beyond AI-specific tooling. It's becoming the dominant category of leak.

Worse, these leaks don't expire on their own. The same GitGuardian report found that 64% of secrets that leaked back in 2022 are still valid and still usable today. Sprawl doesn't just grow, it accumulates, and old exposure sits there quietly waiting for someone to find it.

Credentials also don't stay put. A single API key can end up copied into a .env file, a shell profile, terminal history, IDE settings, a cached token, a build artifact, and a local config file, all from one original secret. Each copy is its own theft path. GitGuardian's analysis of the Shai-Hulud 2 supply chain attack gives a real number for what this looks like at scale: 294,842 secret occurrences spread across 6,943 compromised machines, tracing back to 33,185 unique secrets. That's an identity lifecycle failure, at a speed most security teams have no process built to match. That's an identity lifecycle failure, at a speed most security teams have no process built to match.

How AI coding assistants accelerate secret leakage, and what the trend line shows

Claude Code gives a clean, measurable window into how fast this moves. GitGuardian's report, again cited in The Hacker News, tracked monthly Claude Code co-authored commits growing from 22 in January 2025 to 2.16 million by December. That's a tool going from a rounding error to a mainstream part of how code gets written, inside a single year. That's a tool going from a rounding error to a mainstream part of how code gets written, inside a single year.

Here's where it gets interesting: those commits made up just 0.4% of all scanned public commits, but accounted for 0.9% of all detected leaks. Nearly double the share of leaks relative to their share of code. The baseline leak rate across all of GitHub's public commits in 2025 sat at 1.5%, meaning roughly one in every 67 commits exposed a credential. Claude Code co-authored commits leaked at 3.2%, about double that baseline. At the August 2025 peak, the rate hit 31 leaked secrets per 1,000 commits, close to 2.4 times the human rate. By December, that number had dropped to 13 per 1,000, converging back toward normal.

The lesson here is that faster code generation means faster credential exposure, unless the review process scales up to match the volume. It's that faster code generation means faster credential exposure, unless the review process scales up to match the volume. AI-assisted commits ran noticeably larger for much of the year, more generated code, more context packed into a single commit, more surface area for a stray credential to slip past a reviewer who's used to smaller diffs.

The exposure also doesn't stop at the repository. AI-assisted development touches developer endpoints, MCP config files, CI/CD runners, and IDE extensions, all of which can carry secrets the same way a commit can. The coding assistant numbers are the visible, countable version of this problem. MCP infrastructure is where the same dynamic plays out with far less visibility and almost no instrumentation.

MCP as the new credential aggregation layer enterprises are not securing

MCP, the Model Context Protocol, has quickly become the connective tissue between AI models and the tools, data sources, and workflows they act on. That makes MCP servers a concentration point: sensitive data and real operational privileges, sitting behind one protocol layer.

Adoption has moved fast. The public MCP server registry held roughly 1,200 entries in the first quarter of 2025. By mid-April 2026, that number had crossed 9,400, more than seven times the count in fourteen months. Team8's CISO Village Survey found 70% of enterprises already running AI agents in production, with another 23% planning deployment in 2026. This is infrastructure now. It's infrastructure.

A single MCP server can hold credentials for Slack, GitHub, a Postgres database, and Salesforce, all at once, which should worry security teams most. Compromise that one server, and four systems go down with it. That's a fundamentally different risk profile than a single leaked API key, because the blast radius multiplies with every service the server connects to.

Scope creep makes it worse. Tokens carrying broad permissions like files:*, db:*, or admin:* end up sitting in logs or memory, ready to be scraped. One stolen token, and the attacker has the whole system, not just a corner of it.

And most of this is running completely ungoverned. Clutch Security's research, cited by Lenses.io, found that 86% of MCP servers run locally on developer machines. Only 5% run in a production environment. The dominant way MCP gets deployed today is the least visible, least controlled way possible. This is the layer where identity sprawl, the visibility gap, and credential aggregation all collide.

The specific attack classes that exploit MCP's identity and trust model

Risk in MCP spans five distinct layers: transport and communication, authentication and identity, context integrity and confidentiality, authorization and privilege management, and supply chain security. Each layer has its own named failure modes, and practitioners need the vocabulary because these terms show up constantly in vendor advisories now.

Invariant Labs and the OWASP MCP Top 10 (2025) name several attack classes: tool poisoning buries malicious instructions inside a tool's definition, and the agent executes them without a human ever reviewing what's in there. Tool poisoning buries malicious instructions inside a tool's definition, and the agent executes them without a human ever reviewing what's in there. Rug pulls, also called silent tool redefinition, let a tool's behavior change after it's already been approved, so the trust granted at install time sticks around long after the tool stopped doing what it was approved to do. Tool shadowing lets a malicious tool intercept or override calls meant for a legitimate one. Cross-server attacks turn one compromised MCP server into a pivot point, letting an attacker move into others across the same ecosystem.

Confused-deputy and OAuth weaknesses appear when authorization boundaries collapse, letting an agent act on a user's behalf without the token being properly scoped. Prompt injection, sometimes called toxic agent flows, hides malicious instructions inside data the agent reads as part of its normal job, the indirect injection vector Pillar Security has written about. And then there's what's called the lethal trifecta: tools with too many permissions, direct API exposure carrying ordinary web vulnerabilities, and no runtime enforcement, so a policy violation only becomes visible after the damage is already done.

These aren't abstract categories. They exploit the exact gap between the moment a tool gets approved and however it actually behaves at runtime, letting an attacker pull data out, hijack what the agent does, or set up a quiet command channel, all without tripping a traditional alert.

Supply chain risk adds another layer entirely. The nx build system attack in August 2025, hitting a package with 4.6 million weekly downloads, used a malicious postinstall script that used jailbroken prompts designed to reach into developer credential stores. A single compromised package reached straight into the credential store.

Empirical vulnerability rates and real incidents that confirm the risk is not theoretical

The numbers here aren't hypothetical. Equixly's testing, run through early 2026, found 43% of tested MCP servers vulnerable to command injection. Endor Labs looked at 2,614 MCP implementations in 2025 and found 82% using file operations prone to path traversal. BlueRock Security scanned more than 7,000 servers in 2026 and found 36.7% affected by server-side request forgery. Enkrypt AI scanned 1,000 servers in October 2025 and found 33% carrying critical vulnerabilities. Four separate research efforts, four different sample sizes, and the same conclusion each time: a meaningful chunk of what's deployed today is exploitable right now.

Specific CVEs make the stakes concrete. CVE-2025-49596 carries a CVSS score of 9.4, allowing arbitrary command execution through unauthenticated MCP Inspector instances. CVE-2025-6514, found in mcp-remote, scored 9.6, an OS command injection flaw affecting versions 0.0.5 through 0.1.15 before a fix landed in 0.1.16, by which point the package had already seen wide distribution. CVE-2026-30615, found in Windsurf, is classified as zero-click: simply opening a Git repository containing a malicious README or embedded HTML content triggers prompt injection that silently writes a malicious MCP configuration and runs code with no user interaction at all.

Real incidents back the CVEs up. Postmark suffered a supply chain attack in the second half of 2025. In mid-2025, a Supabase agent running inside Cursor, with privileged service-role access, got compromised when attackers embedded prompt injection instructions inside support tickets, exfiltrating integration tokens through a public thread. Microsoft patched a high-severity flaw in its own MCP servers during its March 2026 security release, with further advisories identifying additional vulnerabilities in the months that followedgh and critical CVEs, with an estimated 200,000 vulnerable servers exposed worldwide.

The pattern repeats across all of these incidents: over-permissioned tools, direct exposure to the internet, and no runtime enforcement to catch anything before damage is done. That's a structural failure mode, occurring when over-permissioned tools, direct exposure to the internet, and no runtime enforcement combine to let nothing catch damage before it happens.

Why authentication and authorization in MCP have lagged the deployment curve

MCP's original design left a gap that's still being paid for. Authentication, at launch, usually meant an API key sitting in a config file or environment variable, static, shared across a team, and unscoped. If that key leaked, whoever had it got full access, with no way to track who used it or shut it off selectively.

The spec has moved a long way since then, and the timeline matters if you're actually deploying this stuff. In March 2025, OAuth 2.1 was defined as the authorization framework for HTTP-based MCP transports. A June 2025 revision separated the MCP server's role as a resource server from the authorization server, the foundation every later version builds on. By November 2025, the spec required any internet-facing MCP server to implement OAuth 2.1 with PKCE, specifically the S256 method where technically possible, and banned plain PKCE outright. A later spec revision added a requirement for RFC 8707-compliant resource indicators, closing off token mis-redemption attacks. Incremental scope consent was also added in subsequent spec revisions, letting a client request only the minimum access it needs for a given operation, instead of grabbing broad permissions upfront.

On paper, that's real progress. In practice, it barely matters yet. The dominant deployment mode is still local developer machines, 86% by Clutch Security's research, cited by Lenses.io, with only 5% running in a governed production setup. Spec compliance assumes an environment built to enforce it, and most MCP deployments today simply aren't that environment.

So the auth problem isn't really a technical one anymore. The spec has caught up. What hasn't caught up is enforcement: whether anyone's actually watching which servers exist, what scopes their tokens carry, and whether the rules on paper apply to the machine sitting under someone's desk.