Overview
Delegation and Impersonation are the mechanisms by which a human user grants an AI agent permission to act on their behalf. This is distinct from the agent having its own identity. Here, the agent "borrows" the user's identity or a subset of their permissions.
This is critical for personal assistants (e.g., "Book me a meeting") where the action must be attributed to the user, not the bot. The challenge is doing this securely without handing over the user's password or long-lived master keys.
Architecture
OAuth 2.0 Token Exchange or Grant flows are the standard for this delegation.
Key Decisions
- Scope Restriction: The delegated token should have narrower scopes than the user's full login. (e.g.,
calendar.read_writeonly, notadmin.directory). - Time-Boxing: How long is the delegation valid? Can the agent act while the user is offline? (Offline Access).
- Revocation: The user must have a "Kill Switch" dashboard to see which agents have delegation rights and revoke them instantly.
Implementation
OAuth 2.0 Refresh Tokens
The standard way to allow offline access.
- User performs OAuth flow with
access_type=offline. - Agent receives a Refresh Token.
- Agent rotates Access Tokens to perform tasks.
- Critical: Secure storage of Refresh Tokens (encrypted at rest) is paramount.
GNAP (Grant Negotiation and Authorization Protocol)
An emerging standard (successor to OAuth) that allows for richer negotiation of interaction, specifically designed with complex delegation scenarios in mind, though not yet widely adopted compared to OAuth.
Risks
- Token Theft: If the agent's token storage is compromised, attackers get persistent access to the user's accounts.
- Scope Creep: Users blindly clicking "Allow" to broad permission scopes requested by agents.
- Lack of Visibility: Users forgetting they delegated access to an agent 6 months ago. Periodic recertification ("Do you still want 'TravelBot' to access your Calendar?") is required.