Delegated Agent Identity

Agents often act with either a shared service account that can do far too much, or the user’s own full credentials. With a service account, logs can’t show which user an action was for, and one leaked key exposes everything. With user credentials, the agent can do anything the user can, and nobody can tell what the user did from what the agent did.

• Agents need real access to act on users’ behalf.
• Security wants least privilege and short-lived credentials.
• Audit needs to show both the agent and the user behind each action.
• Users must be able to see and revoke what agents can do for them.

Give each agent its own identity, registered like an application, and have it act through delegated, on-behalf-of tokens. A token names the agent, the user, the scopes granted (for example read calendar, draft but not send email) and a short expiry. Users grant scopes through a consent step and can revoke them. Every downstream system sees and logs both identities. High-risk scopes can require step-up approval each time instead of a standing grant.

Every action carries two names, the agent and the user it acts for, plus only the scopes that user granted, for a limited time.

1. RegistrationIT registers “Scheduling Agent” as its own identity. It may request calendar read/write and email draft scopes, but never email send.
2. ConsentAn employee grants the agent calendar access and draft email for 90 days. The grant appears in their account settings with a revoke button.
3. ActionThe agent books a meeting with a token that names the Scheduling Agent acting for this employee, with the calendar write scope, expiring in 1 hour.
4. Calendar logShows “Created by Scheduling Agent on behalf of the employee”, not just the employee’s name.
5. IncidentMonths later, a bug makes the agent double-book meetings. Security finds every affected event with one query on the agent identity and revokes its write scope for all users within minutes.