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.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “Cursor and Obot: Secure MCP Access Without Giving Up Developer Choice”.
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.
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.
Q: How should security teams decide which GitHub tools an agent may use?
A: Start from the task, not the human role.
Practitioner guidance
- 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.
Bottom line: GitHub agents need narrower, explicitly designed tool scopes than the human users who operate them.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
16/09/2026 9:21 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Governed MCP access for AI agents in GitHub: what changes