The Obot MCP Gateway Bug Is the Agent-Security Checklist Writing Itself

The Obot MCP gateway advisory is the kind of bug that should get printed out and taped to every agent-platform design review. Not because Obot is uniquely careless, but because the failure mode is exactly where the industry is currently rushing: a tool gateway hid a restricted connector in the UI, checked authorization during one flow, then let any authenticated user with the server ID call the tools anyway.

That is a classic direct-object-reference bug wearing a 2026 costume. In a normal web app, it might expose records a user should not see. In an agent platform, it can expose capabilities backed by stored OAuth credentials: HR updates, time-off requests, ticket creation, file writes, internal lookups, and any other operation an MCP server makes callable. The advisory’s sharpest sentence is the one engineers should keep: the blast radius is bounded by “everything the platform's stored OAuth/API credentials can reach.”

GitHub rates the issue critical. The advisory says the vulnerable endpoint was /mcp-connect/{mcp_id}, confirmed in Obot v0.21.0 and patched in v0.21.1. Any authenticated Obot user with a role at or above Basic, no user interaction required, could connect through the gateway if they knew an MCP server ID. The endpoint did not enforce Access Control Rules, so the user could list tools and make tool calls even if they were not in the MCP Registry or group meant to access that server. The reporter-estimated CVSS 3.1 score is 9.3; GitHub’s advisory API record reports 9.6 with low attack complexity, low privileges required, changed scope, high confidentiality impact, and high integrity impact.

That is not an obscure edge case. That is the security checklist writing itself in red ink.

UI hiding is not access control, especially when agents can call the endpoint directly

The intended flow, according to the advisory, did include authorization. A user connects to an MCP URL through Obot. During callback, after login, Obot checks whether the user has access to the provided resource. The UI also correctly does not show the restricted server in connector pickers for a Basic User outside the allowed group. The problem is that the gateway route that actually mattered — the one accepting JSON-RPC tool requests — did not enforce the same Access Control Rules.

This distinction matters because agents do not use your product only through the UI you designed. The advisory explicitly notes that the exploit works through Claude Desktop, Claude Code, or any MCP-aware client by configuring the gateway URL as a remote MCP endpoint with the user’s API key. In other words: once an endpoint is reachable, the practical client surface is every agent harness, desktop app, CLI, and integration that speaks MCP. The browser picker being correct is nice. The gateway authorizer being wrong is decisive.

Security teams already know the principle: authorize at the resource boundary, not just at discovery time. But MCP raises the stakes because the “resource” is not merely a record. It is a callable tool backed by upstream authority. A restricted HR MCP server is not just a page of employee data. It may include updateEmployee or submitTimeoffRequest. A ticketing MCP server is not just a list of issues. It may create tickets, modify priorities, comment as a service account, or pull internal incident context into a prompt. A file server may read and write. A browser tool may navigate signed-in sessions. The permission check has to happen where the tool call is made, every time.

Server IDs are identifiers, not secrets

The exploit condition — knowing an MCP server ID — should not comfort anyone. IDs leak. They land in local configs, screenshots, logs, docs, stack traces, Slack messages, agent transcripts, onboarding examples, copied JSON blobs, and “temporary” debug output that lives forever. If a platform’s security depends on an ID remaining obscure, it is already broken.

The right posture is to assume server IDs are public identifiers. The gateway should still ask: who is the caller, which organization or workspace are they in, which registry grants access, which Access Control Rule applies, which client is connecting, which scopes are allowed, which tool is being invoked, and what upstream credential is about to be used? If any of those answers changes between tool discovery and tool invocation, the invocation should fail closed.

The MCP authorization specification frames protected HTTP MCP servers as OAuth 2.1 resource servers, with protected resource metadata, authorization-server discovery, and least-privilege scopes. That framing is useful, but it does not save an application that skips its own authorization check at the gateway. OAuth can authenticate a principal and issue tokens. It cannot magically infer your registry membership rules, group grants, tool-level policy, or whether a shared service credential should be usable by a Basic User outside the intended group.

This is where agent platforms need to stop treating MCP as “plugin plumbing” and start treating it as an authorization concentrator. The gateway is not a neutral pipe. It is the place where human identity, agent identity, upstream credentials, tool schemas, JSON-RPC calls, audit logs, and business impact meet. That is an access-control boundary, not a convenience layer.

What teams should do now

If you run Obot, the immediate action is simple: patch to v0.21.1. Then do the work the patch cannot do for you. Inventory every MCP server behind the gateway. Classify each one by capability: read-only docs/search, low-impact internal data, write-capable business systems, file access, browser access, production-adjacent APIs, identity systems, HR/finance, and anything with broad service credentials. The advisory’s impact depends on what the stored OAuth/API credentials can reach, so start there.

Next, review logs for unexpected /mcp-connect/ usage, especially tools/list and tools/call requests from users outside the intended registries. If your logs cannot answer “which user called which tool, with which arguments, through which client, on behalf of which upstream credential, and why was it allowed,” that is not just a logging gap. It is an operational blind spot. Agent actions compress intent, context, and side effects into one loop; audit trails need to survive that compression.

Rotate or narrow upstream credentials where they were broad. Prefer per-user upstream tokens where practical. Where shared service credentials are unavoidable, put a policy layer in front of the tools. Do not let a shared token become a skeleton key simply because MCP made it easy to expose a useful server. Separate low-risk agent tools from high-impact systems. A documentation search server and an HR write server should not live behind the same casual default registry with the same approval expectations.

For platform builders, the design rule is blunt: every path to tool invocation must revalidate authorization. Not just OAuth callback. Not just connector discovery. Not just the UI. Not just “does this user have an API key?” The check belongs on the gateway route that lists tools and the route that calls tools. Tool-level scopes should exist. Write tools should be distinguishable from read tools. Approval policies should attach to high-impact actions. Server IDs should be untrusted input. Direct HTTP tests should be part of the security suite, because agents are very good at finding the path that bypasses your nice UI.

The broader lesson is that agent convenience and agent authority need to be separated. Developers want one assistant connected to everything because that is genuinely useful. Security teams should resist the shape where one authenticated user session can drive every connector with ambient authority. Use narrower registries. Use disposable or least-privilege credentials. Require approvals for write tools. Keep browser-state tools out of the same trust bucket as documentation search. Treat MCP configs like code, not bookmarks.

My take: this advisory is not a niche Obot story. It is a preview of the bugs every agent gateway will have unless teams design for direct tool invocation from day one. MCP makes agents useful by turning software into callable tools. That also means every MCP gateway is now part API gateway, part authorization server, part audit system, and part blast-radius manager. If your security model is “the connector was hidden in the UI,” request changes. Hard block. Do not merge.

Sources: GitHub Advisory Database — GHSA-vw82-7fv8-r6gp, Obot repository advisory, Obot v0.21.1 release, MCP authorization specification