1.5 Million AI Agents Running Without Oversight: Agent Sprawl Is the New Shadow IT, and Your Engineering Org Probably Has No Inventory

[cto_michelle]

I’ve been in technology leadership for 25 years, and I’ve watched every major “shadow” wave hit enterprise engineering: shadow IT, shadow SaaS, shadow cloud accounts. Each time, the pattern is the same—teams move fast to solve immediate problems, governance catches up 18-24 months later, and the cleanup bill is enormous.

Agent sprawl is that wave right now, and it’s moving faster than anything before it.

The Numbers Should Alarm You

According to Gravitee’s State of AI Agent Security 2026 report, more than 3 million AI agents are now operating within corporations. Only 47.1% are actively monitored or secured. That leaves an estimated 1.5 million agents running without oversight—accessing sensitive data, making decisions, and connecting to critical systems with no audit trail.

Let that sink in: 29% of enterprise agents operate with zero oversight whatsoever. Not minimal oversight. Zero.

And this isn’t a security team problem alone. Gartner’s Predicts 2026 report explicitly warns organizations to “secure AI agents to avoid ungoverned sprawl and abuses.” The average organization now manages 37 deployed agents, and each one is an unmapped access path.

Why Traditional RBAC Won’t Save You

Here’s what keeps me up at night as a CTO: our existing identity and access management infrastructure was designed for human users. Static role-based access control assigns permissions based on job titles and team membership. But AI agents don’t have job titles. They don’t clock out. They operate at machine speed across system boundaries that humans would never cross in a single session.

The industry is starting to recognize this. Microsoft just released their Agent Governance Toolkit—an open-source project addressing all 10 OWASP agentic AI risks with sub-millisecond policy enforcement. Cisco announced a full security reimagining for what they call the “agentic workforce.” Solutions like Ory’s Keto are moving toward relationship-based access control (ReBAC) because static RBAC is fundamentally inadequate for autonomous agents.

But how many of your engineering orgs have actually implemented any of this? Be honest.

The Organizational Blind Spot

What I find most concerning is the organizational dimension. 80% of organizations report risky behaviors from their AI agents—unauthorized data access, unexpected system interactions—but only 21% have mature governance models in place. Only 24.4% of organizations have full visibility into which agents are communicating with each other.

This means your engineering teams are deploying agents that talk to other agents, access production data, and make automated decisions… and three-quarters of you don’t even know which agents are talking to which.

With EU AI Act high-risk enforcement arriving August 2, 2026, regulators aren’t asking for policy documents anymore. They want runtime operational evidence. If you can’t demonstrate governance at the agent layer, you’re looking at real liability.

What I’m Doing About It (And Where I’m Stuck)

At my company, we’ve started treating every AI agent as a first-class identity in our IAM system—same as a human employee or a service account, but with agent-specific constraints:

1. Agent inventory: Every deployed agent must be registered with its purpose, data access scope, and owning team
2. Scoped permissions: Agents get the minimum access needed, reviewed quarterly (not the broad API keys we used to hand out)
3. Runtime monitoring: We’re instrumenting agent-to-agent communication to build an interaction graph
4. Kill switches: Every agent has a human-accessible emergency stop that doesn’t require the deploying team

But I’ll be transparent—we’re maybe 40% of the way there. The biggest challenge isn’t technical. It’s cultural. Engineers resist governance because it feels like friction. Product teams want to ship agent-powered features yesterday. And the new roles we need—orchestration engineers, responsible AI engineers—are roles we’re still figuring out how to hire for and where to place in the org chart.

Questions for This Community

1. Do you have an agent inventory? Can you tell me right now how many AI agents are running in your production environment and what data they access?
2. Who owns agent governance in your org? Is it security? Platform engineering? A new dedicated team? Nobody?
3. How are you handling the RBAC gap? Are you extending existing IAM, or building something agent-native?
4. What’s your EU AI Act readiness for agent deployments specifically?

I suspect most honest answers will be uncomfortable. That’s okay—that’s exactly where productive conversations start.

The cost of getting this wrong is $4.6M per breach on average, and we’re all sitting on unmapped blast radii. I’d rather have the uncomfortable conversation now than the incident retrospective later.

[eng_director_luis]

Michelle, this post hit a nerve. I’m going to be uncomfortably honest here.

To answer your first question: No, I do not have a complete agent inventory. And I run engineering at a Fortune 500 financial services company where regulatory compliance isn’t optional—it’s existential.

Here’s what happened. Over the past 18 months, three separate engineering teams deployed AI agents for different use cases: one for automated code review, one for incident triage, and one for customer data enrichment. Each team used different frameworks. Each team provisioned their own API keys. None of them went through our standard service account provisioning process because—and this is the part that should concern everyone—our standard process doesn’t have an “AI agent” category. It has “human user” and “service account.” That’s it.

By the time my platform team discovered the third agent, it had been running for four months with read access to a customer PII database. Not because anyone was malicious. Because the engineer who deployed it copied an existing service account’s permissions as a template, and that template happened to include PII access.

The Financial Services Angle

In regulated industries, this isn’t just a $4.6M breach cost conversation. It’s a license-to-operate conversation. Our compliance team nearly lost their minds when they learned that autonomous agents were making API calls to systems that fall under SOX controls, and those calls weren’t in any audit log designed for non-human actors.

The gap isn’t just RBAC. It’s the entire audit and attestation infrastructure. SOC 2 Type II audits ask about access controls for personnel. Nobody’s auditing agent access patterns yet, but I guarantee auditors will be asking about this within 12 months.

What We’re Building (Reluctantly)

We’ve started what I’m calling an “Agent Registry”—basically a service catalog but specifically for AI agents. Every agent needs:

• A named human owner (not a team, a person)
• A declared data classification ceiling (what’s the most sensitive data it can touch)
• An expiration date (no indefinite deployments)
• Quarterly access reviews that mirror our human IAM reviews

The pushback from my teams has been significant. One senior engineer told me, “This is just bureaucracy that slows down innovation.” And honestly? He’s partially right. The process adds about 2 days to agent deployment. But I’ll take 2 days of governance over 2 years of undetected PII exposure.

The honest answer to “who owns this” in our org: it’s fallen to platform engineering by default, not because we planned it that way, but because we’re the team that kept finding agents we didn’t know existed.

[maya_builds]

Okay so I’m coming at this from a completely different angle than Michelle and Luis, but I think it actually proves the point even harder.

I lead design systems. My world is component libraries, Figma tokens, and accessibility audits. You’d think agent sprawl wouldn’t be my problem. You’d be wrong.

The Shadow Agent Problem on Feature Teams

In the last quarter alone, I discovered that three of my product teams had independently set up AI agents for design-related tasks:

• One team had a Figma-to-code agent that was pulling our design tokens and generating React components. Cool in theory, except it was using a 6-month-old snapshot of our token system and shipping components with deprecated spacing values.
• Another team had an accessibility checking agent that was running against staging but filing automated Jira tickets directly into our backlog—with no human triage. We had 140 tickets before anyone noticed, half of which were false positives.
• A third team was using an AI agent to generate user research summaries from recorded interviews. The agent had access to unredacted interview recordings that contained participant PII.

Nobody coordinated. Nobody checked. Each team was just… solving their immediate problem.

This Is Shadow IT With Better Marketing

I keep hearing “AI agents” described as if they’re some sophisticated new paradigm. And sure, the tech is different. But the organizational dysfunction is identical to what we saw with shadow IT in 2015. Teams adopt tools to solve local problems, those tools create global inconsistencies, and by the time leadership notices, you’re dealing with a sprawl that’s 10x harder to unwind than it would have been to govern upfront.

The difference this time? These shadow tools don’t just read data—they act on it. That Jira-filing accessibility agent wasn’t just reading our backlog; it was writing to it. That’s a fundamentally different risk profile than someone spinning up an unauthorized Slack workspace.

What I’d Love to See

Michelle mentioned treating agents as first-class identities. I want to extend that idea to the design and product layer:

Agent impact assessments before deployment—not just “what data does this agent access” but “what systems does this agent write to, and who gets notified when it does?”

Because the agents my teams deployed weren’t malicious. They were helpful! They were solving real problems. But helpful + ungoverned = chaos. That’s the lesson from every shadow IT wave, and we keep having to relearn it.

Also—I’ll just say it—the fact that only 24.4% of orgs know which agents are talking to each other is genuinely terrifying. If we don’t know what our agents are doing, we definitely don’t know what our agents are doing wrong.

[product_david]

I want to push back slightly on the framing here—not on the problem, which is very real, but on how we think about the solution.

The Speed vs. Governance Trade-off Is a False Binary

Every governance conversation I’ve been in follows the same arc: security and compliance present the risks, engineering leadership agrees it’s serious, and then we design a process that adds friction. Adoption drops. Teams find workarounds. We’re back to shadow agents within 6 months.

The reason agent sprawl exists isn’t because engineers are reckless. It’s because the value proposition of deploying an agent is immediate and obvious, while the value proposition of governing it is abstract and delayed. Until we solve that incentive mismatch, no amount of registry requirements or quarterly reviews will stick.

What Product Thinking Can Add

I’ve spent my career thinking about adoption and user behavior. Here’s what I’d bring to this conversation:

1. Make governance the path of least resistance, not the checkpoint.

Instead of requiring engineers to fill out an agent registration form before deploying, give them a deployment pipeline that automatically registers, scopes permissions, and instruments monitoring. The governance shouldn’t be a gate—it should be the default infrastructure. Think of it like how container orchestration solved the “servers nobody tracks” problem. We didn’t ask engineers to register their servers. We gave them Kubernetes, and registration became automatic.

2. Measure agent ROI the same way we measure feature ROI.

One reason agents proliferate without oversight is that nobody’s measuring their business impact. If an agent is generating value, great—quantify it, fund it, and govern it properly. If an agent has been running for 90 days and nobody can articulate what business outcome it drives, that agent should be sunset.

At my company we’re piloting “agent product reviews”—quarterly sessions where every deployed agent has to demonstrate its value in business terms, just like any product feature. Three agents got killed in the first review because their owners couldn’t explain what they did. That’s three ungoverned access paths eliminated not through security enforcement, but through product discipline.

3. Agent discovery platforms are a real category now.

I’ve been evaluating tools like Arthur AI’s agent discovery platform and similar offerings that emerged in early 2026. The idea is essentially an asset management layer for AI agents—automatic discovery, classification, and risk scoring. This is the “make it easy” approach rather than the “make it mandatory” approach, and I think it has better odds of actually working.

The EU AI Act Angle

Michelle raised the EU AI Act readiness question. From a product perspective, the August 2026 enforcement date is actually an opportunity, not just a threat. If your governance tooling is ahead of the curve, that’s a competitive moat—especially in fintech, healthtech, and any B2B SaaS selling into European markets.

The companies that figure out agent governance as a product capability (not just a compliance checkbox) will have a meaningful advantage. The rest will be scrambling to retrofit governance onto sprawled agent architectures while their competitors ship with it built in.

Luis, your Agent Registry concept is solid, but I’d push you to think about it less as a compliance artifact and more as a product: who are the users, what’s the adoption metric, and how do you make it so useful that engineers want to register their agents?

[vp_eng_keisha]

This conversation is giving me life because it’s surfacing something I’ve been thinking about for months: agent sprawl isn’t just a technical governance problem—it’s an organizational design problem, and I don’t think most engineering orgs have the structure to solve it.

The Role Gap Is Real

Michelle mentioned orchestration engineers and responsible AI engineers as roles she’s still figuring out how to hire for. I want to dig into this because I think it’s the crux.

At my company (high-growth EdTech, scaling from 25 to 80+ engineers), we had a revealing conversation in our leadership team last month. I asked a simple question: “Who is accountable for the AI agents running in production right now?” The answers were:

• “The team that deployed them” (but no one tracks which team deployed which agent)
• “Security” (but security said they didn’t know most of these agents existed)
• “Platform engineering” (but platform eng said they provide infrastructure, not governance)
• “Probably the CTO” (our CTO’s reaction was… instructive)

The truth is nobody owned it, and the reason nobody owned it is that the role doesn’t cleanly fit into any existing function. It sits at the intersection of security, platform engineering, compliance, and product—which in most orgs means it’s everyone’s second priority and nobody’s first.

New Roles Need Intentional Design

I’ve been researching what companies are doing here, and the emerging pattern I see is a new function I’d call Agent Operations (AgentOps? We love our PortmanteauOps in this industry). The profile looks like:

• Security fluency but not a traditional AppSec background
• Platform engineering skills for building self-service guardrails
• Product sense (David’s point about making governance the path of least resistance)
• Compliance awareness especially for EU AI Act and SOC 2 implications

The problem? This profile doesn’t exist in most talent pipelines. We can’t post a job req for “Agent Governance Lead” and expect a flood of qualified candidates. This is a role we need to grow internally—which means identifying engineers who have the right combination of systems thinking, security awareness, and communication skills, and investing in their development.

The Inclusion Angle

Here’s something I care deeply about: every time a new critical role emerges in tech, the default is to fill it from the same homogeneous pipeline. If we’re creating AgentOps or orchestration engineering as new disciplines, we have an opportunity—and a responsibility—to build diverse teams from day one rather than trying to retrofit inclusion into an already-established function.

I’ve seen this play out with SRE, DevOps, and platform engineering. Each time, the pioneer cohort set cultural norms that proved incredibly sticky. If we let agent governance become another role dominated by a narrow demographic, we’ll be fighting that inertia for a decade.

Practical Step I’d Recommend

For anyone reading this who doesn’t have an agent inventory (which based on the stats is most of us): start with a 2-week discovery sprint. Not a governance framework. Not a policy document. Just an honest inventory:

1. Ask every team lead: “What AI agents is your team running?”
2. Cross-reference with your API gateway logs for non-human traffic patterns
3. Check your cloud IAM for service accounts created in the last 12 months that don’t map to known services
4. Document what you find, who owns it, and what data it touches

You’ll be horrified. And that horror is the best catalyst for organizational change I’ve ever encountered.

Michelle, David, Luis, Maya—thank you for this thread. This is the conversation every engineering leadership team should be having this quarter.