Identity and authorization failure modes for delegated personal agents

Contribution to the Identity work stream. Draft prepared for list posting, 2026-07-18.

Author: James Alcorn AI assistance: This message was drafted with help from an AI agent. I have read it in full and I vouch for it. Thread: Responds to the kickoff's starter question, "What do your agents use for identity today, and where does it break?" New topic, own thread; not cross-posted.

Summary

We operate a personal agent that acts continuously, and often unattended, on behalf of a single human across that person's own accounts. In practice almost every identity and authorization failure we hit traces to one gap: today's web and OAuth ecosystem assumes the party acting is either an interactive human in a browser or a pre-registered machine client with its own credentials. A delegated agent acting as a human is neither. Below are the concrete failure modes we have seen, anonymized, followed by directional proposals we hold loosely. We are not confident any of these is the right final shape; several may be better as profiles or extensions of existing work than as new primitives.

Scope and method

The agent authenticates as the human, reusing that person's existing credentials and sessions, and performs bounded tasks the human hands it. Every failure mode below is drawn from real operation, not hypotheticals. Names of apps, the concrete task, the person, their employer, and vendors are generalized. For each mode we describe what happened, why the current model does not cover it, and the impact.

Failure modes at a glance

A. Managed-identity access. Observed: org policy blocks the API connector; only interactive SSO in a browser works, and it re-prompts each time. Gap vs. OAuth today: no way to grant "this person's agent, within these bounds."

B. Step-up auth. Observed: TOTP codes, push approvals, and OTPs to unseen channels all need the human present at that moment. Gap vs. OAuth today: no pre-authorized, out-of-band approval for a known delegate.

C. Bot vs. delegate. Observed: anti-bot challenges hard-fail a legitimate authorized agent. Gap vs. OAuth today: no signal to assert sanctioned, delegated automation.

D. Principal ambiguity. Observed: wrong identity picked from a shared session; can't tell which account owns an entitlement. Gap vs. OAuth today: identity is ambient session state, not an assertable binding.

E. Scope granularity. Observed: connectors grant broad, static, long-lived scopes beyond the task. Gap vs. OAuth today: no per-action or time-boxed grant.

F. Egress to hosted flows. Observed: action finalizes only on a third-party hosted page the environment can't reach; no API path. Gap vs. OAuth today: assumes a human browser with open egress.

G. Core gap. Observed: no scoped, revocable, auditable grant built for a non-interactive delegate. Gap vs. OAuth today: the root the other failures grow from.

Failure modes in detail

A. No sanctioned delegated-access path for enterprise-managed identities

For an account governed by an organization's identity provider, the org's policy blocks the native API/OAuth connector. The only route left is driving an interactive browser through the org's SSO each time. There is no passive or API access and no durable background token; the session expires and re-prompts for password plus a second factor. The result is no unattended operation and a fresh interactive login per task. OAuth supports app-to-resource delegation, but the org has no way to express "this person's agent may act within these bounds," so blocking everything is the safe default.

B. Interactive step-up the agent cannot satisfy on its own

Three variants:

Time-based one-time codes: a rotating code from an authenticator app. The agent has no access to the seed and cannot produce the code inside its short validity window; it needs the human present.

Push approval: a tap-to-approve prompt, sometimes with number matching, sent to the human's physical device.

One-time codes to a channel the agent cannot see: a code emailed or texted to an inbox or number the agent is not connected to, forcing a synchronous human relay.

In each case high-assurance auth collapses to "the human must be present at this exact moment," which defeats asynchronous delegation. Step-up is designed around a present human; there is no notion of pre-authorized, out-of-band approval for a known delegate.

C. No way to distinguish a legitimate delegate from an abusive bot

Anti-bot and "verify you're human" challenges hard-fail a legitimate, authorized agent. There is no channel to assert "authorized agent acting for this identified user," so work the user explicitly delegated is blocked by defenses aimed at abuse. Bot detection sits below or beside the auth layer and has no signal for sanctioned automation.

D. Principal ambiguity

Two variants:

Shared browser profile: with multiple sessions coexisting, a "continue with <provider>" button can silently land on the wrong identity (for example personal versus work). The agent cannot deterministically assert which principal it is acting as.

Multiple accounts per service with different entitlements: a free personal account and a paid work account for the same service. The agent cannot tell which identity owns a given subscription or entitlement without hunting through receipts and billing history.

The risk is acting as the wrong principal or on the wrong account, plus wasted effort reconstructing which account holds what. Identity selection today is ambient state, not an explicit binding the agent controls and can assert.

E. Coarse-grained, non-time-boxed authorization

Connectors grant broad scopes beyond what a task needs - for example full send access when only read is required - with no fine-grained per-action scope and no time-boxing. The agent ends up holding far more authority than any single task warrants, which widens the blast radius if anything goes wrong. Scopes exist in OAuth, but they are coarse, static, and long-lived; there is no standard per-action or short-lived grant tied to one delegated task.

F. Environment and egress gating to third-party hosted flows

Some management actions finalize only on a third-party hosted page - a hosted billing or checkout portal. When the agent's environment cannot reach that host, the task cannot complete, because the only management path is the interactive hosted page and there is no delegated or scoped API for the same operation. A task then blocks at the last step through no fault of the principal or their credentials. The assumption throughout is a human browser with open egress, not a machine-first path.

G. The core gap: no delegation, revocation, or audit primitive built for a non-interactive agent

Underneath all of the above: there is nothing analogous to OAuth's scoped, revocable, auditable grant, but designed for an agent that acts continuously and non-interactively for a principal. The agent must reuse the human's own credentials and sessions, which is coarse, hard to audit at the level of individual actions, and hard to revoke narrowly. This is the root the specific failures grow from.

Directional proposals

These are directions, not finished designs. We hold each loosely and flag the main tradeoff.

Agent authorization grant. What it would do: owner- or IT-issued grant, scoped per action, time-boxed, revocable, auditable - the OAuth analog for a delegate, not a registered app. Main tradeoff or risk: issuance and lifecycle overhead; per-action least privilege can add enough friction that users reach for over-broad grants.

Authorized-agent attestation. What it would do: a machine-readable signal a site or anti-bot system can verify to tell a sanctioned delegate from an abusive bot. Main tradeoff or risk: a target for forgery and abuse; a weak scheme could be spoofed or centralize trust.

Explicit principal binding. What it would do: the agent asserts, and the provider honors, which identity it acts as, instead of ambient session state. Main tradeoff or risk: needs provider support and a binding that cannot be silently overridden; adds a step.

Delegated or out-of-band step-up. What it would do: the principal approves high-assurance auth without the agent holding TOTP seeds or push secrets. Main tradeoff or risk: shifts trust to the approval broker; relaxes the "human present" guarantee step-up exists to enforce.

Entitlement or identity discovery. What it would do: ask which of my identities owns a subscription or entitlement without scraping receipts. Main tradeoff or risk: exposes account-linkage data that itself needs protection.

Enterprise agent-access lanes. What it would do: a supported path for orgs to allow a user's agent bounded access to managed accounts, instead of all-or-nothing. Main tradeoff or risk: expands enterprise attack surface; needs org-side policy controls and monitoring.

Cross-cutting risks and open questions

Attestation abuse and forgery, and where the trust root for it lives.

Trust re-concentration in whatever brokers delegated step-up.

Least-privilege complexity versus usability, where over-scoping becomes the path of least resistance.

Interop: these help only if providers, identity providers, and anti-bot vendors adopt compatible primitives. Unilateral adoption yields little.

Overlap with existing work. Several of these may be expressible as profiles or extensions of current OAuth mechanisms (token exchange, richer authorization requests, existing step-up flows) and related IETF agent-auth drafts rather than new protocols. We have not validated that mapping.

What would change our view

Evidence that existing OAuth extensions already cover these cases in practice would move us toward profiling and documenting those rather than proposing new primitives. We would rather see the smallest change that closes the delegation gap than a new stack.