Agent Sprawl Is an Identity Problem, Not a Dashboard Problem

Google published its second annual State of AI Infrastructure report this week, and the headline number is the one every cloud vendor wants you to see: 83% of organizations say they need to upgrade their infrastructure to run agentic AI in production. That’s the number that gets you to click. It’s also, I think, the least interesting number in the whole report.

The numbers that actually matter#

Read a bit further and the numbers that actually matter are these. 79% of tech leaders say security, governance and MLOps are their top challenge to scaling inference. 78% now buy their gen AI stack straight from their primary cloud provider, up 30 points from last year. Those two facts sitting next to each other tell you what’s really going on. Companies aren’t struggling to find enough silicon. They’re struggling to know what their agents are doing, and they’re responding by handing the problem to whoever sold them the compute.

I get why. If you’ve got a few hundred agents reading email, hitting internal APIs and writing to databases, and no single place that tells you what any of them can touch, buying a managed control plane feels like the fast way out. Google’s answer is something called Agent Gateway, a place to see what agents are doing, set read and write scopes, and require a human sign off before anything risky happens. IBM and half a dozen identity vendors are pitching some version of the same idea this year, under names like agent sprawl or agentic identity crisis.

Watching a black box isn’t the same as shrinking it#

Here’s my problem with most of these pitches. They treat the agent as a thing you watch from the outside, a black box you point a dashboard at. That’s the same instinct that gives you a NOC full of alerts nobody reads. What you actually want is for the agent to be unable to do the dangerous thing, not just visible while it does it.

That’s a scoping problem, not a monitoring problem. It’s the same argument I made about running agent generated code in a sandboxed microVM instead of trusting a container with the run of the host: the interesting question is never what the agent decided to do, it’s what it was physically capable of doing when it decided to do it. A governance dashboard that logs an agent deleting a production table isn’t meaningfully better than no dashboard at all. The credential should have been scoped so that table was never reachable in the first place.

A unified data layer raises the stakes#

The report also talks about organizations moving to a unified data layer, so agents can query across silos without custom pipelines. Read charitably, that’s fine, agents do need real data to be useful. Read less charitably, it’s exactly the setup that makes scoping matter more, not less. The easier you make it for an agent to reach everything, the more that agent’s permission boundary is doing the actual security work. A dashboard sitting on top of a wide open credential is decoration.

The takeaway#

None of this means the compute story is fake. Training and serving agents at scale genuinely looks different from running a chatbot, and the report’s numbers on egress costs and idle specialized hardware are real line items I’ve seen teams get burned by. But compute is the part every vendor already knows how to sell you. The part that decides whether your agents are safe to run in production is whether their permissions were built to expand as they earn trust, or whether everything launched with god mode and a monitoring tool bolted on after.

If you’re rolling out agents this year, the infrastructure question worth asking isn’t whether you have enough TPUs. It’s whether you could hand a stranger the credentials your agent is running with right now, and still sleep fine.

I’m a platform/SRE engineer writing about making agentic AI reliable in production. If you’re standing up agents against systems you care about and want a second pair of eyes on the permission boundary before the dashboard, get in touch.