Last month, an AI agent running inside Cursor wiped PocketOS's entire production database, including its backups, in roughly nine seconds. The agent found an API token in an unrelated file, originally created for managing custom domains, and used that token to execute the deletion. The backups sat inside the same blast radius as the database the agent was operating against.
Nine months earlier, a Replit AI agent had done the same thing to a SaaStr database during a designated code freeze. It erased records for over a thousand executives and companies, generated 4,000 fake user accounts, and gave the engineer running the experiment inaccurate information about whether recovery was possible.
Two public incidents in nine months, both following the same pattern: a runtime entity holding risky credentials and permissions, operating against systems it should never have reached. Gartner forecasts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents due to governance gaps identified only after production incidents occur. The forecast and the incidents describe the same trajectory.
What both incidents actually were
The Replit agent had write access to production during a code freeze. The PocketOS agent had access to a credential it had no business reading. Both incidents get described as AI safety problems. The mechanism in each case was access control.
Engineering leaders who lived through the worst of microservices governance recognize this immediately. The same failure mode produced production outages and security incidents across every company that scaled microservices without scaling the operating model underneath them: runtime entities accumulating credentials, ownership becoming implicit, dependency graphs no one could map, and the eventual incident that forced a catalog into existence the hard way. Agents are a new class of runtime entity. The operational requirements are nearly identical.
Agents are already in production. It’s time for governance to catch up.
It took the industry most of a decade to build the catalogs and ownership models that tamed microservices. Agents won't give you that long.
Multi-agent orchestration is now a standard vendor offering. At Google I/O 2026, Google shipped Antigravity 2.0 as a multi-agent autonomous coding platform that orchestrates child agents to complete development tasks. A single engineer can stand up a workflow that spawns dozens of agents without filing a ticket.
Spending decisions can now sit inside the agent. Cloudflare and Stripe shipped a protocol that lets agents create cloud accounts, register domains, and deploy to production using OAuth and a tokenized payment credential, with no human dashboard required. An ungoverned agent now has a blast radius that covers compute, infrastructure, and spend.
The deployment ticket is gone. When microservices sprawl happened, a developer still had to file a request to deploy a service, and the resulting ticket produced an audit log even if the catalog failed to capture the service itself. Agents remove that step. If the catalog doesn't produce the audit log, no one in IT learns the workflow exists until the incident report does it for them.
Three moves for the next two quarters
This is the same playbook that solved microservices governance, now pointed at a new class of entity, and platform teams already know how to run it.
Bring agents into the same catalog as services. Name, owner, purpose, scopes attached, credentials referenced, review history. If an entity can call an API, push code, or spend money, it belongs in the system of record. Both public incidents involved agents holding credentials no catalog was tracking. A catalog that covered agents would have flagged the configuration that produced each one.
Require ownership at agent creation. The default operating pattern in most engineering organizations today is implicit ownership: whoever built the agent owns it until they leave. That pattern doesn't survive Gartner's deployment curve. Required ownership enforced at creation, by the same scorecard system that governs services, is the change that scales.
Define and enforce production-readiness for agents. Scoped credentials with rotation policies. Spend caps that page when crossed. Human review for any agent with write access to production. Audit logging the catalog can read. None of this is novel platform work. All of it is the existing service-governance model extended to a new class of entity.
Put it on the roadmap before an incident does
Extending your catalog, ownership model, and scorecards to cover agents is the same platform work your teams already run for services. The work is the same whether it lands on your roadmap or in a post-incident review, so it’s better to start before a forcing-function occurs.
We're hosting a webinar with Tala on production readiness, the same bar you'll want to hold agents to. [Save your seat]
