Governed MCP access for AI agents in GitHub: what changes

At a glance

What this is: This is a walkthrough of how Cursor and Obot separate human GitHub permissions from AI agent tool access through scoped composites, filters, and gateway logging.

Why it matters: It matters because IAM and NHI teams need to govern what agents can do without weakening developer access, especially when multiple AI clients and MCP paths can create uncontrolled tool exposure.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Obot's walkthrough on governed MCP access for GitHub agents

Context

MCP governance is the problem here, not just developer productivity. Once an AI client can reach an MCP server, the real question becomes which tools it can see, which arguments it can pass, and which requests can be inspected or blocked before they reach upstream systems. In identity terms, this is NHI control over an authenticated tool path, with human permissions and agent permissions deliberately kept separate.

The article shows a practical boundary model for GitHub access: the person may keep their normal repository rights while the agent is limited to a narrower composite, filtered in transit, and logged at the gateway. That is a useful pattern because MCP introduces a new control plane layer, but it also expands the number of places where bypass, overexposure, or unreviewed tool discovery can occur.

For IAM and platform teams, the concern extends beyond Cursor itself. If other AI clients can connect directly to MCP servers or authenticate outside the governed path, then policy at one client does not equal policy across the estate. That is a classic NHI governance issue with a new shape: access is no longer only about identities and roles, but about tool surfaces, client pathways, and runtime inspection.

Key questions

Q: What breaks when an MCP gateway is not the only path to a tool?

A: Policy becomes partial instead of authoritative. If developers can connect through other AI clients or direct MCP configurations, gateway controls only cover one route while tool exposure can continue elsewhere. That leaves audit logs, filters, and access scoping blind to the full estate, which is why pathway governance matters as much as tool governance.

Q: Why do MCP tool allowlists still need runtime filters?

A: Because allowlists answer whether a tool exists, not whether a specific request is safe. A permitted tool can still carry dangerous arguments, unexpected repository references, or sensitive content. Runtime filters validate the call itself, which is essential when the same tool can be used for different scopes, different data, or different audiences.

Q: How can organisations tell whether MCP access is actually being governed?

A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token. If logs only show a shared credential or generic server activity, the organisation does not have effective identity governance for the protocol.

Q: Should organisations treat AI client policy and upstream GitHub permissions as the same control?

A: No. They are complementary but different. Client policy decides what the agent can attempt through the governed path, while GitHub permissions decide what the underlying identity can actually do. If teams collapse those layers, they miss bypass paths, overestimate coverage, and fail to see where access is really being enforced.

Technical breakdown

How MCP tool scoping separates human access from agent access

An MCP server advertises a set of tools, but a control plane can selectively re-present only some of them to a given identity or group. In this pattern, the upstream server may support write operations, while the composite exposes only read or request-only actions to certain users. That distinction matters because permission at the human account level does not automatically govern what the agent can invoke through MCP. Tool naming, descriptions, and exposure lists become part of the security boundary, which means governance has to follow the tool surface, not just the repository ACL.

Practical implication: Treat tool exposure as a separate entitlement layer and review it independently from the underlying GitHub permissions.

Why filters are different from allowlists in MCP security

Tool selection decides whether a tool is available at all. Filters decide whether a specific call, argument, or response should be allowed to continue through a permitted tool. That distinction is critical for MCP because a broadly capable tool can still be dangerous when it accepts untrusted arguments, returns sensitive content, or carries prompt-injected instructions. Filters can reject calls based on repository owner, redact sensitive entities, or mutate arguments before invocation. In other words, governance at runtime is not the same as static tool publication, and both are needed when agent behaviour can vary per request.

Practical implication: Use runtime filters for argument validation and content inspection, not just static tool allowlists.

How gateway logs and client inventory change MCP visibility

Gateway logs show what passed through the governed path, including the user, operation, timing, and status. That is useful, but it only covers traffic that actually reaches the gateway. Device-level inventory closes part of the gap by discovering clients, MCP servers, skills, and plugins even when they connect directly. This is especially important in environments where developers use more than one AI client. Without client inventory, security teams may mistake partial gateway coverage for total control, which leaves direct MCP usage outside the review boundary.

Practical implication: Combine gateway audit logs with endpoint discovery so direct client-to-server paths do not remain invisible.

Threat narrative

Attacker objective: The objective is to obtain unintended tool access or data exposure through an AI client path that was not properly governed.

1. Entry occurs when a developer authenticates an AI client to an MCP server and gains access to a tool surface that may be broader than intended.
2. Escalation happens when the client or an alternate MCP path reaches tools or arguments that bypass the scoped gateway and use upstream credentials directly.
3. Impact follows when the agent can access, modify, or disclose repository data beyond the organisation's intended tool boundary.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool exposure is now an identity decision, not just a software distribution choice: In an MCP environment, the security question is no longer whether a client can install a connector, but which tools that connector can actually surface to a given identity. That makes tool publication part of the entitlement model, and it pushes IAM and NHI governance into the same decision surface. Practitioners need to think in terms of tool-scoped access, not client-wide trust.

Gateway enforcement and upstream authorisation solve different problems: The control plane can decide which tools are visible and inspect what passes through, but upstream systems still decide whether the underlying credential can complete the action. That split is useful because it prevents a false sense of protection from one layer alone. The implication is clear: identity governance for MCP must treat presentation, request filtering, and upstream authority as separate controls.

Runtime filtering is the missing middle between static allowlists and downstream denial: Static exposure control limits what an agent can attempt, while upstream systems may still reject what the credential cannot do. Filters fill the gap by validating arguments, blocking sensitive content, and modifying unsafe requests before they leave the control plane. That makes the filter layer a governance control, not just a data-loss feature, and it is where organisation-specific policy becomes enforceable.

MCP bypass is the real governance gap, not MCP itself: The article's strongest warning is that policy applied to one AI client does not govern direct connections from other clients or local configurations. Once developers can use multiple agents or direct server paths, single-client policy becomes partial coverage. That is why the named concept here is governed-path drift: the authorised path looks controlled while alternative paths quietly expand the effective attack surface. Practitioners need estate-wide visibility, not isolated client policy.

Identity lifecycle for AI clients is now part of tool governance: Access reviews, policy changes, and device inventory all matter because the effective MCP estate includes clients, servers, composites, and upstream credentials. The article shows that when one control layer changes, the others do not automatically follow. That means governance programmes have to review the whole path, from client enrolment through tool exposure and auditability, if they want access decisions to remain credible.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how immature tool-level governance still is.
• For a broader control-model view, see OWASP Agentic Applications Top 10 and map MCP paths to runtime trust decisions, not just static connector approval.

What this signals

Governed-path drift: when one AI client is controlled but others are not, the organisation ends up with policy that looks centralised and behaves as fragmented. That fragmentation is a direct threat to NHI governance because the effective control surface is the client, the server, the composite, and the upstream credential together, not any one layer in isolation.

MCP estates need the same discipline that identity teams already apply to privileged access and lifecycle review. If a tool can be exposed, filtered, logged, and bypassed through different paths, then security leaders should measure the whole path, not just the dashboard for the primary client. For a control reference point, CIS Controls v8 remains useful for account management and auditability, while OWASP Top 10 for Agentic Applications 2026 is the more relevant lens for tool misuse and agent behaviour.

The practical signal for programme owners is that endpoint discovery now matters as much as gateway policy. If developers can bring their own clients, then the organisation has to discover those clients, classify their MCP paths, and decide which ones belong behind the governed route. That is where NHI visibility and IAM oversight converge, because access is being negotiated at runtime across multiple software identities.

For practitioners

• Scope tools by audience, not by client trust Publish separate composites for different roles so the agent only receives the tools required for its job, and keep write or delete operations out of read-focused paths.
• Add runtime filters to every permitted tool Validate arguments, repository names, and content patterns before calls reach upstream systems, and reject any request that violates organisation-specific constraints.
• Inventory every AI client and MCP path Compare gateway traffic with endpoint-discovered clients, servers, skills, and plugins so direct connections cannot hide outside the controlled path.
• Review upstream credentials separately from tool exposure Confirm that the credential behind a permitted tool can only perform the operations the organisation is prepared to allow, then reassess after any repository or role change.

Key takeaways

• MCP governance is a tool-surface problem as much as an identity problem, because agents can be shown different capabilities than the human user retains.
• Gateway logs, runtime filters, and upstream permissions each cover a different part of the path, and none of them is sufficient on its own.
• If developers can use alternative AI clients or direct MCP connections, then policy must extend beyond one client or the organisation is only controlling the visible path.

Key terms

• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• AppSec MCP Server: A context-sharing interface that connects application security tools, IDEs, CI pipelines, and policy systems through the Model Context Protocol. In practice, it helps security functions exchange state and guidance in a form that can support automation and inline developer assistance.
• Tool Access Scope: Tool access scope is the exact set of systems, actions, and data an AI agent is allowed to reach. It should be narrow, explicit, and reviewable, because the risk emerges when the agent can transform a prompt into a real-world operation across connected services.
• Governed-path drift: Governed-path drift occurs when policy covers one AI client or connection path, but other clients or direct routes remain outside that governance model. The result is a false sense of control, because the visible path is compliant while the real access estate keeps expanding through unmanaged alternatives.

What's in the full article

Obot's full post covers the operational detail this analysis intentionally leaves for the source:

• Step-by-step GitHub composite setup for separate read-only and development audiences
• Cursor Enterprise policy settings for approved MCP URLs, local stdio commands, and marketplace distribution
• Custom filter examples for repository-owner validation, PII inspection, and argument mutation
• Obot Sentry inventory details for discovering direct MCP clients, skills, and plugins across managed devices

👉 Obot's full post shows the composite design, filter logic, and client inventory path in detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.