Yes, when the resource server needs roles, permissions, or tenant attributes to make granular decisions. The key is to source that data from trusted systems during the flow, not to depend on a second lookup after the token is issued.
When Should MCP Tokens Carry External Identity Attributes?
Organizations should add external identity data to an MCP token only when the receiving service needs it to make the authorization decision in real time. That usually means roles, entitlements, tenant context, or similar attributes that affect access at the resource server. The design goal is to avoid a second lookup later, while still keeping the token tightly scoped and trustworthy.
What Belongs in the Token, and What Should Stay Outside It?
The practical boundary is whether the attribute is needed to authorize the current request. If the resource server can decide from a token claim without re-querying another system, the claim may belong in the token. If the attribute is only useful for reporting, analytics, or future state changes, it usually does not. This is why many teams treat MCP authorization as an OAuth 2.1 resource-server problem, not as a generic identity sync exercise.
For federated or delegated access, the safest pattern is to keep the token audience-bound and issue only the minimum claims the downstream service needs. That reduces token reuse risk and keeps the decision anchored to the actual protected resource. When the access path is mediated through MCP, resource indicators and proof-of-possession tokens are stronger patterns than broad bearer tokens with oversized claims.
Enrichment should be fed from trusted upstream systems during issuance or exchange, not from ad hoc copies in application code. If the attribute source is stale, ambiguous, or inconsistent across directories, the token can become a convenient but inaccurate source of truth. In practice, the value comes from the combination of trusted source data and short-lived decision context, not from simply stuffing more identity into the payload.
Why Over-Enrichment Creates Fragility
External identity data is useful when it improves the resource server’s decision quality, but it becomes fragile when teams use it to replace governance. Claims that outlive their source, or that are copied into many tokens without clear freshness rules, create authorization drift. A token can then authorize access that no longer matches the user’s current role, tenant, or approval state.
The opposite problem also appears: if the server must call out to another system for every request, the design shifts from token-based decision-making to runtime dependency chaining. That raises latency, failure-domain, and availability concerns, especially for high-volume MCP services. The goal is to keep the authorization decision local, but still derived from authoritative data.
How This Relates to Identity Quality and Delegation
External enrichment only works well when the underlying identity data is clean, current, and owned by a reliable system of record. If role data is inconsistent or poorly correlated, the token will faithfully carry bad decisions faster. Teams that already invest in an identity data fabric or identity visibility and intelligence platform tend to do better here because they can verify attribute provenance before it reaches the authorization layer.
Where MCP is used for delegated or agent-driven access, the token contents should reflect the delegation boundary, not just the end user’s profile. That is where the MCP security model and the agent identity perspective matter: the token should capture who or what may act, for which resource, and under which constraints, without turning every downstream service into a second identity platform.
Risk and Threat Considerations
Enriching MCP tokens can reduce lookup overhead, but it also widens the blast radius if the token is over-privileged, stale, or easy to replay. The main failure mode is not the extra claim itself, it is treating the claim as permanently trustworthy after the issuing context has changed.
Failure mechanism: A broad or long-lived token can outlive role changes, tenant moves, or revocations, allowing unauthorized access until expiry or manual cleanup.
Impact: That can produce privilege drift, tenant isolation failures, or replayable access in exactly the place where the resource server assumed the token was authoritative.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP tokens often represent non-user service access and delegation. |
| AC-6 — Least Privilege | Only the minimum claims needed for the resource decision should travel in the token. | |
| IA-5 — Authenticator Management | Enriched tokens depend on managed credential and token lifecycle controls. | |
| Recommendation — Bind MCP service-to-service access to authenticated, audience-scoped identities. Limit enriched claims to the least privilege needed for the target resource. Control token issuance, rotation, and revocation as managed authenticators. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP services must not expose broader function access through over-broad token claims. |
| API2 — Broken Authentication | Token enrichment still depends on correct authentication and token handling. | |
| Recommendation — Enforce function-level authorization on every MCP endpoint and tool action. Validate token authenticity and binding before trusting enriched claims. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The question is fundamentally about access decisions from trusted identity attributes. |
| Recommendation — Align token enrichment with access-control policy and authoritative identity data. | ||
Practitioner Guidance
What to verify: Confirm that every enriched claim has a named source of truth, a freshness rule, and a clear decision owner. If the attribute cannot be trusted at the point of issuance or exchange, it should not be used for authorization.
Decision rule: Put the attribute in the token when the resource server must enforce the decision locally and the claim can be bounded to the specific audience and lifetime. Keep it out when the value is informational, volatile, or better resolved through a separate governance path.
Practitioner takeaway: Enrichment is justified when it improves the correctness of the authorization decision, not when it merely makes the token look more complete.