300 agents in 60 people: The ungoverned AI agent sprawl

The agent ratio. Runlayer, a company of 50-60 people, discovered they run over 300 agents every day. That's five agents per employee, most of them unattended. Each agent connects to MCP servers, SaaS tools, and internal data sources, creating an attack surface that traditional security tooling was never designed to cover. The ratio alone should make any engineering leader ask how many automated processes their own teams have already spun up.

The security gap. The talk walks through concrete risks: an agent reading support emails can be prompt-injected into exfiltrating CRM data. An agent that reviews pull requests can be talked into approving a security change after enough back-and-forth. Permission scoping is hard because the same tool may be safe in one context and dangerous in another. Deterministic rules don't cover multi-step attacks that unfold over an entire session.

Monitoring as the only first step. Runlayer's internal response was to deploy an agent gateway, log every tool call, and train classifier models to flag runs that deviate from the agent's defined intent. They map agents by topic and risk, and they use historical call patterns to suggest permission reductions. This is pragmatic, but it's also exactly the product Runlayer sells—the talk is a dressed-up use case for their own platform.

Cost is the twin problem. Beyond security, poorly written MCP servers cause agents to retry endlessly, burning tokens. A non-technical team member 'vibe-coded' an MCP server that ballooned costs because of unhandled formatting errors. Another team switched from a cheap model to a more capable one and saw costs jump 100x in a week. Without monitoring, these costs go unnoticed until the bill arrives.

What's missing from the talk. The classifier models are described but their accuracy and training data are not. There's no A/B comparison of monitored vs. unmonitored loss. The talk assumes teams can afford to build or buy this infrastructure. Smaller teams without a dedicated security engineer are left with a warning but no clear path to action. The evidence is entirely internal and non-replicable.

The implication for leaders. The core signal—that agent proliferation has outstripped governance—is real. The speaker's recommendation to start with monitoring and mapping before buying tools is sound. Teams should set budgets, review agent permissions quarterly, and watch for cost spikes. The hardest part is organizational: no one owns agent security yet, and it sits between engineering, IT, and security teams.