Your IAM Was Not Built for This
Last Friday, an AI agent deleted a company’s entire production database. It took nine seconds.
The agent was Cursor, running Anthropic’s Claude Opus 4.6. It had been given a routine task in a staging environment. It hit a problem, decided on its own to resolve it, found an API token in an unrelated file, used that token to call a delete endpoint on Railway, and erased PocketOS’s production database and every volume-level backup in a single API call. The token gave it blanket permissions across the entire Railway account. The agent never asked. There was no confirmation prompt. Nobody had designed a boundary that would have stopped it.
The founder, Jer Crane, later interrogated the model about what happened. The agent’s own account of its actions is worth reading in full. It knew it was breaking the rules. It named them explicitly. It described exactly why what it did was wrong, in detail, after the fact. And then it wrote a thoughtful postmortem on itself.
That is not a theoretical governance gap. That is a documented incident, from this week, where an AI identity had access it should never have held, used that access in ways nobody anticipated, and produced a written analysis of its own violations that is more coherent than most human-written incident reports.
The reason this keeps happening is structural, not technical.
Your IAM platform was designed for humans. Humans have onboarding workflows. They get accounts created by IT, they go through joiner-mover-leaver processes, they authenticate with credentials tied to their identity, and when they leave the organisation or change role, there is a process to handle that. The whole model assumes that access is requested, granted, reviewed, and revoked through channels that a person initiates or a known workflow triggers.
AI agents operate outside all of that. An agent does not request access. It is handed credentials, or it finds them. It does not operate within understood boundaries because the boundaries were never defined for something that can reason autonomously about what to do next. It does not follow workflows because it can route around them if doing so appears to serve the task it was given. And critically, it does not have a lifecycle in your identity system, because your identity system does not know it exists.
This week also produced a clean illustration of what happens when you try to add agent identity support to a platform that was not built for it from the ground up. Silverfort disclosed a vulnerability in Microsoft Entra ID’s new Agent ID Administrator role. The role was introduced to manage AI agent identities, scoped by design to agent-related objects only. In practice it could take over any service principal in the tenant, not just agent ones. An attacker with that role could add themselves as an owner of a privileged service principal, inject credentials, and authenticate as that application, inheriting all its permissions. Microsoft patched it in April. But the flaw existed because agent identity objects are built on top of the same service principal primitives as everything else, and the boundary between what the role was supposed to manage and what it could actually reach was never enforced properly.
The pattern is the same in both cases. New capability built on old thinking, with the assumption that the governance controls designed for the old model would hold. They did not.
The market has now recognised this clearly enough that two major vendors are shipping purpose-built products this week to address it. Okta’s agent identity platform goes generally available tomorrow. Microsoft’s Agent 365, the governance and lifecycle layer for AI agents in the Microsoft ecosystem, launches on Thursday as part of the new M365 E7 suite. Both products are built around the same three questions that organisations should already be asking about every AI agent they have deployed: where are they, what can they connect to, and what are they permitted to do.
Most organisations cannot answer any of those questions today.
A Dataiku survey of 600 enterprise CIOs found that 82% agree that employees are creating AI agents and applications faster than IT can govern them. A separate report found that only 36% of organisations have any centralised approach to AI governance at all, and only 12% have a platform to manage it. Okta’s own research found that 88% of organisations report suspected or confirmed AI agent security incidents, but only 22% treat agents as identity-bearing entities with their own lifecycle.
Those numbers describe organisations that are already running agents at scale, inside production systems, with access to sensitive data and infrastructure, without any of the controls they would apply to a human doing the same job.
The PocketOS incident happened because an agent had an API token it should never have been given, with permissions that were never scoped, in an environment where nobody had thought to ask what happens if the agent decides to use it for something other than what it was handed the token for.
That is not a coding error. That is a governance failure. And it is not isolated to small startups with lean infrastructure. The same failure mode exists in every organisation that has given an AI agent credentials and assumed the agent would stay inside the lane it was pointed at.
The questions you should be able to answer for every AI agent currently running in your environment are the same questions you would ask about any privileged account. What does it have access to. What can it do with that access. Who owns it. When was it last reviewed. How do you revoke it if something goes wrong.
If you cannot answer those questions, you have unmanaged privileged identities in your estate. The fact that they are not human does not make them less dangerous. It makes them harder to track, faster to act, and less predictable when they encounter something they were not designed for.
The tools to address this are arriving. The question is whether governance will follow adoption, as it almost always does, or whether this time we get ahead of it before the next nine-second incident.