Agents Aren't Users: The Identity Crisis Behind 88% of Enterprise AI Incidents

In February 2026, Gravitee published survey data from 900+ executives showing that 88% of organizations had a confirmed or suspected AI agent security incident in the last year (opens in new tab), while only 21.9% of teams treat AI agents as identity-bearing entities with distinct security principals. 45.6% still rely on shared API keys for agent-to-agent authentication. Over half of all agents run with no security oversight or logging at all.

The story is not that prompt injection is winning. It is that most of us wired agents into production using two patterns that were never going to hold: a human user's credentials ("run as Jane") or a service account scoped for a 2018 batch job. When something goes wrong, the incident report ends the same way — the agent had permission to do what it did, nobody could explain why, and nobody could turn it off cleanly.

What follows is the identity model we default to, why the common alternatives are structurally broken, and a concrete pattern — OIDC workload identity, short-lived JWTs, narrow per-agent policies, a central event log — that lets you kill a misbehaving agent in under a minute without rotating every secret in your estate.

The incident is almost never what the press release says

Read enough post-mortems and a shape emerges. The press release says "prompt injection led to data exfiltration." The actual report says: an agent was given a personal access token belonging to a senior engineer, the token inherited org-admin on a dozen repos, a tool call leaked data through an unconsidered path, and rotating the shared token broke production for six hours.

The OWASP Top 10 for Agentic Applications 2026 (opens in new tab) names this directly: ASI03 is "Identity and Privilege Abuse" — exploiting delegated trust, inherited credentials, or role chains. Microsoft's writeup on addressing these risks (opens in new tab) emphasizes the same pattern. Prompt injection is sometimes the trigger. The blast radius is always the identity model.

"Run as Jane" is a liability, not a design

Giving an agent a human's credentials is the quickest path past corporate SSO. It is also the choice that ages worst, for three disqualifying reasons.

Revocation is a career-limiting decision. When "Jane's agent" misbehaves at 2am, your only lever is Jane's account. Disabling her session kills the agent — but also her VPN, laptop sync, calendar, and every other automation under her identity. On-call engineers refuse to pull the lever until a senior approves it, and that lag is the entire window the agent keeps burning calls.

Audit collapses into a single actor. Every log line looks like Jane did it. When compliance asks who exported the customer list, the answer is Jane until you forensically reconstruct which events were her and which were the agent.

Scope inflation is inevitable. Jane has the scopes she needs to do her job, which for any senior operator is most of them. Her agent inherits all of it — a latent attack surface that grows quietly as Jane picks up new responsibilities.

"Run as Jane" is fine for a five-minute prototype. It is a shortcut that sits in your codebase for eighteen months until a breach forces you to rip it out.

Generic service accounts fail the other way

The next most common pattern is a shared service account — ai-agent@company.com, ml-bot-prod — with a broad token every agent uses. This is what 45.6% of Gravitee respondents are doing now. It fixes the "Jane gets fired" problem and creates four worse ones.

Per-agent attribution is gone by construction. Every log line says ml-bot-prod. When one of five agents misbehaves, you rotate the shared credential and break the other four.

The credential is long-lived and widely distributed. Shared keys end up in CI secrets, .env files, Slack DMs, and old Notion pages. The June 2026 exposure of 16 billion credentials weaponized to access corporate data lakes and AI agent systems (opens in new tab) landed on estates where this was standard.

Scope is sized for the largest use case. If any agent needs CRM write, all of them get it. Least privilege collapses to the union of every caller's needs.

Nobody owns it. Human accounts get re-certified quarterly. ml-bot-prod has nobody. Non-human identities now outnumber human identities by roughly 50 to 1 on enterprise networks (opens in new tab), most on long-lived tokens traditional tooling never mapped.

What an agent identity actually needs

Strip away the vendor pitches and the requirements are narrow. Most teams we work with are missing three or four of these six.

A unique, non-reusable identifier. One per agent instance, not per agent type. Ten summarizer workers means ten IDs. This is what makes attribution possible and revocation surgical rather than nuclear.
A short-lived credential. Minutes to an hour, not months. SPIFFE's SVIDs default to 1-hour TTLs with automatic renewal at 50% of validity (opens in new tab). A 1-hour compromised credential has a 60-minute blast window; a 1-year credential has 8,760 hours.
A narrow, explicit scope. Not "read-write on CRM" — "read contacts where owner_id = <initiating user>, write notes on contacts it has read, no opportunities or billing." If this sounds tedious, good. It is tedious on purpose.
Attribution back to the initiating human. Autonomous agents still act in response to a human trigger. The token needs to carry that lineage. RFC 8693's act claim is the standard construct: the token is for the user, the actor is the agent, and claims nest to express chains. Christian Posta's breakdown of on-behalf-of for AI agents (opens in new tab) is the clearest explanation we have found.
An append-only audit trail. Every tool call, every scope assertion, with agent ID, initiating human, timestamp, and outcome — on infrastructure agents cannot redact. Kiteworks notes that 33% of organizations lack AI audit trails entirely and 61% run fragmented infrastructure that cannot produce actionable evidence (opens in new tab). The audit-trail gap is the strongest predictor of governance failure.
One-click, one-agent revocation. Name a single agent by ID and invalidate every credential it holds without touching anything else. If your answer involves rotating a shared secret, you have the nuclear option, not revocation.

A concrete pattern that works

The model we default to has three moving parts and one event bus, assuming you already have an OIDC IdP (Keycloak, Auth0, Entra ID, Ory) and a policy engine (OPA, Cedar, or your platform's equivalent).

OIDC-issued workload identity per agent instance. When an agent starts, it presents something your infrastructure can attest to — a Kubernetes service account JWT, cloud instance metadata, a SPIFFE SVID — and exchanges it for a short-lived OIDC token bound to a specific agent ID like agent:summarizer:prod:7a2c91. The IdP refuses tokens for IDs not in an allowlist.

Short-lived JWTs scoped per interaction. When the agent acts on behalf of a user, it performs RFC 8693 token exchange (opens in new tab), submitting both its token and the user's. The resulting access token has an act claim naming the agent, a sub naming the user, an aud restricted to one downstream API, and scopes narrowed to the intersection of user and agent permissions. TTL: five to fifteen minutes.

Per-agent policies enforced at the resource. The policy engine holds rules like "agent agent:summarizer:* may read emails where act.sub matches the mailbox owner; may not send; may not delete." Declarative, version-controlled, reviewed in pull requests. Changing a policy does not require a deploy.

An event bus that logs every decision. Every token exchange, policy evaluation, and tool call gets appended to an immutable stream feeding your SIEM, your analytics, and a kill-switch service. You can answer "what did agent X do today" with one query.

This is not revolutionary. SPIFFE/SPIRE gives you workload identity. OAuth 2.1 plus RFC 8693 gives you delegation. OPA or Cedar gives you policy. What is missing in most implementations is the discipline to wire them together for agents specifically.

The revocation fire drill

Every team we work with gets the same exercise on day one: name a single agent, kill it, verify it's dead. Stopwatch on. Target: under 60 seconds. Most teams take six minutes to four hours on the first attempt — variance is almost entirely about credential structure.

A working drill: operator opens the admin console, searches the agent ID, clicks revoke. The IdP marks the ID disabled, refuses further exchanges, and publishes a revocation event. Downstream APIs subscribed to the stream deny in-flight tokens. Within 15 minutes maximum, the agent has no working credential anywhere; a policy-engine deny rule cuts that to seconds.

The shared-service-account version: rotate the shared key, propagate to a secrets manager, redeploy four agents, a cron job, and CI. Legitimate systems go down. The rogue agent, if it cached the old credential, keeps working until next fetch.

Reporting on agent governance (opens in new tab) notes that most organizations can monitor their agents but cannot stop them. Containment, not detection, is the gap.

Scope inflation is the second silent killer

Revocation answers "can we stop an agent misbehaving today." It does not answer the slower failure: an agent whose scope grew for two years while nobody looked. An assistant that started with "read calendar, suggest times" ends up with "read email, read CRM, write CRM, trigger webhooks, act on behalf of any user." Each step was justified. Nobody reviewed the whole.

The countermeasures are boring and effective.

Review scopes on a schedule. Quarterly. Compare what the policy grants to what the agent actually used in 90 days. Unused scopes get removed; if removal breaks something, you learn which code path depended on a scope nobody could justify.

Alert on scope widenings, not just uses. Your IdP emits an event when an agent's policy adds a scope. That event goes to a human, not a log. Production widenings outside change windows get investigated.

Prefer per-user scope narrowing over role-wide scope. "Read emails of the user who initiated this task" is bounded; "read emails" is a liability. The narrowing sits in the token exchange, not in application logic.

Treat "can create agents" as privileged. Gravitee notes that 25.5% of deployed agents can create and task additional agents (opens in new tab). That capability compounds scope creep exponentially and belongs behind explicit approval.

Where the standards are going

In January 2026, US NIST CAISI published a Federal Register RFI on security considerations for AI agents (opens in new tab), with comments due March 9, 2026. Responses asked NIST to extend SP 800-218 (SSDF) (opens in new tab) and SP 800-160 to cover agentic AI across the full lifecycle. Expect formal guidance through 2026 and early 2027.

For DACH teams, BaFin and BSI guidance tends to align with NIST patterns six to twelve months later. Build the identity model above now and you are ahead of where compliance lands. Stay on "run as Jane" and you will be scrambling.

The short version

Treat every agent as an identity-bearing principal: unique ID, short-lived token, narrow scope, clear attribution to the initiating human, immutable audit trail, single revocation path. Run a revocation fire drill quarterly. Review scopes quarterly. Never let an agent share credentials with a human user or another agent.

The patterns — SPIFFE workload identity, OAuth 2.1 token exchange with RFC 8693, policy engines, event-sourced audit — have been production-grade for years. What is new is applying them deliberately to agents, rather than inheriting whatever identity was lying around. The 88% incident rate is the symptom of skipping that step.

Agents Aren't Users: The Identity Crisis Behind 88% of Enterprise AI Incidents

The incident is almost never what the press release says

"Run as Jane" is a liability, not a design

Generic service accounts fail the other way

What an agent identity actually needs

A concrete pattern that works

The revocation fire drill

Scope inflation is the second silent killer

Where the standards are going

The short version

Further reading

A random post, once a week.

Related posts

Running a Product on Cloudflare Edge: What We Gained, What We Gave Up

The 35% Flip: Why Teams Are Replacing SaaS With Custom Builds

Comprehension Debt Is the Real AI Tax