By Bill Maxwell, Software Architect at Obot AI
Cursor is popular because developers get productive fast. Add an MCP server, authenticate, and you're calling tools in minutes.
That works great until the organization realizes it has no idea what agents are actually accessing. Which tools should an agent see? Who should have access to them? What data can cross the connection? Cursor doesn't enforce SSO, audit logging, or policy control for MCP servers — that layer lives elsewhere.
This post walks through a real deployment example: GitHub access for two audiences — managers and developers — using Cursor and Obot together. Developers keep their full GitHub permissions. Their agents get a narrower, governed set of tools through Obot's MCP Gateway: they can open a pull request, but merge_pull_request and delete_file are never exposed. Requests get inspected for PII and org-specific constraints in transit. Every call is logged.
We cover the full architecture: how Cursor's controls and Obot's controls interact, where each layer's authority begins and ends, how to use Obot Composites to serve different tool sets to different roles, and how Obot Sentry extends visibility to AI clients beyond Cursor — including Claude Code, Codex, and VS Code.
Originally published on Obot AI
Top comments (0)