# Delegated personal agents: seven identity and authorization failure modes we hit in production, plus six directional proposals

## James Alcorn (2026-07-18)

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.