Identity-aware Claude agents still depend on scoped authorization

At a glance

What this is: This is a build guide for an identity-aware Claude Gmail agent that limits access with on-behalf-of OAuth, progressive scoping, and human approval for sends.

Why it matters: It matters because agentic workflows can combine multiple actions into one user request, which means IAM and PAM teams need runtime authorization boundaries, not just initial login controls.

Context

Claude-powered Gmail agents are not single-purpose automations. They can read messages, draft replies, and send content on a user's behalf, which means one conversational task can cross several authorisation boundaries.

The governance problem is not whether the model can call tools. It is whether the identity layer keeps each action scoped to the minimum necessary permission, with approval gates when the action changes from low-risk retrieval to higher-risk outbound execution.

For identity programmes, this is an agentic AI access-control problem, not a generic chatbot problem. The same design pressures appear whenever an autonomous workflow touches shared tools, delegated credentials, or sensitive business actions.

Key questions

Q: How should teams prevent an AI agent from turning a read-only task into outbound action?

A: Split the workflow into separate read, draft, and send permissions, then require a fresh consent or approval step when the action crosses into external effect. The goal is to stop capability from expanding silently inside a single session. That keeps authorisation aligned to intent rather than to the initial login event.

Q: Why does on-behalf-of OAuth matter for AI agent security?

A: It prevents the agent from directly holding the downstream service token, which reduces the blast radius if the agent logic is compromised. The server can retrieve scoped credentials on the user's behalf while keeping the sensitive token outside the agent runtime. That is a stronger control boundary than passing secrets into the model or its tool layer.

Q: What are the signs that an agent access model is too broad?

A: A broad model usually shows up when one user request unlocks multiple downstream actions, when permissions are granted before they are needed, or when outbound actions do not require a second intent check. Those patterns mean the agent has more effective authority than the task requires. That creates preventable exposure even when authentication is working correctly.

Q: What should organisations do when an agent can send messages on a user's behalf?

A: Treat sending as a separate risk class from reading and require explicit approval at the moment of send, not just at account sign-in. That approach reduces the chance that a misread prompt or bad draft becomes an external communication. It also gives review teams a clear accountability point for the final action.

Technical breakdown

On-behalf-of OAuth keeps the agent away from Gmail credentials

On-behalf-of OAuth means the MCP server requests and holds the Gmail token for the user, rather than handing that token to the agent. The agent proves its identity to the server with an MCP access token, and the server exchanges that identity for the scoped Gmail credential only when a tool call requires it. That separation matters because the agent can make decisions, but it never needs direct custody of the downstream secret. In practice, this shifts trust from the agent runtime to the controlled authorisation boundary.

Practical implication: Keep downstream API tokens out of the agent runtime and terminate access inside the server-side identity boundary.

Progressive OAuth scoping matches access to the action

Progressive scoping asks for permissions only when a tool actually needs them, instead of preloading the agent with all possible rights at startup. That matters because reading mail, sending mail, and managing other Gmail functions have different risk levels and different user expectations. The authorisation server can surface an exact consent URL when a missing scope is first encountered, which makes scope expansion visible and intentional. This pattern prevents the common failure mode where a low-risk read request quietly becomes a standing high-risk delegation.

Practical implication: Request scopes at first use and tie each new permission to a specific action boundary.

Human approval closes the gap between capability and intent

OAuth scope says what an agent may do, but not whether a specific action reflects the user's intent. The tutorial adds per-message approval for sending email because generation errors, prompt confusion, or misread context can turn a technically permitted action into an operationally unsafe one. In this design, the approval link acts as a transaction-level control, not a login control. That distinction is important for any agent that can compose external messages, move records, or trigger business processes with external effects.

Practical implication: Add approval gates for outbound or irreversible actions even when the agent already holds the correct scope.

Threat narrative

Attacker objective: The objective in a failure scenario is to get the agent to disclose or send information outside the user's intended authorisation boundary.

1. Entry occurs when the agent receives a user request that can span inbox access, content drafting, and message sending across multiple systems.
2. Credential abuse is limited by on-behalf-of token retrieval, because the agent never directly handles the Gmail OAuth token.
3. Escalation is prevented by progressive scope checks and per-message approval, which stop a read-only task from turning into outbound action without new consent.
4. Impact would be a confidential or unauthorised email send, but the control model is built to stop that before the message leaves the system.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Scoped authorisation is the real control plane for identity-aware agents: the login event is no longer the meaningful security boundary once an AI agent can chain multiple actions inside one user request. The security question becomes which action is being authorised, for which tool, at what moment, and with what approval state. That is a runtime authorisation problem, not a static access problem. Practitioners should treat agent identity as a sequence of bounded decisions rather than a single authenticated session.

Identity-aware agents expose a risk gradient that classic role assignment hides: reading inbox data, drafting a reply, and sending a message are not equivalent acts even when they are triggered by the same prompt. The article makes the case for separating tool eligibility from action finality, which is the right way to think about control design for agentic workflows. A single role or one-time consent event is too blunt when the workflow itself is multi-stage. The practical conclusion is that access design must follow task semantics, not UI convenience.

Progressive consent is a governance pattern, not just a usability pattern: asking for Gmail send rights only when the agent first needs them reduces blind delegation and makes the user see scope growth in context. That improves accountability because the consent event is tied to an observable action, not a hypothetical future need. In NHI terms, this is how delegated authority stays reviewable. Teams should stop treating upfront breadth as efficient and start treating staged consent as the default for agentic access.

Human approval is the missing layer when agent output becomes external action: even correct scopes do not guarantee correct intent, especially when the agent is synthesising content rather than merely retrieving data. The article shows why approval must sit at the point of outward effect, not only at sign-in or tool registration. That is a useful boundary for IAM, PAM, and workflow owners alike. Where an agent can create business impact, the control must verify intent at execution time.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Action boundaries will matter more than model capability: agentic AI programmes will increasingly be judged on how well they separate retrieval, drafting, and execution. If those stages share the same effective permission set, the organisation has already lost the control argument, even if authentication looks clean on paper.

Identity-aware control design should become the default pattern for AI workflows: the practical unit of governance is the transaction, not the account. That means teams need to map what the agent can do at each step, then place approval and scope checks where the impact actually changes.

Runtime consent will be the differentiator between managed and unmanaged agents: once agents can act across systems, static provisioning is no longer enough to explain risk. Access review tells you who had authority at setup, but not whether the latest action still reflected the user's intent.

For practitioners

• Define action-tiered scopes Separate read, draft, and send permissions into distinct runtime boundaries so the agent cannot inherit outbound capability from a low-risk query.
• Keep downstream tokens server-side Use on-behalf-of token retrieval so the agent never sees Gmail OAuth credentials or any other sensitive downstream access token.
• Add approval gates for irreversible actions Require per-action human approval before an agent sends mail, updates records, or triggers other external side effects.
• Verify scope at connection time Reject agent connections that lack the minimum scope needed for the tools they will call, even if the first request is read-only.
• Log consent expansion as a governance event Record each newly granted scope as a distinct change to the agent's effective authority so review teams can see how access evolved.

Key takeaways

• Claude-powered Gmail agents bundle multiple operations into a single request, which makes broad standing permissions a poor fit for the risk profile of the workflow.
• The key control is to separate downstream token custody, scope expansion, and final send approval so each stage is independently governed.
• For identity teams, agent security is a runtime authorisation problem, not just an authentication or integration problem.

Key terms

• On-behalf-of oauth: A delegation pattern where one service requests a downstream token for a user without exposing the user’s credential to the calling agent. In agentic systems, this keeps the identity boundary inside the server layer and prevents the model or tool runtime from becoming the holder of sensitive credentials.
• Progressive Scoping: A pattern where an agent starts with minimal permissions and requests more access only when a later task genuinely requires it. This reduces standing privilege, improves auditability, and makes it easier to see when an agent’s access is expanding beyond its original boundary.
• Human-in-the-Loop Approval: A review step where a person explicitly approves a high-risk access request before it is granted. It is most useful for exceptional privilege expansion, not for routine automation, because the goal is to catch unusual requests without turning every machine action into a manual process.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.