TL;DR: A walkthrough shows how Cursor can keep developers productive while an MCP control plane narrows what AI agents can see, call, and return in GitHub, with filters, audit logs, and gateway enforcement separating user permissions from agent permissions, according to Obot. The key governance problem is not productivity, but assuming tool access stays bounded when other clients and direct MCP paths can bypass the intended control plane.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Obot's blog post: Governed MCP access for GitHub workflows uses an MCP gateway, filters, and audit logs to constrain AI agent tool use without removing developer permissions.
Why it matters: It matters because IAM teams now have to govern agent-scoped GitHub access, not just human access, and direct MCP paths can bypass the intended control plane.
Context
The core governance problem is not whether developers can stay productive. It is whether an AI agent’s access to GitHub can be kept narrower than the human user’s access when the agent connects through MCP and other clients may connect outside the governed path.
In this model, the identity boundary shifts from a single human login to a set of delegated tool permissions, upstream credentials, filters, and audit records. That creates an NHI governance problem because the same GitHub account may be used directly by a person while an agent receives a different, limited tool surface through the gateway.
The article’s practical value is in showing where control actually lives: at tool exposure, message inspection, and gateway enforcement, not in the presence of an MCP server alone.
Key questions
Q: What breaks when AI agents connect directly to tools without a gateway?
A: Direct connections create fragmented secrets, inconsistent policies, and limited visibility into what the agent actually did. That makes it harder to revoke access quickly, investigate misuse, or prove control coverage, especially when multiple agents call multiple tools across different environments.
Q: Why do direct MCP connections increase identity risk for GitHub workflows?
A: Direct MCP connections create risk because the gateway is no longer the mandatory interception point. Once clients can talk to upstream servers on their own, filters, policy checks, and audit logs become optional instead of enforced. That turns access governance into a configuration problem spread across endpoints and clients rather than one control plane.
Q: How should security teams decide which GitHub tools an agent may use?
A: Start from the task, not the human role. Give the agent only the tools needed for that workflow, then remove write or destructive functions unless they are explicitly required and separately justified. If a tool can read and write, scope it by arguments and backend credentials rather than assuming the tool name makes it safe.
Q: What should teams do when AI clients outside the gateway are in use?
A: Treat them as unsanctioned entry points until proven otherwise. Inventory every approved and personal client, identify any direct MCP settings, and compare those paths with the governed gateway route. If the same resource can be reached both ways, the weaker path is now part of the effective access model.
Technical breakdown
How MCP tool exposure is narrowed for GitHub agents
An MCP gateway sits between the client and the upstream server, deciding which tools are exposed to the agent and how those tools are named and described. A composite server can present only a selected subset of upstream capabilities, so the client never learns about tools that are not explicitly published through the gateway. This is different from a plain allowlist, because the control plane governs the advertised tool surface itself, not just whether a call is permitted after the fact. The upstream identity still matters because the backend system enforces its own authorization on the action requested.
Practical implication: Use a gateway to make the agent’s tool inventory smaller than the human user’s upstream permissions.
Why filters matter after tool selection
Tool scoping is only the first control layer. Filters inspect arguments, tool messages, and server responses so the gateway can reject, redact, or mutate content before it crosses the trust boundary. That is the mechanism that blocks a permitted tool from becoming a dangerous one when it accepts user-supplied inputs such as repository names, branch names, or returned source content. In practice, this is where prompt injection defense and organization-specific policy enforcement happen, because the gateway can validate whether the request matches the intended tenant, repository, or data domain.
Practical implication: Inspect tool arguments and returned content, not just tool names, before allowing the call to complete.
What gateway audit logs prove and what they do not
Gateway logging records who called what, when, and with what result, giving security teams an evidence trail for agent-mediated access. That audit trail is valuable, but it is not complete coverage if the organization allows direct MCP connections or other AI clients outside the gateway. In other words, logging strengthens accountability only for the traffic it sees. If developers can use alternate clients or point their own configuration at upstream services, the control boundary moves and the audit trail becomes partial rather than authoritative.
Practical implication: Treat gateway logs as authoritative only when all approved clients and paths are forced through the same control plane.
Threat narrative
Attacker objective: Obtain GitHub actions or data through an AI agent path that was meant to be narrower and more inspectable than direct human access.
- Entry occurs when a developer or AI client establishes an MCP connection to GitHub through either the governed gateway path or a direct client configuration.
- Credential and tool scope are then determined by the path taken, with the gateway returning a narrowed tool set while ungated paths can preserve broader upstream access.
- Escalation happens when a permitted tool accepts unsafe arguments or when a direct MCP path bypasses the intended gateway filters and audit controls.
- Impact is unintended repository access, policy bypass, or data exposure through agentic GitHub operations that were supposed to stay constrained.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Governed MCP access is an NHI governance problem, not a client preference issue. Once an AI agent can call GitHub tools, the question is no longer whether the person is authorised. The question is which tools the non-human actor can see, invoke, and return through its own control path. Practitioners should treat MCP exposure as part of the NHI estate, with the same discipline they would apply to service accounts and API tokens.
Tool allowlists are necessary but insufficient because they do not define the full trust boundary. The article’s architecture shows that a client can be restricted in one layer while upstream access remains broader or a second client bypasses the gateway entirely. That means governance has to cover tool advertisement, upstream credential scope, and alternate connection paths together. The practitioner takeaway is that access policy without path policy is not enough.
Gateway logging becomes meaningful only when the gateway is mandatory. Auditability is often treated as a compensating control, but here it only works if every approved client and every MCP route is forced through the same interception point. If developers can connect directly from other AI clients, the audit record becomes partial and the governance model loses its enforcement value. Teams should assume that unsanctioned client paths are control gaps, not exceptions.
Composite MCP servers create a useful separation between human rights and agent rights. That distinction lets organisations let developers keep their GitHub permissions while constraining the agent to a smaller operational surface such as opening pull requests. The important shift is conceptual: agent privilege should be designed around task scope, not mirrored from the human identity. Practitioners should build agent roles as explicit, minimal composites rather than inherited clones of user access.
Overexposed MCP paths create identity blast radius. A single MCP server can aggregate high-value tokens, internal tools, and external services, so one broad connection can become a distribution point for excessive access. That is why this pattern belongs in NHI governance and Zero Trust thinking at the same time. The practical conclusion is to reduce exposed tool sets before you attempt to monitor them.
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.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Read next: MCP Security Guide
What this signals
Identity blast radius is the right concept for governed MCP design. The issue is not merely whether an agent can call a tool, but how far a single client configuration can extend trust across GitHub, upstream credentials, and external AI clients. The safer pattern is to make the gateway the only sanctioned path and to treat any alternate route as unmanaged access.
When tool exposure, upstream authentication, and audit logging are split across different layers, the control model becomes fragile. Security teams should expect bypass risk whenever developers can attach personal or workspace-level MCP connections outside the governed route.
For practitioners
- Define separate agent and human GitHub roles Use distinct composites or tool sets so an AI agent can open a pull request without inheriting merge or delete capabilities from the developer’s own account.
- Force all approved MCP traffic through one gateway Block direct client-to-server MCP paths wherever possible so filters, upstream authentication, and audit logging apply to the same governed route.
- Inspect tool arguments and returned content Apply filters to repository names, branch names, issue text, and server responses so permitted tools cannot move data outside the intended project or tenant.
- Review alternate AI clients and local MCP setups Inventory Cursor, Claude Code, Codex, and VS Code configurations to find direct GitHub MCP connections that bypass the gateway and its records.
- Treat gateway logs as enforcement evidence Use audit records to verify which tools were called, then reconcile those logs against upstream GitHub permissions and any uncovered client paths.
Key takeaways
- GitHub agents need narrower, explicitly designed tool scopes than the human users who operate them.
- Gateway enforcement only works when all approved clients and MCP paths are forced through the same control plane.
- Filters and audit logs help, but they do not compensate for direct connections that bypass the gateway.
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 | The article centers on narrowing agent tool scope below the human user's GitHub permissions. |
| NHI-10 — Human Use of NHI | Developers keep human permissions while agents operate through separate delegated tool paths. | |
| NHI-03 — Vulnerable Third-Party NHI | The gateway and upstream MCP stack create a third-party trust path that can be bypassed or misused. | |
| Recommendation — Scope agent access to the minimum GitHub tools needed and remove inherited write or delete rights. Separate human GitHub permissions from agent-mediated access and prevent agents from reusing human rights. Validate third-party MCP paths and block unmanaged client routes that circumvent governance. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece is fundamentally about entitlement scoping for delegated GitHub access. |
| Recommendation — Review and constrain GitHub entitlements so agent permissions do not exceed approved task scope. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | MCP access here depends on authenticated upstream and delegated non-organizational access paths. |
| Recommendation — Apply machine and external-user authentication controls to every MCP path that reaches GitHub. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Unauthorized MCP paths can be used to reach broader GitHub resources and move laterally through tools. |
| Recommendation — Map direct MCP bypass paths to credential access and lateral movement in detection and threat hunting. | ||
Key terms
- Composite MCP server: A composite MCP server is a single Model Context Protocol endpoint that exposes multiple tools, resources, or data sources through one interface. It aggregates capabilities from several back-end systems and presents them to an AI agent as a unified tool layer, while still requiring careful control of authentication, authorization, logging, and data boundaries.
- Gateway Enforcement: Gateway enforcement is the use of the API gateway as the place where policy is applied before traffic reaches backend services. It combines authentication, rate limiting, quotas, segmentation, and logging so the organisation can control both access and consumption in one place.
- Tool Exposure: Tool exposure is the subset of available capabilities that a model can actually see and invoke during a specific run. It is a security boundary, not just an engineering convenience, because limiting exposure reduces misuse and shrinks the effective attack surface.
- MCP Path: An MCP Path is the address or route used to reach a specific resource, tool, or capability exposed through the Model Context Protocol. In technical terms, it identifies where an AI agent should send a request within an MCP server or connected environment, helping control access, routing, and tool selection.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 16, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org