Bringing Anthropic’s Claude to the organization doesn’t mean bringing in a single tool. Business users work in Claude on the web and Claude Desktop. Developers spend their time in Claude Code, in the terminal or their IDE. Teams tag Claude in Slack.
As usage grows, employees want Claude connected to the systems they work in, and requests for access to GitHub, Jira, Salesforce, and data warehouses start coming in. At this point, admins and security teams feel pressure to allow access while still keeping it governed. Organizations need to know which tools Claude should see, who should get them, and what data is allowed across the connection. Afterward, they need to be able to show what happened.
Each Claude client is going to behave a little differently. What you want to stay the same, no matter which client someone picked up that day, is the access policy, such as who can reach what, what’s allowed through, and the record of what happened. Getting there takes a combination of Claude’s own controls and making sure the connections you care about go through one place.
What Claude gives you
Anthropic has built real controls here, and if you have Claude in your organization you should be using them. The gateway approach later in this post builds on Anthropic’s controls and extends them.
Connectors. On Team and Enterprise, Owners add approved MCP servers as organization connectors. Either members authenticate to each one themselves, or, with managed authorization, an admin authorizes the connector once for the org. If someone signs in to Claude Code with their claude.ai account, those connectors show up there automatically, so one connector configuration covers Claude on the web, Claude Desktop, and Claude Code.
Tool policy. Admins set Always allow, Needs approval, or Blocked per connector or per tool. Anthropic’s connectors help article shows the tools grouped by type, such as read-only tools and write/delete tools. The settings apply to everyone using the connector, and users can’t override them. This org-wide policy is the ceiling, and it also applies in Claude Code, where blocked tools are filtered out before Claude sees them.
Custom roles. On Enterprise, you can attach custom roles to groups synced from your IdP and narrow connector access per role, down to individual tools. Anthropic’s example is a role that can only use Jira’s search_issues. Roles can narrow the org policy but never widen it. Role-based connector permissions are enforced in Claude Code too, and they combine with Claude Code’s managed settings so the more restrictive answer wins. They don’t cover MCP servers a member runs locally.
Claude Code managed settings. Admins can push a fixed set of MCP servers (managed-mcp.json), provide servers alongside the user’s own (managedMcpServers), and enforce allowlists and denylists by server URL or command (allowedMcpServers, deniedMcpServers, allowManagedMcpServersOnly). With OpenTelemetry export turned on, Claude Code can report which MCP servers and tools were called.
Logging. Enterprise has audit log exports and a Compliance API that covers Claude chats, Cowork, and Claude Code in one audit trail, with each session attributed to a user. On Team and Enterprise, Cowork sessions can also send OpenTelemetry events for each tool call, including the tool name, success or failure, and timing. With content capture turned on, those events also carry the parameters and the MCP server name.
For a baseline Claude deployment, add approved servers as org connectors instead of letting people wire up their own. Set write and delete tools to Needs approval or Blocked unless a group clearly needs them, and use custom roles to keep each group’s connectors and tools narrow. In Claude Code, lock MCP to an allowlist with allowManagedMcpServersOnly. Then turn on OpenTelemetry export for Claude Code and Cowork, and pull the Compliance API into your SIEM.
Where it gets harder
hose controls cover a lot of ground. Here’s where admins tend to run out of room.
The decision is per tool. Claude’s policy decides whether a tool is allowed, needs approval, or is blocked. It doesn’t look inside the call. If get_file_contents is allowed, it’s allowed for any repo the upstream credential can reach. Claude’s policy can’t restrict it to your org’s repos, and it can’t redact a customer’s phone number from a tool result before it goes back to the model.
Local servers sit outside connector permissions. Role and connector permissions govern org connectors. An MCP server a developer runs locally isn’t covered by them. In Claude Code, local servers are governed by managed settings, which have server allowlists and denylists plus permission rules that can allow, ask for, or deny specific MCP tools (mcp__<server>__<tool>). Those policies are separate from the connector permissions you set in claude.ai, and they’re maintained per client.
Session audit and tool-call detail live in different places. On Enterprise, the Compliance API gives you one audit trail across Claude chats, Cowork, and Claude Code, with every session tied to a user. Detailed tool-call data comes from OpenTelemetry, which Claude Code and Cowork export separately. It includes success or failure, and it includes parameters when content capture is on. For Claude, that’s a solid setup once both are wired into your SIEM. What Claude’s logging can’t show you is the same GitHub server being called from Cursor or Codex, which is the next problem.
Claude isn’t the only client. Most organizations also have Cursor, Codex, Copilot, or something new a team just picked up. Policy you set in the Claude admin console only governs Claude. The same GitHub server reached from Cursor needs its own controls set up separately.
Try Obot today — the open-source MCP gateway. Self-hostable, MIT licensed, full audit trail at every tool call.
A gateway sits between Claude and your MCP servers. Instead of adding GitHub directly as a connector, you add the gateway’s endpoint. Users sign in to the gateway with your IdP, and the gateway decides what they have access to, holds or brokers the upstream credentials where configured, inspects the traffic, and logs the calls that pass through it.
Claude’s controls keep handling the user experience, approval prompts, which connectors are visible, and Claude Code’s local permissions. The gateway owns who gets which tools, what’s allowed through them, and the audit trail. Since that lives outside Claude, it applies the same way to every Claude or non-Claude client whose connections go through the gateway. Anything that connects to a server directly, like an MCP server a developer adds by hand in Claude Code, isn’t covered. That’s why the Claude Code lockdown and visibility pieces below matter.
Here’s what that looks like with Obot and GitHub. Claude’s custom roles can divide tools by group inside Claude, and that’s worth doing. Doing it at the gateway means the same tool sets apply to any other client connected to the endpoint, and it adds argument-level filtering on top.
Two audiences, two tool sets
In Obot, a virtual MCP server (vMCP) exposes one or more upstream MCP servers through a single gateway endpoint. Each upstream server is a component, and the component configuration sets the upper limit on what a vMCP can expose. You can disable tools there, and rename them or change their descriptions. Profiles then grant some or all of those tools to specific users or IdP groups. Everyone connects to the same URL and gets only the tools their profiles grant.
This example uses one vMCP, Engineering GitHub, with the GitHub MCP server as its component. merge_pull_request and delete_file are disabled at the component level, so no profile can grant them. Two profiles sit on top. Read Only is granted to the managers and auditors groups. Development is granted to the developers group and adds the tools to create a branch, push changes, and open a pull request.
A developer might have permission to merge in GitHub, but Claude can’t merge on their behalf through this vMCP because the tool is disabled before any profile sees it. Upstream authorization still applies, so the gateway can narrow what the GitHub credential allows but never expand it.
Profiles only add access. If someone is in both the managers and developers groups, they get the Development tools. A narrower profile can’t take away a tool another profile grants, so put hard limits like the merge restriction in the component configuration, not in a profile.
One caveat is that a tool set only works as a boundary when each tool does one narrow thing. A general-purpose tool that can both read and write doesn’t become read-only by being left in the Read Only profile. Leave it out, filter it, or use an upstream credential that can’t write.
Looking inside the call
Tool selection controls what Claude can call. Filters control what gets through a tool that’s allowed.
Obot’s PII filter can block or redact the PII types you configure, such as email addresses and phone numbers, in MCP messages before they go on to Claude or the upstream server.
Custom filters can check arguments. Say the company’s GitHub org is acme. A get_file_contents call carries the owner in its arguments, like this.
A custom MCP filter can reject any call where owner isn’t acme. The same approach works for validating branch names or replacing an argument with an admin-defined value. get_file_contents stays available, but only for repos that meet your rules.
One record
MCP calls routed through Obot show up in Obot’s audit logs with the user, server, operation, time, and status. Full request and response payloads are restricted to the Auditor role. Calls through the vMCP from Claude on the web, Claude Desktop, and Claude Code all end up in the same place, alongside calls from any other client connected to the same endpoint. Direct client connections and other Claude activity, like sign-ins or chats without tool calls, aren’t in this log. Those stay in Claude’s own audit logs and telemetry.
Getting it into Claude
Add the Engineering GitHub endpoint as one organization connector in claude.ai. It carries over to Claude Code for anyone signed in with their claude.ai account. In this example the connector uses individual OAuth, so each user signs in to Obot with their own IdP identity and gets the tools their profiles grant. Other setups, like managed authorization or shared credentials, change how that sign-in works.
Layer Claude’s tool policy on top if you want it. For example, set write tools to Needs approval so developers confirm before Claude pushes.
In Claude Code, put the Obot URL on the allowlist, set allowManagedMcpServersOnly, and deny direct GitHub MCP URLs so the governed path is the only one Claude Code will load.
Seeing past the gateway
A gateway only governs traffic that goes through it. If someone adds a GitHub MCP server directly in Claude Code or Claude Desktop, it never touches Obot.
Obot Sentry is part of Obot’s device management, which is currently in beta. It inventories AI clients, MCP servers, skills, and plugins on enrolled Windows and macOS machines, including Claude Code and Claude Desktop. Sentry’s inventory helps you find the direct connections, so you can decide which should move through the gateway and where to tighten Claude Code’s managed settings. For Claude Code, Codex, and Cursor, Sentry also has experimental tool-call enforcement against an allowlist, which Obot doesn’t yet recommend for production.
What you end up with
People use whichever Claude client fits the work. Admins use Claude’s own controls for what each client shows and how it behaves. The gateway holds the access policy, the filters, and the audit trail for every connection routed through it, whether the connection comes from Claude on the web, Claude Code, or a Claude Tag session in Slack that uses the Obot endpoint. Claude Code’s managed settings help keep connections on that path, and Sentry helps you find the ones that aren’t.
When Anthropic ships the next Claude surface, or a team picks up a different client alongside Claude, you point it at the same endpoints and the policy is already there for those connections.
If you’re using Claude today, you can run Obot Community Edition free for up to 100 users and 100 devices, or use Obot Cloud if you’d rather not run the infrastructure.
