Notifications
Clear all
Topic starter
06/06/2026 1:34 am
TL;DR: Claude-powered Gmail agents chain inbox reading, drafting, and sending across multiple systems, so Descope’s tutorial focuses on on-behalf-of OAuth, progressive scoping, MCP server controls, and per-message approval for sensitive actions. The security lesson is that agent capability must be constrained by runtime authorization and human intent, not broad upfront access.
NHIMG editorial — based on content published by Descope: Build an Identity-Aware Claude Gmail Agent With Descope
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.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Keep service credentials inside the MCP boundary Ensure the agent never receives downstream Gmail OAuth tokens directly.
- Add a second approval gate for outbound actions Require explicit user confirmation before the agent sends a message, even after OAuth consent exists.
👉 Read Descope's tutorial on building an identity-aware Claude Gmail agent →
Identity-aware Claude agents: are your controls keeping up?
Explore further
06/06/2026 2:45 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity-aware Claude agents still depend on scoped authorization
