Skip to content

Why Agent Identity

"Agent identity management" sounds like next year's problem. Two classes of public incident from 2025 say it is this year's.

Incidents: the price tag is already real

One AI agent's token cut through 700+ companies. In August 2025, attackers stole OAuth tokens held by Salesloft Drift, an AI chat agent integration, then swept the Salesforce environments of more than 700 customer companies and bulk-exported data. The victim list includes Cloudflare, Google, Palo Alto Networks, and Zscaler — companies whose business is security. FINRA published a compliance alert specifically for it (incident recap, FINRA alert, CSA analysis).

Why was the blast radius that large? Public post-mortems point at the same profile: a broadly scoped, long-lived, unowned, hard-to-invalidate integration token — one that represented not a specific person doing a specific thing, but "everything this integration can do." Incidents like this have compound causes (third-party supply chain, over-permissioning, credential lifecycle management), and the identity layer is not the only variable. But it is the layer that decides how far one leak spreads.

The other class has no attacker at all. 2025 also produced public cases of AI coding agents deleting production data while executing tasks autonomously (media-reported, relayed through industry analysis: Descope industry analysis; for details, defer to the original reporting). Its value is showing the other direction: even with nobody attacking you, permissions granted too broadly are an incident source on their own. An agent will spend every bit of permission you give it, including the part you assumed it would never touch.

One external theft, one internal mistake, both pointing at the same gap: the permissions in an agent's hands are not minimal, not easy to take back, and not traceable to a person.

Numbers: not an anecdote, a trend

DataSource
By 2028, 25% of enterprise data breaches will trace back to AI agent abuseGartner
By 2028, 80% of unauthorized agent transactions will come from internal policy violations, not external attacksGartner
By the end of 2026, 40% of enterprise applications will embed task-specific agentsGartner
Non-human identities already outnumber human identities 45:1 (144:1 in cloud-native environments)Industry survey aggregate
79% of IT and security practitioners consider themselves ill-equipped to defend against attacks on non-human identities; only 15% are confidentCSA × Oasis joint survey
78% of organizations have no written policy for creating or deleting AI identities; 51% cannot name the person responsible for a given identityCSA non-human identity governance white paper

About these sources

Linked figures can be traced directly. The rows credited to Gartner and to "industry survey aggregate" are relayed from industry sources (analyst reports require licensed access); when citing them, prefer the original report from the corresponding organization.

The second row is worth reading twice: most unauthorized agent behavior won't come from hackers — it will come from someone on your own team over-granting permissions to save time. That decides where your defenses belong. Not only blocking external intrusion, but first taking control of who can delegate what to whom.

Frameworks: standards bodies already list it as a risk

  • OWASP lists ASI03 "Agent identity and privilege abuse" as one of the ten risks in Agentic Applications Top 10 (2026): most agent systems have no governable identity and run on inherited context and shared credentials, which creates an attribution gap and can be used for privilege escalation, impersonation, and authorization bypass (OWASP Agentic Security Initiative).
  • OpenID Foundation offers the most neutral framing to date in its Identity Management for Agentic AI white paper: today's OAuth/OIDC is enough to protect simple agents, but the autonomy inflection point is approaching fast, and agents should become first-class citizens of the identity system (white paper).

"Enough for today, inflection point coming" is exactly why you start now: the identity layer is infrastructure that has to grow alongside your agent count. Retrofitting it after the scale arrives puts cost and risk in a different league.

Four questions you need to be able to answer

Security review, internal audit, regulatory inquiry — the phrasing varies, but these four always show up. They are also the spine of this documentation:

  1. How many agents do I have, and who is responsible for each? → Registration and governance: the registry, approvals, responsible people (Agent identity model, Governing an agent fleet)
  2. Whose identity is each agent acting under right now, and on whose authorization? → Explicit delegation: Delegate Tokens and consent (Delegate Token and attenuation, Consent and approval)
  3. What can they access, and what can't they? → Access control: attenuated intersections and resource-side validation (Delegate Token and attenuation, Protect your APIs)
  4. When something goes wrong, how do I pull permissions immediately, and how do I trace it back to a person? → Revocation and audit (Revocation and emergency response, Audit and accountability chain)

Whichever of these four you can't answer is exactly where your gap is. The next page walks through GenAuth's matching capabilities in the same order, along with how far each one has shipped.

Next steps