Topic starter
05/07/2026 10:33 pm
TL;DR: Multi-agent systems can distribute work across specialized agents, but once those agents call external APIs, identity, consent, and token scope become the real control plane, according to Descope. The practical shift is that least privilege must be enforced at token exchange and connection level, not just in application code.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “Build Secure Multi-Agent Systems With CrewAI and Descope”.
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.
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.
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.
Practitioner guidance
- Define per-agent authority boundaries Assign each agent a single operational purpose and map it to a dedicated Connection or equivalent token scope.
- 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.
- 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.
Bottom line: Multi-agent orchestration does not remove identity risk, it concentrates it at token issuance and scope mapping.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
05/07/2026 10:46 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Secure multi-agent systems need token-scoped identity at runtime