See how to use Cursor and Obot to limit what AI agents can do in GitHub without taking away developers’ own permissions. I’ll walk through role-specific tool access, filters, audit logs, and how to spot MCP connections that bypass the gateway—even when developers use other AI clients.
Cursor is popular because developers can get productive quickly. Add an MCP server, authenticate, and they are calling tools in minutes.
That works well until the organization realizes it has no idea what agents are accessing its systems. Which tools should an agent see? Who should have access to them? What data can cross the connection?
Cursor and Obot can answer those questions at different layers. Obot is an open source AI control plane that provides security and governance for agent access to resources such as MCP servers. This post walks through one deployment—GitHub access for two audiences—to show where each layer’s control begins and ends.
An organization may decide that a developer can merge code in GitHub while the agent they use in Cursor is limited to opening a pull request. The developer keeps their GitHub permissions, and the agent never receives merge_pull_request through its Obot connection.
Where Cursor Stops and Obot Starts
Cursor Teams provides SSO, team management, access controls, and usage analytics. Team administrators can also distribute MCP servers and plugins through a private marketplace. Cursor Enterprise adds policy for remote MCP URLs and local stdio commands.
Cursor’s tool allowlists determine which tools may run automatically; they do not change the tools advertised by the MCP server. Cursor documents distribution and policy as separate administrative controls.
The Obot control plane sits between Cursor and the upstream MCP server. Users log in to Obot through the company’s identity provider. Obot can then determine which tools they receive, manage the upstream connection, inspect MCP messages, and record gateway traffic.
Comparison matrix
Layer
What it Controls
Where its Control Ends
Cursor Teams
Team identity, marketplace distribution, and developer approval of tool calls
Distribution alone does not prevent personal or workspace MCP configuration
Cursor Enterprise
Allowed MCP URL and command patterns, local-server network access, and automatic tool execution
Does not provide identity-specific tools/list responses or inspect and modify MCP messages
Obot
Tools exposed through a Composite, access to that Composite, upstream authentication, filters, and gateway records
Cannot govern a connection that bypasses Obot
The full path looks like this:
Cursor determines whether the agent can connect and whether a tool call requires developer approval. After the user authenticates to Obot, their identity determines which tools are returned, and each call passes through the gateway’s filters and audit logging.
The dashed arrow is the problem this architecture still has to solve, and we come back to it once the two paths are built.
Two Audiences, Two Composites
Our example starts with the GitHub MCP server from Obot’s catalog. Obot provides several options for connecting to GitHub. We use the standard GitHub MCP server here, but the same approach applies to GitHub Enterprise Server and GitHub Enterprise Cloud.
An Obot Composite MCP server presents selected tools from one or more upstream servers through a single URL. We choose which tools appear and can change the names and descriptions Cursor sees. Each Composite has a fixed tool set, so this deployment needs two. Managers and auditors receive Engineering Read Only. Developers receive Engineering Development, which includes the read-only tools plus the tools needed to create a branch, push changes, and open a pull request. Neither Composite exposes merge_pull_request or delete_file.
We assign the Composites to users or identity-provider groups through MCP Access Policies. Obot’s policy determines whether a user can connect to Engineering Development and receive create_pull_request. When the agent calls that tool, GitHub still evaluates the upstream user or service credential. If the credential cannot access the repository or perform the operation, GitHub rejects the call.
The last two rows are the governance boundary: a developer may have permission to merge a pull request directly in GitHub, but their agent cannot request that operation through either Composite because merge_pull_request was never exposed. Limiting exposure this way reduces excessive permissions, enforces tool-level scopes, and helps protect sensitive tools and sensitive systems.
The GitHub MCP Server’s tool surface may change between releases, but clients only see the tools defined in the Composite. Upstream additions are not automatically exposed. That reduces exposure to unexpected tool metadata changes and rug-pull attacks.
Tool selection is only a boundary when each tool has narrow behavior.
A general-purpose tool that accepts both read and write operations does not become read-only because it appears in Engineering Read Only. Leave it out, reject unsafe arguments with a filter, or use an upstream credential that cannot perform the write operation.
Access rights should be reviewed and audited regularly so roles do not expand unnecessarily, especially because MCP servers aggregate high-value tokens and broker access to internal tools, external tools, enterprise systems, and other data sources.
What Filters Catch That Tool Selection Misses
Choosing the tool set provides broad control over what an agent can call. Filters answer a different question: what should be allowed through a permitted tool, and they are part of security best practices for securing mcp workflows.
Obot’s built-in PII filter can block or redact configured entity types, such as email addresses, Social Security numbers, and driver’s license IDs. Applied to the GitHub Composites, it can inspect issue content, source snippets, and tool results before those messages continue.
Obot filters can inspect an MCP request and server responses. MCP filter servers can accept, reject, or modify a message when mutation is enabled. HTTP webhook filters accept or reject API calls based on their HTTP response.
Our example company uses the GitHub organization acme. A call to get_file_contents includes the repository owner in its owner argument:
A custom MCP filter can inspect that value and reject calls outside acme. The same mechanism could validate branch names or replace an agent-supplied argument with an administrator-defined value. That helps defend against prompt injection attacks and reduces the chance of unintended commands by validating arguments and tool descriptions before tool invocation. These organization-specific controls require a custom MCP filter server or HTTP webhook, which helps protect AI assistants and other AI workloads during runtime.
Every MCP interaction through this path appears in Obot’s gateway audit logs. The record includes the user, server, operation, time, and status. Full request and response payloads are restricted to the Auditor role, and the records can be filtered or exported.
The result is narrower than a tool allowlist: get_file_contents remains available, but only for repositories that satisfy the organization’s rules. Automated guardrails can block risky requests in real time before they exfiltrate data or trigger remote code execution, including cases where agent attempts to reach protected systems violate policy.
/cta – try
Try Obot today — the open-source MCP gateway. Self-hostable, MIT licensed, full audit trail at every tool call.
We publish Engineering Read Only and Engineering Development through Cursor’s Team Marketplace. Each Cursor configuration contains the Obot URL rather than a GitHub credential. The developer authenticates to Obot, Obot checks access to the requested Composite, and the configured upstream connection handles GitHub.
Cursor Teams includes one team marketplace. Cursor Enterprise adds unlimited marketplaces and access gating through identity-provider groups. Cursor’s plugin documentation covers marketplace access and the available installation modes.
Marketplace visibility is useful for showing each audience the relevant integration. It is not authorization. The corresponding Obot policy remains necessary even when only developers can see Engineering Development in Cursor.
Close the Cursor Path with Cursor Enterprise
If the organization already uses Cursor Enterprise, its MCP server configuration can make the Obot URLs the required path inside Cursor, with Obot as the MCP Gateway used to centralize access control. The administrator adds the two Obot URLs as approved entries, turns off user MCP extensions outside administrator-defined URL or command patterns, and selects the appropriate network mode for any permitted local server. Cursor documents these settings under Enterprise MCP controls.
That policy prevents unapproved MCP configurations from running inside Cursor. It does not replace the controls behind the Obot URLs. Using zero trust principles here also reduces each direct entry point and limits how unauthorized users could gain access. Control plane communications should be exposed only through private endpoints and encrypted with TLS, and MCP servers should encrypt traffic using TLS 1.2 or higher. The Composites still determine which tools each audience receives, Obot Access Policies still authorize the user, filters still inspect traffic, and the gateway still records the calls.
Now an unlisted GitHub MCP server cannot run inside Cursor, and every permitted GitHub call follows the controls demonstrated in this example.
See Beyond Cursor with Obot Sentry
Cursor is typically one of the AI clients in use. An organization may standardize on Cursor while developers also use Claude Code, Codex, Visual Studio Code, or another agent for particular workflows. Cursor Enterprise policy governs Cursor, but it does not show what developers have configured in those other clients or whether they connect directly to MCP servers. In practice, organizations focus on verifying every mcp client and agent workflows, not just governing Cursor, to maintain secure access.
Obot Device Management uses Obot Sentry to inventory AI clients, MCP servers, skills, and plugins on enrolled Windows and macOS workstations. This brings direct GitHub MCP configurations into view even when their traffic never reaches Obot’s gateway.
For clients covered by Sentry, the organization gains an audit record of MCP calls and selected client-native actions, including file access and shell commands. Today that coverage includes Cursor, Claude Code, Codex, and Visual Studio Code, and it expands the organization’s visibility beyond traffic routed through the gateway.
We can start with that inventory, compare direct GitHub MCP activity with the two Obot paths, and see how developers are actually working. The organization can then decide which configurations should move through Obot and where further investigation or controls are needed.
Cursor Enterprise keeps Cursor on the governed path. Sentry extends visibility across covered clients and exposes direct MCP usage that gateway logs alone cannot show. That visibility also supports continuous monitoring and incident response across clients beyond Cursor.
What This Buys You
Cursor provides the managed developer experience and, with Enterprise, keeps MCP traffic on the intended path. Managers receive read-only GitHub tools, developers can propose code changes, and neither group’s agent receives merge or delete capabilities through the governed connection. Requests can be checked for sensitive data and organization-specific constraints, while the resulting audit records identify who made each call.
Developers continue working in Cursor, but the GitHub access available to their agents is deliberately narrower, inspected in transit, and attributable afterward. That helps reduce exposure from misconfigurations, unauthorized use, and data leaks; over 50% of MCP servers use static API keys for credentials, so avoid relying on static API keys, especially since every verified MCP server lacked authentication access controls.
You can build both paths on a free tier before committing to it. If you already use Cursor, you can run Obot Community Edition free for up to 100 users and 100 devices. If you do not want to operate the infrastructure, use Obot Cloud.
