What delegated authority means
Delegated authority is the permission a person (or an organization) gives an AI agent to act for them. When an assistant books a meeting in your calendar, files a support ticket in your name or retrieves an invoice from a supplier's portal, it is exercising authority that originated with you.
Good delegation has three properties: it is scoped (the agent can do some things, not everything), bounded in time (it expires or can be revoked) and attributable (the receiving application can tell whose authority is being exercised).
Why it matters for applications
From an application's point of view, an agent request raises up to three separate questions:
- Which client sent this? That is agent identity, which signed requests can establish (see HTTP Message Signatures).
- Whose authority is it acting under? That is delegation.
- Is that authority enough for this action? That is authorization, decided by the application's own policy.
A signed request from a well-known assistant operator answers the first question well. It says nothing on its own about the second. The assistant may be acting for one of your users, for someone who is not your user, or entirely on its own initiative. Treating client identity as proof of a person's consent is one of the most common mistakes in agent-facing design. See what signed AI agent requests prove, and what they don't.
How delegation is commonly expressed
- OAuth-style grants. The person signs in to your application and grants an agent a token with limited scopes, as defined in OAuth 2.0 (RFC 6749). Your application then knows exactly whose authority the token carries, and the grant can be revoked (RFC 7009).
- Account-scoped API keys that a user creates for a specific integration, ideally with narrow permissions.
- In-app confirmations for high-impact actions, where the person approves a specific action the agent prepared.
- Token-level delegation claims. OAuth 2.0 Token Exchange (RFC 8693) defines an
act(actor) claim that records one party acting for another. Newer work on expressing agent delegation in requests is still developing, and applications should verify any delegation claim against their own records rather than accept it at face value.
Common misconceptions
- "If the agent is verified, the user approved it." Verification identifies the client. Approval has to come from the person, through a channel your application trusts.
- "An agent using my user's session is fine." It may be, but the session was issued for interactive human use. Many applications prefer a dedicated, scoped grant for automation so that actions are attributable and revocable.
- "Delegation is all or nothing." The safest delegations are narrow: read access broadly, write access only for specific actions, and confirmation for anything irreversible.
How Proof of Actor relates
Proof of Actor helps you see when an interaction is agent-driven or AI-assisted, and on what basis: verified, declared, inferred or unknown. That context tells you where delegation questions arise, for example an autonomous agent acting inside a human account session. Proof of Actor does not issue or validate delegation credentials, and an Agent result never implies that a person authorized the action. Your application's own grants, scopes and confirmations decide that, and Route lets you apply the right policy per route once you have observed real traffic. For policy patterns, see designing app-level policies for humans and AI agents.
Read what the evidence can and cannot establish, or apply for early access.
Sources
- RFC 6749: The OAuth 2.0 Authorization Framework: scoped grants from a resource owner to a client
- RFC 7009: OAuth 2.0 Token Revocation: revoking a delegated token
- RFC 8693: OAuth 2.0 Token Exchange: the
act(actor) claim for delegation