Identity-aware Claude agents still depend on scoped authorization

At a glance

What this is: This tutorial shows how to build a Claude-powered Gmail agent with layered authentication, progressive OAuth scoping, tool-level authorization, and human approval for sends.

Why it matters: It matters because AI agents are increasingly acting like non-human identities, and IAM teams need controls that separate what an agent can request, what it can touch, and what a person must approve.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Descope's tutorial on building an identity-aware Claude Gmail agent

Context

Identity-aware AI agents are not a single permissioned action, they are a chain of separate operations that can read, decide, draft, and send. In IAM terms, that means one user request can expand into multiple authorization events with different risk levels, especially when the agent touches inbox data, outbound messages, and third-party APIs.

The governance gap is not just whether an agent is authenticated. It is whether the programme can bind scope to task, require user consent for sensitive steps, and keep the agent from ever holding long-lived credentials directly. For agentic AI, that is the practical boundary between useful orchestration and uncontrolled delegated access.

Key questions

Q: How should security teams implement AI agent email access without over-granting permissions?

A: Use separate read and send scopes, request them only when the workflow needs them, and keep downstream service tokens inside the identity layer. The agent should never hold Gmail credentials directly. Add a final approval step for outbound mail so OAuth consent and user intent are not treated as the same control.

Q: Why do AI agents complicate traditional IAM control design?

A: Because one user request can expand into multiple machine actions with different risks, such as reading data, drafting content, and sending messages. Traditional IAM often binds privilege at provisioning time, but agentic workflows need scope decisions that track runtime intent and action sequence, not just initial authentication.

Q: What do teams get wrong about OAuth consent for agents?

A: They assume consent to access a service is the same as consent to perform a specific action. In practice, OAuth proves capability, not intent. For agents, a send permission should still be followed by a separate approval step whenever the action can disclose sensitive content or create irreversible change.

Q: How do you know if an agent is operating outside its intended boundary?

A: Look for actions that cross from requested read-only work into write, share, or send behaviour without a new consent event or approval event. If the agent can continue after a scope change without a fresh authorization check, the boundary is too loose for safe governance.

Technical breakdown

On-behalf-of OAuth keeps Gmail credentials out of the agent

On-behalf-of OAuth means the MCP server, not the agent, fetches the downstream Gmail token after validating the user’s identity and scope. The agent receives an MCP access token for the session, but the actual Gmail credential is stored and refreshed by the identity layer. This separation matters because it reduces direct credential exposure, limits blast radius, and preserves the principle that the agent is an executor, not the token owner. In a remote MCP model, the server becomes the policy boundary between conversational intent and API access.

Practical implication: keep downstream service tokens behind the MCP server and never pass them into agent prompts or tool context.

Progressive OAuth scoping changes permission from upfront to task-based

Progressive scoping requests permissions only when the agent first needs them. Instead of granting read and send access at session start, the user is asked for gmail.readonly when inbox access is required and gmail.send only when a send action is attempted. That design aligns consent with intent and avoids over-granting access for tasks that may never occur. The important IAM point is that scope selection becomes event-driven, not static, so authorization can track the actual workflow rather than the maximum possible workflow.

Practical implication: split read and write scopes, then trigger consent at the moment the agent crosses into a new risk tier.

Per-action approval separates authorised access from authorised intent

Even when the Gmail send scope exists, the tutorial adds a final Enchanted Link approval before the message is sent. That distinction is critical: OAuth proves the agent may act within a scope, but it does not prove the user wants that specific email sent. Human-in-the-loop approval becomes the last control for high-impact actions where content, recipient, or context can be wrong. In practice, this is a control for semantic risk, not just credential risk, and it belongs at the action boundary.

Practical implication: require a separate approval step for outbound actions that could expose data or create irreversible side effects.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Identity-aware agents are still NHI problems first, even when they feel conversational. The core issue in this pattern is delegated machine access, not chat UX. The agent reads and sends email by chaining identity events, which means the governance burden sits squarely in NHI lifecycle, scope design, and token handling. Practitioners should treat the agent as a non-human identity that happens to speak natural language, not as a human surrogate with human-style controls.

Progressive consent is a useful control pattern, but it does not solve the deeper trust model. It reduces over-scoping by binding permissions to task initiation, which is better than front-loading every possible privilege. But it still assumes the agent’s behaviour remains inside a predictable action path. As soon as the workflow can branch, retry, or expand, the governance question becomes whether the programme can keep authorisation proportional to actual execution rather than intended execution.

Token isolation is the real control boundary, not the model wrapper. The agent can be compromised, hallucinate, or mis-handle instructions without directly exposing Gmail credentials if downstream tokens never leave the identity tier. That makes the MCP server a policy enforcement point, not just a transport component. For IAM teams, the lesson is that agent security is won or lost at credential containment and scope mediation, not in the prompt layer.

Task-scoped approval should be treated as a distinct control domain from OAuth consent. OAuth grants capability. Approval confirms intent. Those are not interchangeable, and conflating them is how organisations end up authorising access that no one explicitly meant to exercise. The practitioner takeaway is that high-risk agent actions need a second control plane for user confirmation, especially where the output can be externally visible or irreversible.

Runtime authorisation for agentic email is a named governance pattern worth carrying forward. The article illustrates a broader runtime authorisation gap: decisions about what an agent may do cannot be fully settled at provisioning time because the workflow unfolds dynamically. That gap is visible across OWASP Agentic AI risks and NIST AI governance discussions. Practitioners should treat this as a sign that agent governance must operate at session time, not only at enrollment.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 44% have implemented any policies to govern AI agents, which shows that policy coverage is lagging far behind deployment reality.
• For the broader control model, see OWASP Agentic AI Top 10 for the runtime risks that make task-scoped authorization necessary.

What this signals

Runtime authorisation gap: agent governance is moving from static entitlement review to event-based control, because a conversational workflow can change risk state mid-session. Teams that still rely on session-start approval will miss the point at which a read task becomes a send task, and that is where exposure begins.

With 80% of organisations already seeing AI agents act beyond intended scope, the practical question is no longer whether to govern agents, but where to place the enforcement point. The right answer is usually between the agent and the downstream service, not inside the prompt.

For teams mapping controls to standards, this is a strong fit for NIST AI Risk Management Framework governance thinking and for OWASP Agentic AI Top 10 style runtime threat modelling. The programme impact is clear: consent, scope, and approval need to become distinct control events.

For practitioners

• Separate read and send authority Keep inbox access and message send permissions in different scopes, then request only the narrower scope needed for the current task. This reduces accidental overreach and makes consent reviews legible to users and auditors.
• Keep service credentials inside the MCP boundary Ensure the agent never receives downstream Gmail OAuth tokens directly. Fetch and refresh credentials on behalf of the user inside the MCP server so token exposure stays confined to the identity tier.
• Add a second approval gate for outbound actions Require explicit user confirmation before the agent sends a message, even after OAuth consent exists. Use per-action approval for emails, file shares, and any action that can expose confidential content.
• Validate scope at connection time and at action time Check the minimum required scope when the client connects, then re-check before each sensitive tool call. That prevents silent drift between a valid session and an invalid entitlement.

Key takeaways

• AI agents behave like delegated non-human identities, so mailbox access must be scoped and mediated like any other machine credential.
• The article’s model shows why 80% of organisations already seeing out-of-scope agent behaviour is a governance warning, not an edge case.
• Separate OAuth consent from per-action approval if you want an agent to be useful without becoming an uncontrolled sender.

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 oauth scoping: A permission model that asks for access only when a task first requires it, rather than granting every possible scope up front. For AI agents, this reduces over-privilege and keeps consent aligned to the exact action being attempted, especially when workflows branch into higher-risk operations.
• Task-scoped approval: A control that requires explicit human confirmation for a specific action, even after the system already has the technical permission to act. In autonomous or agentic workflows, it separates capability from intent and is most valuable for sends, shares, deletes, and other irreversible steps.
• Mcp server: A remote control layer that standardizes how agents connect to tools and data sources while keeping authentication and authorization outside the model. In practice, it becomes the policy boundary that can validate identity, enforce scope, and prevent direct credential exposure to the agent runtime.

Deepen your knowledge

AI agent identity, scoped authorization, and runtime approval are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building agent governance from a similar starting point, it is worth exploring.

This post draws on content published by Descope: Build an Identity-Aware Claude Gmail Agent With Descope. Read the original.