Identity Is the Real Control Plane for Agents

Most agent teams still talk about control as if it lives in orchestration. They point to the graph, the planner, the memory layer, the tool router. That is where the system decides what happens next.

But production control is not just sequence. It is legitimacy.

Who is the agent allowed to act as? Which permissions is it using right now? Did a user approve this action, or did the system quietly inherit authority from a broad credential? Which tenant does this run belong to? If the session that authorized the work expires halfway through, does the workflow pause safely, ask for renewed authority, or stop before it crosses from automation into impersonation?

Those are not edge cases. They are the control surface.

That is why identity is the real control plane for agents.

Orchestration can choose the next step. Identity decides whether the step is legitimate.

Where production agents actually break

Agent systems do not usually become dangerous because the planner chose the wrong tool once. They become dangerous because the system keeps acting after the authority behind the action becomes unclear.

A few failure modes show up fast once agents move from demo loops into background work.

1. The session expires, but the workflow keeps going

OAuth was built around limited, scoped access instead of sharing a user's raw credentials. That model works well for ordinary applications. It becomes an operational problem when an agent run outlives the authorization context that started it.

A human might approve a tool action at 9:00 AM. The agent might still be retrying steps at 9:45. If the run loses the session or the delegated token expires mid-flight, the system has to decide whether to pause, request re-authentication, request re-consent, or fail closed. Many teams do not make that decision explicitly. They discover it only after the run slips into a half-broken state and operators can no longer tell whether the remaining work is still legitimate.

That is not only an auth problem. It is a control failure.

2. Delegation quietly turns into broad impersonation

OAuth exists partly to avoid giving third-party systems a user's raw credentials and unlimited access. In agent systems, teams often recreate that original problem in a new form: they give the agent one powerful shared credential and call it infrastructure.

The result is a system that can technically complete work but cannot answer the question operators most need after something goes wrong: on whose authority did this action happen?

That question matters even more in long-running systems. Token-exchange standards explicitly distinguish between subject and actor because delegation and impersonation are not the same thing. An agent acting on behalf of a user should not be treated like a generic backend process with permanent power. If the system collapses those identities into one broad service account, operators lose the chain of authority that makes recovery and review possible.

3. Shared credentials destroy attribution

Broad service accounts look convenient because they remove friction. They also flatten accountability.

Google's IAM guidance is blunt here: shared or long-lived service-account credentials weaken attribution, and service-account keys should be avoided when a stronger alternative exists. That matters beyond security hygiene. In an agent system, weak attribution means an operator cannot separate user-approved actions from agent-initiated retries, background automation, or unintended escalation during review.

Once that trail is gone, incident response turns into guesswork. The system may have logs, but it no longer has a trustworthy authority trail.

4. Tenant boundaries blur before anyone notices

Multi-tenant systems do not fail only when a database row leaks. They also fail when identity and workspace boundaries are modeled loosely enough that the wrong context can be pulled into the right-looking run.

That is the quiet danger in agent products serving multiple customers, business units, or workspaces. If identity is treated as a login feature instead of a runtime boundary, the system can execute exactly as designed while operating on the wrong tenant's data, tools, or memory.

Auth0's multi-organization guidance reflects the underlying truth: user isolation and organization boundaries are architectural concerns, not just UI concerns. Agent systems make that sharper because the actor is often continuing work after the human is no longer actively watching the screen.

5. Recovery paths are missing or fake

Most teams add approvals somewhere. Fewer teams design what happens after authority breaks.

If a token expires during a background run, can the task pause and resume under renewed authority? If a human wants to narrow scope instead of fully re-approving, is that modeled? If an agent acted under stale delegation, can an operator roll back, reassign, or force a new consent step? If a retry succeeds, is it still tied to the same actor and approval context, or did the system silently switch authority on the way through?

If those answers are missing, the identity layer is incomplete.

The identity surfaces that actually define control

Identity is often reduced to authentication, but that is only one slice of the operating layer. For agents, five surfaces matter.

Authentication: who started or resumed the authority chain

Authentication answers who the principal is. It does not answer what the agent may do next, how long that authority lasts, or whether the current run is still operating under the same approved context.

Useful? Yes. Sufficient? Not even close.

Authorization: what the system is allowed to touch

Authorization is where scope becomes concrete. Which tools can this run call? Which data can it read? Which write actions are allowed? Which actions require step-up approval?

This is where many agent systems get lazy. They authenticate a user once, then hand the runtime a permission bundle that is much broader than the task actually needs. That makes the happy path easy and the control surface weak.

Delegation: on whose behalf the action is happening

Delegation is the most under-modeled part of many agent products.

A useful agent often acts for a user, but not as if it were the user in every context and forever. Delegation should preserve the chain between the subject who granted authority and the actor performing the work. That is exactly why token-exchange standards bother to distinguish subject and actor identities. Without that distinction, there is no clean way to tell whether the agent is executing delegated work, backend-owned work, or unauthorized carryover from an older approval.

Tenancy: which boundary contains the run

Tenancy decides whose world the run belongs to.

Which customer? Which workspace? Which project? Which connected app installation? Which policy set? Which memory namespace? Which approval history?

When teams treat tenancy as an application concern rather than an identity concern, agent systems become vulnerable to the most embarrassing class of failure: correct execution under the wrong boundary. The agent may call the right tool, follow the right plan, and still operate in the wrong customer's world.

Auditability: what operators can prove afterward

Auditability is not a reporting nice-to-have. It is what lets a team reconstruct legitimacy after something goes wrong.

An operator needs to know which actions were user-approved, which were agent-initiated, which were retried automatically, which tenant boundary and authority were in force, and whether any approval or token state changed during the run. Without that trail, there is no reliable review, rollback, or post-incident explanation.

Why recovery belongs in the identity layer

A lot of teams still treat recovery as workflow logic. If a run fails, retry it. If a task stalls, resume it. If a token dies, reconnect it.

That is too shallow.

Recovery is an identity question because the core issue is not only whether the system can continue. It is whether the system is still allowed to continue.

Re-authentication, re-consent, rollback, reassignment, interruption, and step-up approval belong in the same operating model as permission and delegation. Otherwise the system can resume technically while resuming illegitimately. A retry is not safe just because it succeeds; it is safe only if the authority chain still holds.

That is the difference between a robust background agent and a very determined script.

A governed agent runtime should be able to answer these questions before it resumes, retries, or hands work to another actor:

• What exact authority was used for the last successful action?
• Is that authority still valid for the next one?
• If not, should the run pause, narrow scope, or hand back to a human?
• Can a reviewer see the approval state that justified the run?
• Can the system resume without losing the actor-subject chain?
• Can the operator reassign the task without inheriting hidden authority from the previous run state?

If those questions are external to the identity model, the control plane is incomplete.

The practical standard: identity-safe agent systems

Before trusting an agent in production, teams should be able to say yes to five tests.

1. Authority is scoped, not implied

The runtime should use task-appropriate permissions, not one broad credential that quietly unlocks everything.

2. Delegation is explicit

The system should preserve who granted authority, who exercised it, and whether the agent is acting on behalf of a user, a service, or a separate operator-approved role.

3. Tenant boundaries are first-class

Every run should be anchored to the correct customer, workspace, project, connected app, and memory/tool context, with boundary checks that survive retries, resumptions, and handoffs.

4. Approval and action trails are reconstructable

Operators should be able to tell which actions were approved, which were automated, which were retried, which tenant the run belonged to, and which credentials or tokens were used at each stage.

5. Recovery changes authority safely

Re-auth, re-consent, rollback, reassignment, and interruption should not be bolted on after the fact. They should be part of the core model for how authority is refreshed, narrowed, or handed back to a human.

The real selection question

When teams evaluate agent frameworks, they usually ask whether the system can orchestrate tools, manage context, or run in the background.

The better question is harder: can this system preserve legitimate authority across time, tenants, retries, interruptions, and recovery?

If the answer is fuzzy, the system does not really have a control plane yet.

It has a workflow engine.

And orchestration without identity is just a faster way to lose track of who the machine was allowed to be, what it was allowed to touch, and which boundary it was supposed to stay inside.

Primary-source notes

• IETF RFC 6749 defines OAuth 2.0 around limited, scoped access and token lifetime rather than sharing a user's raw credentials: https://www.rfc-editor.org/rfc/rfc6749
• IETF RFC 8693 distinguishes delegation and impersonation semantics in OAuth token exchange, including subject and actor concepts: https://www.ietf.org/rfc/rfc8693
• Google Cloud IAM guidance warns against shared or long-lived service-account credentials and notes attribution limits when keys are used broadly: https://cloud.google.com/iam/docs/best-practices-service-accounts and https://docs.cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys
• Auth0's multi-organization architecture guidance treats user isolation and organization boundaries as architectural concerns in multi-tenant systems: https://auth0.com/docs/get-started/architecture-scenarios/multiple-organization-architecture

Freshness note: RFC 9700 (OAuth 2.0 Security Best Current Practice, 2025) updates RFC 6749/6750/6819 and is useful companion context for the OAuth framing.