Most stacks hand an AI agent the user's OAuth token or session and treat that as authorization. That answers "can this client reach the tool?" It does not answer whether this agent should call this tool, on this resource, for this task, right now.
User access is usually broader than agent access should be. A finance employee may view payroll; an invoice-summarizing agent should not. When the agent inherits the full user entitlement set, least privilege collapses: the agent can do everything the user can, access stays continuous after the original intent goes stale, and tool chains create side effects nobody explicitly approved.
A better pattern: give the agent its own identity and role, keep the human principal in the delegation chain, and intersect agent role with user authority and task context at the tool call. OAuth (even token exchange) is still AuthN and scoped access — not the final allow/deny for each side effect.
We wrote about why inherited permissions fail and what to do instead in our write-up:
https://www.permit.io/blog/do-ai-agents-inherit-user-permissions?utm_source=devto&utm_medium=social&utm_campaign=do-ai-agents-inherit-user-permissions&utm_content=authbyexample
Top comments (1)
The invoice-summarizing example makes this concrete: the user may approve payments, while the agent's task only requires reading selected invoices. Check that narrower authority at every tool call, using task constraints established by trusted application code.
I work on Cedarling; this is a useful case for Cedar policies evaluated before execution. cedarling.dev