MCP Broker Administration

Learn how AI agent access is governed by entitlements, how AI-initiated activity is attributed and audited, and how to enforce use of the MCP Broker.

This feature is part of the Secure AI offering. If it is not enabled for your organization and you would like it to be, please contact your StrongDM/Delinea representative for more information.

Overview

The MCP Broker is a Model Context Protocol (MCP) server built into the StrongDM client that lets desktop AI agents (Claude Desktop, Claude Code, Codex, and other MCP-compatible agents) reach StrongDM-protected resources over their native protocols. For end-user setup and usage, see MCP Broker for Desktop AI Agents.

This page covers what the Broker means for administrators:

• How agent access is governed and audited
• How to identify AI-initiated access in your logs
• How to write policies that control what AI agents can do
• How to make the Broker the only MCP path on managed devices

MCP Broker Versus MCP Gateway

These are different features with opposite traffic directions. The MCP Broker converts an agent's MCP tool calls into native protocols (for example, PostgreSQL, SSH, Kubernetes, and so forth) for resources behind StrongDM proxies. The MCP Gateway resource type proxies traffic to upstream MCP servers. This page covers the Broker only.

Requirements

• StrongDM client version 53.22.0 or later on user endpoints (version 53.56.0 or later for Microsoft SQL Server and MongoDB support)
• Users entitled to the target resources through your standard workflows
• For AI agent identification and policy conditions, enablement by StrongDM during the technical preview

How Agent Access Is Governed

The Broker adds no new authorization surface. Agent access is governed by the same server-side controls as human access through the StrongDM client:

• Entitlements: An agent can only see and act on resources its user is already entitled to. Unauthorized resources never appear in the agent's resource listings. There are no separate agent entitlements to configure.
• Credential-less proxying: Resource credentials are injected by the StrongDM proxy. They are never exposed to the agent, the user, or the client.
• Server-side enforcement: Entitlement checks, policy evaluation, and auditing happen on StrongDM nodes (gateways, relays, and proxy clusters), not on the client. Editing local configuration cannot grant access to a resource that is only reachable through StrongDM.
• No standing infrastructure: The Broker runs inside the StrongDM client on each user's machine. You do not host, patch, or scale any HTTP MCP servers, and there is no per-resource MCP configuration.

Because of this, no additional admin configuration is required to let entitled users use the Broker. Users configure their agent to launch the Broker (sdm mcp), and their existing entitlements apply. The controls described in the rest of this page are optional and additive for security and auditing purposes.

Enforcement of the Broker as the Sanctioned MCP Path

The Broker's MCP server is defined in each agent's local configuration file (for example, claude_desktop_config.json or ~/.cursor/mcp.json), which users can edit. Editing that file cannot grant access to StrongDM-protected resources. The mechanisms that do that, such as entitlements, credentials, and policy, are not housed in the client. It does, however, let a user remove the Broker or add other, unsanctioned MCP servers to their agent.

For managed fleets that want the Broker to be the only MCP path, deploy the AI vendors' managed-configuration files with your endpoint-management (MDM) tooling. Two things must both be true for this to hold: the managed configuration lives at a root/admin-owned path, and users do not have local admin rights.

The AI vendors themselves describe these client-side managed settings as controls, not security boundaries, on unmanaged devices. Treat them as defense-in-depth on top of StrongDM's server-side enforcement, not as a substitute for it. The examples below are current as of July 2026; validate against each vendor's current schema before deploying to a fleet.

Claude Code

Claude Code

Deploy a managed-mcp.json to the system path. When present, Claude Code loads only the MCP servers it defines, and users cannot add others.

• Linux/WSL: /etc/claude-code/managed-mcp.json
• macOS: /Library/Application Support/ClaudeCode/managed-mcp.json
• Windows: C:\Program Files\ClaudeCode\managed-mcp.json

{
  "mcpServers": {
    "sdm-listener-mcp": {
      "command": "sdm",
      "args": ["mcp", "--acknowledge-experimental-status"],
      "env": { "SDM_APP_DOMAIN": "app.strongdm.com" }
    }
  }
}

Verify on a managed endpoint: claude mcp list shows only sdm-listener-mcp, and claude mcp add is rejected while the enterprise configuration is active.

Claude Desktop

Claude Desktop

Claude Desktop reads managed policy from the macOS preference domain com.anthropic.claudefordesktop and the Windows registry key HKLM\SOFTWARE\Policies\Claude.

Keep local MCP servers enabled in that policy. Disabling them disables the Broker too. Claude Desktop does not currently offer a per-server MCP allowlist equivalent to Claude Code's managed-mcp.json, so on Claude Desktop, rely primarily on StrongDM's server-side enforcement and on AI agent policies.

ChatGPT CLI/Desktop

ChatGPT CLI/Desktop

This is formerly "Codex".

Deploy a requirements.toml (hard constraints users cannot override) that restricts MCP servers to the Broker:

# /etc/codex/requirements.toml (Unix)
# %ProgramData%\OpenAI\Codex\requirements.toml (Windows)

[mcp_servers.sdm-listener]
identity = { command = "sdm" }

For ChatGPT Business/Enterprise tenants, the same requirements can be assigned centrally per user group from the admin console, which takes precedence over local files.

Monitoring

• Watch the managed config paths with file-integrity monitoring (osquery, EDR) and alert on changes.
• The strongest circumvention signal is network-level: alert on any connection to a protected resource that did not traverse a StrongDM node. If resources are reachable only through StrongDM and hold no client-resident credentials, that signal is enforced regardless of client configuration.

Questions and Feedback

This is a Technical Preview. If you encounter issues or have feedback, please reach out to the StrongDM Product team directly.