MCP servers create problems when the access path stops representing the individual user and starts representing the server itself. At that point, GitHub can no longer distinguish who acted, and teams often broaden tokens to keep requests from failing. That turns a delegated access path into shared infrastructure privilege.
Why This Matters for Security Teams
MCP servers can turn a normal delegated GitHub workflow into shared infrastructure access, which is why identity governance gets messy fast. The problem is not just authentication, but attribution: once GitHub only sees the server, it loses the ability to distinguish the original human actor from the automated path that executed the request. That breaks auditability, least privilege, and offboarding discipline.
This is exactly the pattern behind broader NHI exposure. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which helps explain why teams often respond to MCP failures by widening tokens instead of fixing identity design. OWASP’s Non-Human Identity Top 10 frames this as a governance issue, not just a tooling issue, because machine access frequently outlives the person or workflow that originally justified it.
In practice, many security teams discover the problem only after a token is over-scoped, a repo is overexposed, or an incident review cannot answer who actually triggered the change.
How It Works in Practice
MCP servers create identity problems when they sit between the user and GitHub while holding the credentials that GitHub ultimately trusts. If the server uses one long-lived token for many users, every action collapses into the same identity. That means branch updates, issue writes, workflow triggers, and repository reads may all appear to come from the same machine principal, even when the intent originated with different humans.
For agentic or tool-driven workflows, current guidance suggests treating identity as both workload-based and task-based. The best pattern is to bind the server to a workload identity, then issue short-lived credentials only when a specific task is authorized. That aligns with standards work such as the OWASP Agentic AI Top 10 and NIST’s Cybersecurity Framework 2.0, which both emphasize least privilege, monitoring, and response.
- Use per-user delegation only when GitHub can preserve end-user attribution.
- Prefer short-lived, task-scoped tokens over shared static secrets.
- Separate MCP server identity from GitHub action authority.
- Evaluate access at request time, not only at provisioning time.
- Log the originating user, tool action, and repo target together.
NHI Mgmt Group’s Top 10 NHI Issues research is consistent with this pattern: once secrets and privileges become reusable infrastructure, governance weakens quickly. These controls tend to break down in shared MCP deployments that route many users through one service account because GitHub attribution and revocation stop matching the real actor.
Common Variations and Edge Cases
Tighter GitHub token scoping often increases integration overhead, so organisations have to balance operational reliability against identity fidelity. That tradeoff is real, especially when MCP servers support automation across multiple repos, environments, or teams.
There is no universal standard for this yet. Some environments use GitHub App installations for cleaner repository scoping, while others rely on OIDC-backed federation or brokered delegation to avoid storing static secrets. The key question is whether the MCP server is acting as a named workload with bounded authority, or as a proxy that silently inherits broad human access. If it is the latter, the governance model is already drifting.
Edge cases appear when one MCP server serves multiple tenants, when tool calls chain into other systems, or when emergency access bypasses normal approval paths. In those cases, identity controls need runtime policy, strong audit trails, and offboarding that can revoke the server path independently of user accounts. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how quickly shared machine access can become an incident multiplier, while the State of MCP Server Security 2025 highlights how often MCP deployments expose credentials or fail to scope tool permissions. In mixed human-machine workflows, the model breaks down when teams optimise for convenience instead of preserving who-did-what at the point of GitHub authorization.
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-01 | Shared MCP tokens create NHI attribution and privilege sprawl risks. |
| OWASP Agentic AI Top 10 | A2 | Agent-style tool access needs runtime authorization, not static trust. |
| CSA MAESTRO | IAM-3 | MAESTRO addresses identity controls for autonomous tool-using workloads. |
| NIST AI RMF | AI RMF governs accountability for autonomous, tool-using systems. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust requires dynamic, least-privilege access decisions for machine paths. |
Inventory every MCP-to-GitHub identity path and replace shared tokens with scoped machine identities.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
