TL;DR: Shared MCP deployments break clean attribution and least privilege when a single GitHub credential is expanded for multiple users, according to Stacklok. The article describes a proxy-based pattern that keeps OAuth handling, session state, and token exchange outside the MCP server so access remains user-linked rather than shared.
At a glance
What this is: This how-to explains a GitHub authorization pattern for MCP servers that keeps access per user instead of collapsing shared use into one credential path.
Why it matters: IAM and platform teams need this pattern because shared machine access erodes attribution, weakens least privilege, and makes downstream governance harder across NHI and emerging agentic workflows.
Context
MCP server deployments often start as single-user integrations, but the control model changes as soon as multiple developers share the same backend. When one GitHub credential gets expanded to reduce request failures, the platform can no longer preserve clean attribution or least privilege across individual users.
This article focuses on the authorization gap created by that shift and the proxy pattern used to close it. In identity terms, the question is not whether access works, but whether the access path still represents the actual user behind each request.
Key questions
Q: How should security teams govern shared GitHub access in MCP deployments?
A: Security teams should avoid a single shared GitHub credential for multiple MCP users and instead preserve a distinct downstream identity path per user. That keeps attribution intact, limits privilege to the actual session, and makes offboarding and incident review possible. If the broker holds the session state, it should also be the place where revocation and audit are enforced.
Q: Why do shared credentials create so much risk in MCP deployments?
A: Shared credentials erase accountability and make containment harder because every tool call appears to come from the same identity. In practice, that means one leaked key can expose multiple users, multiple agents, and multiple tools at once. Request-level identity is what preserves auditability and lets teams scope access correctly.
Q: What signals show that an MCP authorization design is too shared?
A: Look for repository access being widened to prevent request failures, one token serving multiple developers, or logs that no longer identify the originating user. Those are signs that the access path has stopped preserving session-level accountability. At that point, the authorization model is serving convenience at the expense of identity clarity.
Q: Should MCP teams use a proxy to handle OAuth and token exchange?
A: Yes, when the backend should execute requests but should not own the user’s sign-in flow, session storage, or GitHub token management. A proxy keeps those functions centralized and makes the downstream server depend on a controlled credential handoff rather than direct shared access.
Technical breakdown
Why shared GitHub credentials break per-user attribution
A shared GitHub credential turns multiple operators into one downstream identity, which means audit logs, access decisions, and operational blame all collapse into a single account. In MCP deployments, that matters because the server may still act on behalf of an individual developer while the credential itself no longer tells you who initiated the request. The result is a loss of accountability and a broader permission set than any one user actually needs. This is a classic identity dilution problem in non-human access paths, and it becomes more visible as teams move from proof of concept to shared production use.
Practical implication: preserve a distinct credential path for each user rather than expanding one shared token to cover all requests.
How a proxy authorization layer separates OAuth from the MCP server
The proxy pattern moves OAuth handling, token storage, and session management out of the MCP server and into a middle layer that brokers access. The client authenticates once, receives a proxy-issued credential linked to that session, and the proxy exchanges it for the stored GitHub credential when forwarding the request. That architecture matters because the server only sees the downstream credential it needs to operate, while the authorization logic stays centralized. This reduces the need for each MCP server to implement its own auth flow and avoids turning the application layer into the system of record for identity state.
Practical implication: centralise OAuth handling at a proxy boundary when the application should not own long-lived GitHub credentials.
Why session storage and redirect handling become control points
Once the proxy becomes the authorization broker, session persistence and redirect URI configuration become part of the security boundary. In-memory storage is adequate for short-lived testing, but it loses session state on restart, which can interrupt user continuity and complicate operational trust. Persistent storage such as Redis keeps tokens available across restarts, but it also raises the bar for storage governance and recovery design. The key point is that authorization state is now an operational dependency, not just an implementation detail, so reliability and access control have to be managed together.
Practical implication: treat session persistence as part of the authorization design, not as a deployment afterthought.
NHI Mgmt Group analysis
Shared credential expansion is an attribution failure, not just a convenience choice. Once one GitHub credential is widened to serve multiple developers, the organisation loses the ability to prove which user triggered which action. That breaks the basic governance premise behind access review, incident reconstruction, and least-privilege enforcement. The practical conclusion is that shared MCP access should be treated as an identity design flaw whenever user-level accountability matters.
Proxy-mediated authorization is the right pattern when the server should not own identity state. Moving OAuth handling and token exchange out of the MCP server reduces the chance that application code becomes the keeper of long-lived GitHub credentials. That separation is especially useful where multiple clients need the same backend but should not inherit the same privilege boundary. The practitioner takeaway is to keep the application focused on execution and keep authorization state in a dedicated control layer.
Per-user access is the governance minimum for shared machine workflows. Shared use does not have to mean shared identity, and that distinction matters across NHI, IAM, and agent-connected systems. The cleanest operating model keeps the user visible through the full request path, even if the backend executes the task on the user’s behalf. Teams should design for user-linked access paths first, then add operational conveniences only where they do not erase attribution.
Session state has become part of the identity perimeter for MCP integrations. When the proxy stores credentials and resumes sessions, it is no longer just an intermediary, it is part of the access control plane. That makes reliability, restart behaviour, and token lifecycle governance security concerns rather than platform housekeeping. Practitioners should treat the proxy as a governed identity component, not as a simple traffic relay.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 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.
- Read next: MCP Security Guide
What this signals
Per-user access paths are the governance breakpoint for shared MCP use. Once a single GitHub credential is expanded across a team, the programme loses the ability to separate identity from convenience. That forces a redesign around session-linked authorization rather than broader token scope, especially where auditability matters.
Proxy-based authorization changes where control lives. The identity boundary shifts from the MCP server to the middle layer, which means session handling, token exchange, and redirect logic now need governance review. Teams that treat the proxy as infrastructure only will miss the fact that it has become part of the access control plane.
For practitioners
- Define per-user credential paths Require each developer session to map to its own downstream GitHub access path so shared use does not collapse into one broad token.
- Move OAuth handling out of the MCP server Use a proxy authorization layer to manage sign-in, session issuance, and token exchange instead of embedding those controls in the backend server.
- Separate testing storage from production session state Use in-memory storage only for proofs of concept, and move to persistent session storage when restarts, upgrades, or interruptions must not break access continuity.
- Keep client registration at the proxy boundary Absorb client registration and redirect handling in the proxy so every MCP client does not need separate GitHub-side setup.
Key takeaways
- Shared GitHub access in MCP environments weakens attribution because multiple users can end up behind one downstream credential path.
- A proxy authorization layer keeps OAuth handling and token exchange outside the MCP server so per-user access remains visible.
- Teams should govern session persistence, client registration, and redirect handling as part of the identity design, not as setup details.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Shared GitHub credentials broaden access beyond the individual user that triggered the request. |
| NHI-07 — Long-Lived Secrets | The article contrasts long-lived GitHub credentials with session-linked access. | |
| NHI-10 — Human Use of NHI | The pattern preserves user-linked activity behind a machine-mediated request path. | |
| Recommendation — Eliminate shared downstream tokens and assign each MCP user a bounded credential path. Replace persistent GitHub tokens with session-bound credential handling wherever possible. Keep human-originated actions attributable even when a non-human proxy mediates access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post is fundamentally about preserving correct permissions and authorizations in shared access. |
| Recommendation — Align downstream permissions with the individual user rather than a shared team credential. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential storage, exchange, and rotation are central to the proxy pattern described. |
| Recommendation — Manage GitHub authenticators so the MCP server does not own long-lived shared credentials. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The architecture is designed to limit the exposure and reuse of downstream credentials. |
| Recommendation — Reduce credential exposure by brokering access instead of handing the server reusable tokens. | ||
Key terms
- Proxy Authorization Server: A proxy authorization server sits between a client and downstream service to handle sign-in, token exchange, and session handling. In MCP deployments, it can preserve per-user attribution while keeping long-lived credentials out of the application server.
- Per-User Credential Path: A per-user credential path means each request can be traced to the individual who authenticated, even when the request is forwarded through a shared intermediary. It is a governance requirement when multiple users share the same service surface but should not share the same identity.
- Session-Linked Authorization: Session-linked authorization ties access to a specific authenticated session rather than to a reusable shared secret. For shared machine workflows, it improves attribution and reduces the risk that one credential silently becomes a team-wide permission grant.
- Credential Exchange Protocol: A credential transfer pattern that structures how sensitive identity data moves between systems without forcing users to handle raw export files. In practice, it tries to reduce intermediate exposure during migration, while preserving enough structure for safe import and interoperability.
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.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org