No, not when a standard token exchange flow is available. Custom rewriting is harder to audit, more fragile under change, and easier to couple to a single gateway implementation. Standards-based exchange keeps the security model clearer and gives practitioners a better foundation for future integrations.
Why This Matters for Security Teams
Custom bearer-token rewriting for MCP tool access looks convenient because it can translate one credential format into another without changing every downstream integration. The problem is that it creates a hidden security dependency on the gateway or proxy logic, which can become the real policy engine without the same review, logging, or change control as the identity platform. OWASP’s guidance on the OWASP Non-Human Identity Top 10 treats secret handling and token lifecycle discipline as first-order controls, not implementation details.
This matters even more for MCP because tool access is often chained across LLM-driven workflows, where a small translation bug can widen privileges, break revocation, or make token provenance hard to prove. NHIMG has repeatedly shown how exposed or duplicated secrets become operational liabilities, including in the Guide to the Secret Sprawl Challenge and the OWASP Agentic Applications Top 10. In practice, many security teams discover token rewriting risk only after a gateway change, a revocation failure, or an audit request exposes how much authority the shim has accumulated.
How It Works in Practice
Standards-based token exchange is usually the safer pattern because it preserves a clearer chain of custody for identity and authorization. Instead of rewriting bearer token inside a custom MCP gateway, the system exchanges an incoming token for a downstream token with a narrower audience, shorter lifetime, and explicit issuer context. That makes it easier to align with OWASP Agentic AI Top 10 and established identity controls in NIST SP 800-53 Rev 5 Security and Privacy Controls, because the authorization decision remains inspectable at the boundary.
Practitioners usually want four properties from MCP tool access:
- Token audience is scoped to the exact tool or service being called.
- Token lifetime is short enough to limit replay and lateral movement.
- Revocation and rotation work without gateway-specific parsing logic.
- Audit logs can show who or what requested access, when, and for which purpose.
That model is stronger than rewriting because it avoids embedding business logic into token transformation code. It also reduces the chance that a gateway becomes a single point of failure for every downstream tool. When an MCP stack is integrated with multiple identity providers, custom rewriting often breaks down because the proxy must understand too many token formats, claims, and trust relationships to remain reliable over time. The Ultimate Guide to NHIs shows why lifecycle consistency matters as much as initial issuance, especially where secrets and tokens cross service boundaries.
These controls tend to break down when a legacy MCP gateway is the only component that can speak to the tool provider and the organisation has no native token exchange support from its identity stack.
Common Variations and Edge Cases
Tighter token handling often increases integration overhead, requiring organisations to balance cleaner trust boundaries against migration cost and platform complexity. There is no universal standard for every MCP deployment yet, so current guidance suggests choosing the least custom path that still preserves issuer visibility, audience restriction, and revocation.
There are a few cases where temporary rewriting may be tolerated, but only as a bridge, not a long-term architecture. For example, a migration from a legacy gateway to standards-based exchange may need a short-lived adapter while downstream services are updated. Even then, the rewrite layer should be narrowly scoped, heavily logged, and scheduled for removal. Custom logic becomes especially risky when the same gateway also handles multiple agents, because one malformed translation can over-privilege an entire class of tool calls.
NHIMG’s reporting on exposed OAuth and API credentials, including the Salesloft OAuth token breach and the Vercel Context.ai OAuth Supply Chain Breach, shows the same pattern: once token handling becomes opaque, response and forensics get slower. Organisations should treat custom bearer-token rewriting as an exception path with an expiry date, not as the default design for MCP tool access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Token rewriting increases exposure if rotation and revocation are weak. |
| OWASP Agentic AI Top 10 | A1 | MCP tool access for agents needs bounded, inspectable authorization at runtime. |
| CSA MAESTRO | IAM-02 | Agent tool access must preserve identity traceability across orchestration layers. |
| NIST AI RMF | Agentic token handling is a governance and risk issue for AI systems. | |
| NIST Zero Trust (SP 800-207) | AC-3 | Zero Trust favors explicit, contextual authorization over implicit token rewriting. |
Prefer short-lived exchanged tokens and verify rotation, revocation, and audience scoping.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
