Notifications
Clear all
Topic starter
16/09/2026 9:21 am
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.
NHIMG editorial — based on content published by Obot: how to use Cursor and Obot to limit what AI agents can do in GitHub
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.
Questions worth separating out
Q: What breaks when an MCP gateway is not the only path to a tool?
A: Policy becomes partial instead of authoritative.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Obot's walkthrough on governed MCP access for GitHub agents →
MCP gateway controls for GitHub agents: are your permissions scoped?
Explore further
16/09/2026 9:21 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Governed MCP access for AI agents in GitHub: what changes
