- Agents now arrive from every direction: embedded in SaaS products, built by platform teams, assembled by citizen developers, spun up by engineers and running always-on for individuals. Agent sprawl is the result, and identity and privilege abuse is one of the top risks in OWASP's agentic security list.
- Every agent needs its own identity, never a borrowed user session or a shared service account, and an agent acting for a person needs delegated authority that names both, is scoped to the intersection of their rights, expires quickly and is valid only at the intended tool.
- An agent control plane provides the registry, policy, observability and lifecycle that make a fleet of agents governable. The major identity and cloud platforms shipped control-plane and agent-identity services in 2026; the cross-domain standards are still drafts, so build on OAuth, OpenID Connect and workload identity now and keep identity in the IdP you already run.
The agent sprawl problem
Ask a large enterprise how many AI agents can take actions in its production systems and the honest answer is usually that nobody knows. Agents arrive through at least five doors. SaaS vendors embed them in products the company already licenses. Platform teams build them on agent frameworks. Business users assemble them in low-code builders. Engineers start coding and research agents from their terminals. And individuals connect personal always-on agents to their mailboxes and calendars. Each door has its own console, its own credentials and its own idea of an audit log.
Agent sprawl is the accumulation of agents faster than anyone can inventory them, and it repeats two earlier enterprise mistakes at once: the shadow SaaS of the 2010s, and the service accounts that outlive the projects that created them. The consequences are concrete. Over-privileged agents widen the blast radius of any compromise. Agents running on borrowed credentials make attribution impossible. Agents nobody owns are never reviewed or retired. The OWASP Top 10 for Agentic Applications, published in December 2025, puts identity and privilege abuse in its top three risks and lists rogue agents among the ten.
A simple test reveals where an organization stands: can you list every agent that can act in production, who owns it, what it can reach, and how to switch it off? Most cannot answer the first question, which makes the other three moot.
Agents as first-class identities
The foundation is that every agent is a principal in its own right, with an identity that is unique, attributable, typed as an agent rather than a human or a generic workload, linked to an accountable owner, linked to its definition (which model, which tools, which version), free of long-lived secrets wherever possible, and revocable from one place. The identity and tenancy deep-dive makes the case for treating agents as first-class principals; the patterns below are how that plays out in practice.
| Identity pattern | How it works | Verdict |
|---|---|---|
| Borrowed user session | The agent drives the human's cookies or tokens | Avoid: unbounded authority, no attribution |
| Shared service account | One credential serves many agents | Avoid: confused deputy, no attribution, painful rotation |
| Per-agent identity, own grants | The agent is a principal with permissions of its own | Right for autonomous back-office agents |
| Per-agent identity plus delegation | The agent acts for a user with a token that names both | Right for user-facing agents |
| Workload-attested identity | The runtime proves what it is before receiving any token | Strong foundation underneath either of the above |
Credential-free identities are the target state. Rather than handing an agent a static secret, the platform attests the workload it runs on and issues short-lived tokens on demand, the model behind workload identity schemes such as SPIFFE. Microsoft's agent identity service, generally available since April 2026, follows this shape: an agent identity is a specialized principal with no credentials of its own that obtains short-lived tokens through the blueprint it was created from, and policies can target an individual agent, a whole blueprint or agents carrying particular attributes.
Delegated authority: acting on someone's behalf
The hard case is the agent that acts for a person: the expense agent filing a report for Alice, the support agent issuing a refund for a customer service representative. Here identity alone is not enough. The authority the agent exercises must be derived from the person's, bounded by the agent's own limits, and visible as delegation in every log.
USER alice consent and scope
| signs in recorded
v
AGENT expense-agent (owner: finance-ops)
| token exchange: subject = alice, actor = expense-agent
| scope = alice's rights AND agent's allowed scope
v
GATEWAY policy check | rate limit | audit log
| short-lived token, bound to one audience
v
TOOL ERP: create_expense_report
|
audit: "expense-agent acting for alice created ER-1042"
Five properties define good delegation. The token names both the subject, the person, and the actor, the agent; OAuth 2.0 Token Exchange (RFC 8693) expresses exactly this with its actor claim. The scope is the intersection of what the person may do and what the agent is allowed to do, never the union. Tokens are short-lived and bound to a single audience, so a token leaked from one tool is useless at another. Proof-of-possession binds the token to the agent's key where the stack supports it. And consent is recorded, so the person can see and revoke what each agent may do in their name.
One hop is a solved problem; chains are not. When an agent delegates to a sub-agent, which calls a tool through an MCP server owned by another team, the standards thin out quickly. OAuth handles a single delegation well but has no settled answer for multi-hop chains, asynchronous flows that outlive a user's session, or mapping coarse OAuth scopes onto agent capabilities. Until the standards mature, keep chains short, have the gateway mint a fresh, narrower token at each hop rather than passing one down the chain, and never hand a person's broad token to a sub-agent. The MCP deep-dive covers the protocol's own OAuth-based authorization, which governs the client-to-server hop and nothing behind it.
What an agent control plane does
Identity answers who an agent is. A control plane answers everything else an enterprise needs to run a fleet of them. It has five jobs:
- Registry. One inventory of every agent, including those embedded in third-party products: owner, purpose, model, tools, data reached, risk tier and status.
- Policy. Which tools, data classes, spend levels and degrees of autonomy each agent or class of agents may use, enforced at runtime rather than written in a document.
- Observability. Traces of what each agent did, on whose behalf, at what cost, joined to the identity that did it.
- Security. Detection of anomalous behavior, quarantine of a misbehaving agent, and a kill switch that works across platforms.
- Lifecycle. Approval at creation, periodic attestation of access, re-review on material change, and clean decommissioning.
The control plane decides; enforcement points carry out its decisions. The model gateway sees every inference call, an MCP gateway sees every tool call, and the identity provider issues every token. A control plane that is not wired into those three choke points is a spreadsheet with a dashboard, which is how most first attempts start and should not be how they stay.
Platforms and standards in 2026
The platforms moved first. Microsoft made Agent 365 generally available in May 2026 as a control plane for observing, governing and securing agents, with a registry that can synchronize agents running outside its own platforms, alongside the agent identity service mentioned above. AWS offers an agent identity service that lets agents reach its resources and third-party tools either as themselves or on behalf of consenting users, federating with the major identity providers. Okta announced runtime enforcement for agent traffic through a gateway in September 2026. Application platforms such as CRM and IT-service vendors govern the agents that run inside their own estates. Each is useful; none yet sees everything.
The cross-domain standards are earlier. In February 2026 NIST's National Cybersecurity Center of Excellence published a concept paper assessing existing standards, among them OAuth 2.0 and 2.1, OpenID Connect, SPIFFE and SCIM, for agents as a distinct class of non-human identity. In March 2026 an IETF Internet-Draft proposed composing workload identity, SPIFFE and OAuth into a unified agent identity management model. Community proposals extend OpenID Connect with agent-specific claims, and the agent interoperability protocols carry their own pieces, such as signed Agent Cards in A2A. Treat all of this as assess: watch it, and do not wait for it.
The practical position follows. Build on the standards that are stable today: OAuth 2.1 with token exchange for delegation, OpenID Connect for federation, workload identity for runtime attestation, and SCIM for provisioning. Prefer platforms that expose agent identities and audit data through those standards rather than proprietary consoles, because a multi-vendor agent estate will need one view across all of them.
The agent lifecycle
Identity teams already run a lifecycle for people, usually called joiner, mover, leaver. Agents need the same one, compressed and automated. At creation, an agent is registered with an owner, a purpose and a risk tier, and approved according to that tier. In operation, it holds least-privilege access, its permissions are attested periodically by its owner, and its behavior is monitored against its declared purpose. On material change, such as a new tool, a new data source, a new model or a new autonomy level, it is re-reviewed, because a change of model can change behavior as much as a change of code. At retirement, its credentials are revoked, it is removed from every registry and gateway, and its logs are archived for the retention period the use case requires.
Incidents need a fast path through the same machinery. When an agent misbehaves or a component it depends on is compromised, the control plane quarantines it, revokes its tokens and propagates the revocation to every system that trusts them, which is what continuous access evaluation and shared-signals mechanisms in modern identity stacks are for. The long-running agents deep-dive covers the run-level controls, such as budgets and kill switches, that complement fleet-level revocation.
The architect view
Agents are the fastest-growing population of credentialed actors in the enterprise, and the identity and governance machinery built for people and services extends to them more naturally than most teams assume. What it needs is a decision to apply that machinery, made before sprawl makes the decision for you.
Four commitments carry most of the value. Build one inventory of every agent that can act, starting with a discovery sweep across SaaS products, low-code builders and cloud accounts. Give every agent its own identity in the enterprise identity provider, with no shared accounts and no borrowed sessions. Route delegation through token exchange at a gateway, with short-lived, audience-bound tokens scoped to the intersection of person and agent. And run a lifecycle with named owners, periodic attestation, re-review on change and clean retirement.
The standards for cross-organization agent identity will take another year or two to settle. The work that matters most does not depend on them: knowing which agents exist, who answers for each one, and how to switch any of them off.