Loading
Loading
3366 Members
Join Permit's SlackIn many stacks today, yes, and that is an anti-pattern to mitigate. Passing the user's OAuth token or session to an agent is not the same as authorizing each tool call. OAuth alone is not an agent authorization system.
OAuth proves that a user consented to an application accessing something. It does not decide whether an AI agent should call a specific tool, on a specific resource, at a specific time, for a specific delegated task. That gap is where most AI agent security (and agentic AI security more broadly) problems start: the moment an agent takes action, access control becomes evidence of who acted, under whose authority, and whether policy allowed it.
Inherited access is the easiest developer experience. A user connects Drive, Salesforce, GitHub, Jira, or an internal API. The agent receives a session, API key, OAuth token, or tool-server credential, and from there it calls tools as if it were the user.
Connecting tools is useful. Governing delegated authority is a separate problem. If the tool server accepts the token, many systems treat that as authorization. Fine for demos. Dangerous in production.
The inherited-token model answers "Can this client reach the tool?" It does not answer whether this agent should use this tool, whether the action is inside the user's intent, whether the resource is sensitive, or whether a human should approve.
Protocol angles: MCP auth vs agent authorization, MCP auth bypasses and tool-call runtime authorization, and Claude Code token theft and OAuth runtime authorization.
User access is usually broader than agent access should be. A finance employee may view payroll. An invoice-summarizing agent should not.
When an agent inherits the user's permissions, least privilege collapses three ways:
As I wrote in The Muse 0-day isn't about Muse, the blast radius is set less by the login event and more by what the agent is allowed to do afterward.
OAuth token exchange and on-behalf-of flows are a real improvement over handing the agent the user's raw token. The agent gets its own token, bound to the user, often with narrower scopes and audience. Use them.
But a token, however well minted, still carries coarse scopes decided up front. It cannot decide whether this agent, acting for this user, may export this customer record or issue this refund right now. That decision belongs where delegated authority becomes a side effect: the tool call, evaluated against deterministic policy and current data. The model decides what it wants to do. The authorization layer decides whether it is allowed.
Short answer: the agent authenticates as itself, with its own token.
When an AI agent connects to Auth0, Okta, or another IdP, it typically receives its own access token. The user grants consent for the agent to act, and the IdP issues credentials to the agent application. Those credentials carry the agent's client ID and scopes. The user's session and full permission set stay behind. This is standard OAuth behavior. Auth0 describes the pattern in its User Authentication for AI Agents documentation: the agent acts as a client that requests access on behalf of a user, but the token it receives reflects what the user consented to share, filtered through the agent's registered scopes.
If you need the agent to carry more of the user's context, OAuth token exchange (RFC 8693, supported by Auth0 via Custom Token Exchange) lets you swap the user's token for a new one bound to the agent's identity and audience. The result is still a token scoped to what the user allowed and what the authorization server permits for the exchange.
Even with token exchange, OAuth scopes describe API access at a coarse level: read email, access calendar, call Salesforce. They do not carry resource-level permissions such as "may read invoice 42, may not read invoice 43" or "may update this opportunity but not that one." That granularity lives in the application's authorization layer.
The practical fix is to check the agent's own role and the delegated scope at each tool call. The IdP confirms the agent is legitimate and the user consented. A policy check at the tool confirms the agent may perform this action, on this resource, under current business rules. Permit's MCP Gateway does this at the protocol layer, evaluating policy before each tool executes and logging the decision.
RBAC for AI agents starts with AI agent identity: the agent is its own actor, not a silent proxy for the human session. For more on why identity alone is not the finish line, see agent identity vs agent authorization and why agent identity is not enough without runtime permissions.
In practice:
Zero standing privileges means the agent holds no broad, always-on access. Just-in-time access means capability is granted for the task, the resource, and the moment, then expires. Together they are the opposite of inherited access.
The enforcement point is the tool call: a PEP in front of the tool, API, or MCP server asks a PDP before the side effect runs. High-risk actions route to human approval as policy, not prompt text. Example: agent invoice_assistant acting for alice@company.com may read invoices for assigned vendors, may not touch payroll, and may not send payment instructions without approval.
Agents can inherit user context. They should not inherit unlimited user authority. If you want that checkpoint in front of your agents' tools, the Permit MCP Gateway enforces per-tool policy, approvals, and decision logs. For the compliance view, start from the compliance teams page.
In many stacks today, yes: the agent reuses the user's token or a shared credential. This is an anti-pattern to avoid. Properly configured (as with Auth0 or similar IdPs), the agent authenticates as itself and receives its own token. Mitigate by giving the agent its own identity and role, intersecting that with the user's authority, and checking policy at each tool call.
No. OAuth, including token exchange, handles delegated authentication and scoped access. It does not decide whether a specific tool call is allowed in a specific business context.
Give the agent its own identity and role, bind it to the human principal, authorize each sensitive tool call against policy, require approval where risk is high, and log allow and deny with reasons.
Yes, when the agent has its own role intersected with the user's authority and the resource. Pure user impersonation is inherited standing privilege, not RBAC for agents.
The agent holds no persistent broad access. Permissions are evaluated or granted just in time, per task and resource, and expire.
The agent authenticates as its own client, so Auth0 issues a token to the agent, not to the user. That token carries the agent's scopes and the user's consent, but it does not inherit the user's internal application roles or resource-level permissions. Use token exchange if you need user context in the agent token, and check the agent's role against policy at each tool call for resource-level rules.
Co-Founder / CEO at Permit.io
