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

At a glance

What this is: This tutorial shows how to secure a CrewAI multi-agent workflow by binding each agent to scoped OAuth 2.1 credentials through Descope's Agentic Identity Hub and MCP server controls.

Why it matters: It matters because IAM teams now have to govern agent-specific token boundaries at runtime, not just application permissions, when multi-agent systems reach external APIs and shared enterprise data.

Context

Multi-agent systems split work across specialised agents, but that only works safely when each agent's access boundary is explicit. The governance gap is not orchestration itself, but the assumption that application code can carry privilege decisions for every runtime action.

In this pattern, identity and consent move into the control plane for the crew, because each agent may touch different APIs, different scopes, and different data. For IAM and NHI programmes, the question becomes how authority is issued, exchanged, and revoked while the workflow is still running.

Key questions

Q: How should teams prevent one agent from inheriting another agent's permissions?

A: Give each agent a separate token scope, bound to a single Connection or resource, and issue access only at the moment the task runs. Shared credentials make the crew look simpler, but they erase the boundary that least privilege depends on. Runtime token vending is the safer pattern because authority stays narrow and traceable.

Q: Why do multi-agent systems need runtime consent and token exchange controls?

A: Because the real risk appears when an agent reaches beyond local code and starts using external APIs. Consent and token exchange controls decide whether that action is authorised, which scope is issued, and whether the user had to approve it. Without that layer, agent orchestration becomes an unchecked access broker.

Q: What are the signs that agent credentials are being handled unsafely?

A: Look for refresh tokens in application code, broad shared scopes across agents, and access decisions that happen once at deployment instead of per execution. Those patterns show that the crew is carrying persistent authority rather than receiving it on demand. That usually means the identity boundary is too weak for external API use.

Q: How do IAM teams govern multi-agent access without losing visibility?

A: Use a protected resource model where each agentic action maps to a named scope, each scope maps to a connection, and each exchange produces an audit event. That gives IAM teams a reviewable chain from user consent to token issuance to API use. It is much easier to govern than implicit permissions hidden inside agent code.

Technical breakdown

OAuth 2.1 turns the MCP layer into the trust boundary

The tutorial uses an MCP server protected by OAuth 2.1 so the agentic workflow authenticates through a standards-based client flow rather than custom middleware. The protected resource metadata lets clients discover the authorization server, then DCR allows a client like MCP Inspector to register automatically. That shifts trust from the agent code itself to the authorization and discovery layers that sit in front of the crew.

Practical implication: treat the MCP server as the authorization boundary and validate agentic tokens separately from ordinary project tokens.

Connection-scoped tokens prevent agent overreach

Each CrewAI agent receives a short-lived access token tied to a specific Descope Connection, such as calendar or contacts. The contacts agent can search people, but it cannot inherit calendar authority, because token vending happens at runtime and only for the mapped scope. This is a concrete least-privilege pattern for multi-agent systems: the agent is not trusted to self-select broader access just because it sits inside the same crew.

Practical implication: map every agent to a narrow Connection scope and refuse shared tokens across agent roles.

Token exchange replaces token storage as the security control

The server never holds Google refresh tokens; Descope stores, refreshes, and vends the upstream tokens when the crew needs them. That changes the failure surface from secret custody inside application code to governance over who can request a token, for which Connection, and under what user consent. For NHI governance, this is the difference between static credential inventory and runtime authority brokerage.

Practical implication: move credential custody out of application code and audit every runtime token exchange path.

NHI Mgmt Group analysis

Token scope, not just agent logic, is the real control plane: Once an agent can call external APIs, the decisive security question is which token it receives at runtime and what that token can actually do. The article's design makes that boundary explicit through Connection-scoped vending rather than embedded secrets. Practitioners should treat agent authorization as a live governance problem, not a coding detail.

Least privilege changes shape in multi-agent systems: A crew with specialised agents is only safe when each identity path is separate enough to prevent capability bleed. A contacts workflow that can never obtain calendar authority is materially different from a shared integration account with broad rights. The implication is that role design must be translated into token scope, not assumed from the application architecture.

Runtime consent becomes an identity event: The article shows consent, authentication, and step-up options inside the Descope flow rather than outside the agent system. That means the moment a user approves a scope is also the moment enterprise identity policy is enforced for the crew. Teams that still treat consent as a front-end form miss the fact that it is now part of the authorization boundary.

Descope's pattern illustrates a broader agentic identity shift: Multi-agent systems expose why NHI governance has to move from secret ownership to delegation governance. The useful unit is no longer the service account alone, but the issuance rule, the connection mapping, and the revocation path behind it. That is the governance model practitioners will need as agent fleets grow and compose.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Token-scoped delegation: Multi-agent systems force IAM teams to govern authority at the point of issuance, because the meaningful security boundary is the token an agent receives for a specific task. When access is granted per Connection and per execution, the programme can separate role design from runtime privilege.

As agent fleets grow, identity teams should expect more pressure to treat consent, discovery, and token vending as first-class control points. That is especially true where agents interact with calendars, contacts, CRM, or finance systems, because the blast radius follows the scope of the token rather than the name of the agent.

For practitioners

• Define per-agent authority boundaries Assign each agent a single operational purpose and map it to a dedicated Connection or equivalent token scope. Do not let multiple agents share a broad bearer token just because they participate in the same crew.
• Validate agentic tokens separately Check that runtime tokens are verified against the correct agentic JWKS or authorization server metadata, not only against your standard project keys. Keep discovery and validation aligned with the protected resource that the client is actually calling.
• Remove refresh tokens from application code Move upstream token storage and refresh handling into the identity layer so the server only requests short-lived access tokens at execution time. That reduces credential persistence inside the crew runtime and narrows the audit trail to explicit exchanges.
• Instrument consent and token exchange events Log which user approved which scope, which agent requested the token, and which Connection was used for the exchange. Those events are the evidence trail for agentic access reviews and incident investigation.

Key takeaways

• Multi-agent orchestration does not remove identity risk, it concentrates it at token issuance and scope mapping.
• The article shows a practical least-privilege model where each agent receives only the authority it needs for one task.
• IAM teams should govern agentic access through consent, token exchange, and short-lived credentials rather than through static application permissions.

Key terms

• Connection-scoped token: A Connection-scoped token is a short-lived credential issued for one defined integration or API scope. In multi-agent systems, it limits what a single agent can do at runtime and reduces the chance that one task can reuse authority intended for another.
• Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.
• Protected Resource Metadata: Protected resource metadata is machine-readable discovery data published by a service so clients can find its authorization expectations. For agent registration, it tells the actor where to look for supported flows and how to discover the trust model without relying on ad hoc integration.
• Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.