Notifications
Clear all
Topic starter
19/08/2026 3:52 pm
TL;DR: MCP server authorization is not solved by authenticating users to the server, because downstream access still depends on the credential, scope and attribution the server uses on backend systems, according to Stacklok. Shared service accounts, broad passthrough and runtime approval prompts weaken least privilege and make enterprise MCP deployments harder to govern.
NHIMG editorial — based on content published by Stacklok: MCP server authorization for downstream access
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams enforce per-client authorization in MCP environments?
A: Security teams should bind each request to a specific client identity, approved scope, and approved operation on the server side.
Q: Why do shared service accounts create problems in MCP deployments?
A: Shared service accounts make the backend see one identity for many users, so attribution disappears and privilege usually expands to make the account usable everywhere.
Q: What breaks when teams rely on MCP authorization instead of identity governance?
A: Approval, ownership, and recertification break first.
Practitioner guidance
- Define the downstream authorization path for every MCP server Document which backend system each server calls, what credential it uses and where identity context is translated or dropped.
- Replace shared service accounts with delegated credentials Use distinct, task-scoped credentials that preserve attribution to the originating user while keeping the server visible in the request path.
- Scope backend tokens to the current task Descope credentials so the MCP server can only reach the resources and actions required for the current request.
What's in the full article
Stacklok's full how-to covers the operational detail this post intentionally leaves for the source:
- Concrete backend authorization patterns for GitHub, AWS, Atlassian and Google Docs.
- Examples of token delegation and token exchange flows across shared infrastructure.
- Practical ways to separate human and agent identity patterns without broad passthrough.
- Guidance on when workload-specific identity becomes the better long-term model.
👉 Read Stacklok's how-to on MCP server authorization for downstream access →
MCP server authorization: what downstream identity gaps teams miss?
Explore further
19/08/2026 4:29 pm
Downstream authorization is the real MCP governance boundary. The article correctly separates server authentication from backend authorization, because enterprise risk shows up when the server must act in another system on behalf of a user. That is where NHI controls, delegated credentials and policy enforcement either preserve context or collapse it. For IAM and NHI teams, the control plane that matters is the downstream one, not the login to the MCP server.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to Astrix Security.
- In the same research, 53% of MCP servers expose credentials through hard-coded values in configuration files.
A question worth separating out:
Q: How does delegated credentialing differ from forwarding a user token?
A: Delegated credentialing preserves attribution while issuing a distinct token with task-scoped permissions for the server or agent. Forwarding a user token often exposes broader user authority to the backend system than the current task requires. The safer model keeps the user visible without collapsing the user and the machine into one identity.
👉 Read our full editorial: MCP server authorization exposes downstream identity and scope gaps
