Secure multi-agent systems need token-scoped identity at runtime

At a glance

What this is: This is a developer tutorial showing how CrewAI multi-agent workflows can be wrapped in MCP and protected with OAuth 2.1, scoped connections, and delegated token exchange.

Why it matters: It matters because IAM, NHI, and security architects need to see how agent workflows change the identity boundary from a single app token to many runtime-scoped permissions.

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.
• 17 minutes.

👉 Read Descope's tutorial on securing CrewAI multi-agent systems with MCP

Context

Multi-agent systems are not just a scaling pattern for AI tasks, they are an identity boundary problem. The moment specialized agents touch external APIs, the organisation needs to decide how identity, consent, and access scope are expressed at runtime rather than only in application logic.

This tutorial shows a concrete pattern for binding agents to narrowly scoped Google Connections through MCP and OAuth 2.1. For IAM and NHI programmes, the important question is not whether the workflow works, but whether the access model can keep each agent inside its own permission boundary.

The primary lesson is that orchestration does not remove identity governance. It shifts the governance burden into token issuance, client registration, consent, and delegated access handling, which are the same places where machine identity controls usually fail first.

Key questions

Q: How should security teams govern multi-agent workflows that call external APIs?

A: Security teams should govern multi-agent workflows by treating each agent as a separately scoped identity with its own token boundary, consent path, and revocation path. The practical test is whether one agent can reach another agent's API domain without a fresh authorization decision. If it can, the workflow is over-permissioned.

Q: Why do multi-agent systems increase NHI governance risk?

A: Multi-agent systems increase NHI governance risk because each additional agent expands the number of runtime identities, tokens, scopes, and consent decisions that must be controlled. The risk is not just more automation. It is more places where access can drift, persist too long, or be reused outside the original task boundary.

Q: What breaks when OAuth scopes are too broad for agent workflows?

A: When OAuth scopes are too broad, an agent can reach data or actions beyond its intended role, and the crew becomes a privilege amplifier rather than a control boundary. That creates unnecessary blast radius, weakens auditability, and makes revocation less precise because a single token covers multiple use cases.

Q: How do teams know whether agent tokens are truly least privilege?

A: Teams know agent tokens are truly least privilege when each token maps to one narrow workload, one data domain, and one clear revocation decision. If the same token can service several tasks, or if a human cannot explain why a scope is needed, the model is not least privilege in practice.

Technical breakdown

MCP and OAuth 2.1 as the agent identity layer

Model Context Protocol turns the agent workflow into a protected resource that clients discover and access through OAuth 2.1. That matters because the identity boundary sits in front of the crew, not inside each agent. In the described pattern, the MCP server publishes protected-resource metadata, clients register dynamically, and bearer tokens are validated before any tool call executes. This is a standards-based way to make agent access auditable, but it also means the authorization server becomes the policy chokepoint for every downstream action.

Practical implication: treat MCP discovery and OAuth configuration as part of your identity control plane, not as application plumbing.

Connection-scoped tokens and least privilege for agents

The key control is token scoping at the Connection level. Each agent receives only the access token needed for its assigned API, such as calendar or contacts, and the server never stores refresh tokens in its own code. That is stronger than embedding API credentials in the workflow because scope is enforced at issuance time and refreshed on demand. For NHI governance, this is the operational difference between a shared integration token and an independently bounded machine identity.

Practical implication: separate agent capabilities into discrete connections and validate that each token maps to one narrow responsibility.

Delegated token exchange without refresh-token custody

The pattern delegates Google token storage and refresh to Descope while the server exchanges the MCP bearer token for short-lived access tokens at runtime. This reduces standing credential exposure, but it does not remove trust from the system. The server still decides which agent can ask for which scoped token, and the consent flow still governs whether the user approved that connection. The architecture is therefore safer than local token handling, but it remains dependent on accurate scope design and lifecycle control.

Practical implication: move refresh-token custody out of the application, then verify that consent, scope mapping, and revocation all align with operational ownership.

Threat narrative

Attacker objective: The objective is to use legitimate agent orchestration paths to reach data or actions that should have remained isolated by scope.

1. entry: An authorised user or client reaches the protected MCP server through OAuth 2.1 discovery and dynamic client registration, establishing a legitimate session boundary.
2. escalation: The server exchanges the MCP bearer token for scoped outbound access tokens, and any overbroad connection mapping would let one agent act beyond its intended API scope.
3. impact: A mis-scoped or over-permitted agent workflow could create calendar events, query contacts, or extend access beyond the intended task boundary, turning orchestration into unintended data movement.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

Token-scoped agent access is the real control boundary, not the crew itself. The article correctly shifts attention from orchestration logic to OAuth 2.1, connection scopes, and delegated token exchange. That is the point where multi-agent systems become an NHI governance problem, because each agent is only as constrained as the token it receives. The practitioner conclusion is that agent security starts with runtime scope design, not with the number of agents in the crew.

Refresh-token custody is where many machine identity programmes quietly fail. The described pattern avoids storing refresh tokens in application code and instead delegates token vending to an identity layer. That removes one common persistence point, but it also makes revocation, consent, and connection lifecycle discipline more important. In NHI terms, the issue is not just secret storage. It is whether the identity system can prove that access ends when the task or connection ends. Practitioners should treat delegated token custody as a governance decision, not a convenience feature.

Agentic workflows expose a narrow but important identity concept: connection blast radius. A calendar agent and a contacts agent can share a crew while remaining separately bounded, but only if the scope map is precise enough to prevent privilege overlap. That maps cleanly to OWASP NHI and Zero Trust thinking, where the unit of trust must be smaller than the workflow. The practical conclusion is that every additional agent should force a fresh review of what can be reached, copied, or triggered through its scoped token.

Least privilege for agents is defined by runtime token issuance, not by role intent. Roles like calendar agent or contacts agent sound precise, but they are only descriptive until the authorization server encodes them into enforceable scopes. In a multi-agent environment, the real question is whether the identity layer can keep each agent from inheriting capabilities simply because it participates in the same crew. The practitioner takeaway is to measure privilege by token reach, not by design intent.

Multi-agent systems are becoming a governance test for identity teams, not just developers. The tutorial shows that secure orchestration depends on consent screens, protected-resource metadata, and token exchange policy working together. That is a lifecycle problem as much as an API problem, because access must be granted, constrained, audited, and revoked consistently. Teams that still treat these flows as implementation detail will miss the real control surface. The conclusion is to bring IAM, NHI, and application security into the same review before agent sprawl expands the blast radius.

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.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to SailPoint research.
• That gap reinforces why teams should also read OWASP Agentic AI Top 10 for a broader view of agent identity and tool-use risk.

What this signals

Connection blast radius: multi-agent programmes need a unit of control smaller than the crew itself. When each agent is granted a separate connection and separate token path, the organisation can measure privilege by runtime reach instead of by workflow intent, which is the only reliable way to keep agent governance auditable.

With 80% of organisations reporting agents acting beyond intended scope, the programme signal is clear: agent identity is no longer an experimental edge case, it is an operational governance domain. Teams should expect requests for consent logging, token lineage, and per-connection reviews to become standard in app and IAM design.

For practitioners, the next control step is to connect agent workflows to zero trust principles and review whether protected-resource discovery, client registration, and token exchange are all governed with the same discipline as human access. The pattern aligns closely with the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026.

For practitioners

• Map every agent to a distinct connection scope Separate agent responsibilities into narrowly defined API connections so one agent cannot inherit another agent's access path. Review whether each scope corresponds to a single task boundary, a single data domain, and a single revocation path.
• Move token custody out of the application Delegate refresh-token storage and vending to the identity layer rather than keeping long-lived secrets in server code. Confirm that the application only exchanges short-lived tokens at runtime and never persists credentials locally.
• Treat consent and client registration as governance controls Review MCP client registration, user consent flow, and protected-resource metadata as formal access controls. Require logging and approval evidence for who registered the client, what scope was granted, and when it can be revoked.
• Test for cross-agent privilege bleed Simulate what happens if a calendar-bound agent tries to reach contacts data or if a contacts agent attempts to act on calendar events. Use those tests to confirm that token scope, not code path, is stopping the crossover.

Key takeaways

• Multi-agent systems turn identity into a runtime control problem because each agent can expand the workflow's access surface through its own token path.
• Scoped connections and delegated token exchange reduce standing credential exposure, but only if consent, revocation, and client registration are governed as formal controls.
• IAM and NHI teams should review agent workflows by token reach and connection blast radius, not by how cleanly the crew is organised in code.

Key terms

• Agentic Identity Hub: A control layer for issuing, scoping, and governing identities used by AI agents and multi-agent workflows. In practice, it centralises authorization, consent, and token vending so runtime access can be constrained and audited instead of embedded in application code.
• Connection-scoped access: A permission model that binds an agent or workload to one narrowly defined external integration. Each connection carries its own scope, making it possible to limit what a specific agent can access, reduce blast radius, and revoke access without disturbing unrelated workflows.
• Protected resource metadata: Machine-readable information that tells clients where an authorization server lives and which scopes are required to access a resource. In agentic systems, this metadata turns discovery into a governed step and helps ensure that access requests are explicit and auditable.
• Delegated token exchange: A pattern in which an application does not store long-lived third-party credentials but instead exchanges an existing authenticated token for a short-lived access token at runtime. This reduces secret custody risk, but it still depends on correct scope design and revocation discipline.

What's in the full article

Descope's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step setup of Google OAuth credentials for separate Calendar and Contacts connections.
• Exact MCP server configuration, including protected-resource metadata, DCR, and scope mapping.
• Python server code for token validation, bearer handling, and outbound token exchange.
• MCP Inspector validation steps that show the full OAuth flow end to end.

👉 Descope's full post includes the complete MCP server setup, token exchange flow, and CrewAI sample app details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.