Your AI Agents Don't Have Their Own Identity. That's the Risk No One Is Measuring.

The agent fleet doubled in four months. Control didn't.#

One number should be on every risk committee's agenda right now: the number of AI agents running inside the average enterprise has roughly doubled in four months, and that sits next to a second, less comfortable number — the share of those agents actually being monitored has barely moved. This isn't theoretical. It's a survey of 750 executives and technical leaders, comparing a December baseline against an April measurement in the same year.

The gap isn't lack of interest. 81.7% of organizations plan to deploy significantly more agents over the next twelve months. The problem is that confidence is outpacing actual oversight capability: stated confidence in agent visibility rose nine points in the same window, while real coverage barely moved — and that combination is a classic precursor to a major incident.

This isn't a new security problem. It's identity's third generation.#

Identity management has moved through well-documented generations. First it was built for people: authenticate a human, authorize access to specific resources. Then it extended to software processes through service accounts — non-human identities with static credentials and a fixed permission set. AI agents don't fit either mold. The problem isn't simply that agents are non-human — service accounts already handled that. The problem is that agents have properties service accounts don't: they act on behalf of users with delegated authority, their required permissions vary dynamically by task, they chain actions across many services in a single workflow, and those workflows can last long enough that starting credentials expire before the work finishes.

From "least privilege" to "least agency"#

For decades, cybersecurity relied on a single principle: give every identity only the access it needs. That principle remains essential, but AI agents have exposed its limits — an agent can have exactly the right permissions and still do the wrong thing. An agent with legitimate billing access can issue a technically-authorized refund at the wrong moment, for the wrong amount, with no human approving it in real time. The question isn't only what an agent can touch anymore — it's what it decides to do with that access.

The industry is shifting toward "actions, not access" — from static access control to continuous, real-time identity decisions that govern what entities can do.

The standards haven't agreed with each other yet#

This isn't just a product gap — it's a standards gap. Auth.md, ID-JAG, SPIFFE, AIUC-1, and several IETF RFCs are either not finalized, a work in progress, or less than twelve months old. At the same time, SPIFFE has started to become the de facto standard for non-human identities, yet even Okta — one of the largest identity providers in the market — still doesn't have a full SPIFFE agent identity implementation. If the IAM market leader is still building that piece, it's reasonable to assume most enterprise stacks have the same hole — just not yet measured.

The market is already responding — without consensus yet#

The response hasn't waited. At its Oktane 2026 conference, Okta unveiled its vision of turning its platform into a unified control plane for AI agents, with announcements centered on agent identity, runtime authorization, and agent-to-agent interactions. On the infrastructure side, AWS recommends applying zero-trust principles to agentic identities: every agent needs its own identity, not a copy of a human user's, and should receive scoped, temporary credentials rather than persistent access. And outside the major vendors, a cybersecurity startup called NewCore emerged from stealth with $66 million specifically to solve how to authenticate and govern agents at scale, at a moment when McKinsey already reports 25,000 AI agents working alongside its 60,000 employees. Three different approaches, the same symptom: agent identity has become the new competitive frontier of IAM.

What to do before scaling agents, not after#

• Inventory first: you can't govern what you can't see — before adding agent number 50, know how many already exist, where they came from, and who approved them.
• Delegation, not impersonation: the recommended design pattern is delegation to a uniquely identified agent, not impersonation of the user — so a compromised credential exposes the agent's scope, not the human's full authorization.
• Centralized registry and clear ownership: establish an agent identity platform that treats every internal and third-party agent as a distinct identity with clearly defined ownership and access rights.
• Temporary access, not static credentials: agents should receive temporary access that is revoked when the task is complete, rather than relying on long-lived secrets.
• Traceability to a responsible human: this ensures every autonomous action can be attributed to a responsible human owner and maintains the auditability governance and compliance require.

What this means for your business#

If your company already has agents in production — support assistants, internal automations, coding agents — the question that defines your real risk isn't how many you have. It's whether each one has an owner, a defined scope, and a way to be revoked in seconds. We've already covered how Microsoft treats AI agents as an insider threat requiring governance and the approval problem once AI is already writing your infrastructure. Agent identity is the layer connecting both problems: without it, neither detection nor approval has anyone to attribute the action to. Solving this alongside deployment — not after the first incident — is exactly the kind of work that lives inside Grow: agent systems that don't just execute, but stay governed, logged, and owned by a human from day one.