Tools to Set an Approved List of AI Agents and MCP Servers Across All Your Endpoints

No single built-in setting does this for every agent. Claude Code, GitHub Copilot, Codex, and Cursor each let admins push an MCP server allowlist to developer machines, and you should use them. But each one covers only its own agent, uses its own format, and controls only what that agent loads as an MCP server. To keep one approved list across every agent and MCP server on every laptop, including agents nobody approved, you need a layer on the endpoint that recognizes agents and checks what they do. That is what Qpoint does. Most teams end up using both.

What an approved list has to cover

• Agents. Claude Code, Cursor, Copilot, and Codex, but also open source agents, IDE extensions, and agents developers build themselves.
• MCP servers. Remote servers reached over the network, and local servers that run as a command on the laptop.
• Every machine. macOS, Windows, and Linux, on and off the corporate network.
• Proof. What is actually running, and a record each time something off the list shows up, with the user and machine.

The options and their limits

1. Each agent's own admin settings

As of October 2026, the major coding agents all have some form of managed MCP allowlist:

• Claude Code. Admins can deploy a fixed set of MCP servers with a managed-mcp.json file, or an allowlist and denylist (allowedMcpServers and deniedMcpServers) that match servers by URL or by exact command. These are delivered through MDM or server-managed settings, and allowManagedMcpServersOnly stops users from adding to the list.
• GitHub Copilot. Enterprise owners set allowedMcpServers and deniedMcpServers in a managed-settings.json file, enforced in the Copilot app, Copilot CLI, and VS Code. GitHub's older registry-based allowlist matches on server name only, and GitHub notes it can be bypassed by editing configuration files.
• Codex. Admins publish a requirements.toml through a system file, macOS MDM, or the admin console. Codex enables an MCP server only when its name and its command or URL match an approved entry.
• Cursor. On the Enterprise plan, admins list allowed MCP servers by command or URL in the team dashboard.

Good fit: your developers use one or two of these agents, and you want a control in place this week.

Limits:

• One agent at a time. Each agent has its own file, format, and matching rules, and you maintain each list separately.
• Only agents that ship these controls. Many open source agents and most custom agents have no admin settings at all.
• No control over which agent runs. Locking down Claude Code doesn't stop a developer from installing a different agent and connecting any server to it.
• MCP only. The list controls which MCP servers the agent loads, not what it does through its shell. An agent with no approved database server can still run psql. An agent blocked from an API can write a script that calls it and run that instead.
• No fleet view. Each agent reports usage, if at all, through its own telemetry.

2. MDM and application control

Jamf, Intune, Santa, and EDR application control can block specific programs, or allow only signed, known ones.

Good fit: blocking a desktop app or a specific binary outright.

Limits:

• Many agents and most local MCP servers run as scripts under Node or Python, started with npx or uvx, or inside an IDE as an extension. Rules that work by binary either miss them or would block Node and Python for everyone.
• It is all or nothing. It can't allow Claude Code but only with approved MCP servers.
• It doesn't know which processes are agents.

3. MCP gateways and private registries

A gateway or registry gives developers a catalog of approved remote MCP servers and routes their traffic through one place, with authentication and logging.

Good fit: managing access to remote MCP servers your company runs or pays for.

Limits:

• It only covers servers configured to go through it. A developer or an agent can still connect to a server directly.
• Local MCP servers run as a process on the laptop and never touch the gateway.
• Laptops off the corporate network may not route through it.

4. Config file scans

Some tools and scripts read agent config files on each machine, such as ~/.claude.json, .cursor/mcp.json, and VS Code settings, to list the agents and MCP servers developers have set up.

Good fit: a first inventory, to find out how big the problem is.

Limits: it shows what is configured, not what runs. It misses agents that don't use a known config file, and it doesn't enforce anything.

5. An agent-aware layer on the endpoint (Qpoint)

Qpoint is a single binary that runs on each laptop, between the agents and the operating system. It recognizes agents by how they behave, not from a list of known binaries, and it sees every file, command, and network connection they make, including those of the processes they start. That makes one approved list possible for every agent:

• Approved agents and versions. Define which agents, harnesses, and versions are allowed. Anything else is flagged the moment it starts, with the user and host, and your team can stop it on that machine or across the fleet.
• Approved MCP servers and tools. An allowlist of servers, and the tools agents can call on them, checked on every connection. A local MCP server is a command the agent starts and a remote one is a network connection, so Qpoint sees both, however the agent was configured.
• The same list for every agent. The rules are applied underneath the agent, so Claude Code, Cursor, Codex, open source agents, and custom agents all get the same checks. You don't rebuild them when a new agent ships.
• Scripts count. Processes the agent starts count as the agent. If it writes a script to reach a service that isn't approved, the script's requests are tied back to that agent and session.
• Rules the agent can't reach. Policy runs in a separate process, outside the agent.
• Off the network too. Policies are enforced on the laptop, so they still apply on home networks and planes.
• Violations with context. Each violation comes with the agent, version, user, host, session, and the events leading up to it, and can go to your SIEM.

See Qpoint Govern for the full list of policies you can set.

Good fit: more than one or two agents in use, agents nobody approved, or a need to show auditors what is running and what was blocked.

Limits: it is software you install on every endpoint, usually pushed through the MDM you already use.

Qpoint doesn't replace the agents' own settings. Where an agent has managed MCP settings, turn them on. Qpoint is the layer that covers every agent the same way and checks what actually happens.

Questions to ask any tool

Several newer endpoint products also target AI agents. Whatever you evaluate, ask:

• Does it find agents it has never seen before, or only ones on a list?
• Does it see local MCP servers, or only remote ones?
• Does it enforce on the laptop before the action completes, or report afterward?
• Does it cover what the agent's scripts and child processes do?
• Does it still work off the corporate network?
• Can a developer or the agent get around it by editing a config file?
• Can you start in observe mode and turn on enforcement later?

How to roll out an approved list

1. See what is running first. Start with a pilot group in observe mode and find out which agents and MCP servers people actually use, by team.
2. Write the first list from that. Start with the agents and servers people already depend on, not from guesses.
3. Turn on each agent's managed settings where they exist, matching servers by URL or command rather than by name.
4. Push the policy to the pilot group, then the fleet. With Qpoint, policies are staged and versioned like code, and take effect without touching agent config or restarting anything.
5. Review violations regularly. Add what should be approved, and give developers a clear way to request a new agent or server.

Qpoint runs on macOS, Windows, and Linux, and deploys through Jamf, Intune, a script, or the Qpoint installer. There are no wrappers, proxies, or changes to how developers work. The control plane and event stream run in your environment, and Qpoint never sees your data. More on rolling out to laptops is on the endpoints page.

Frequently asked questions

Can't we just use Claude Code's managed settings? If Claude Code is the only agent your developers use, its managed settings are a good control and you should turn them on. They don't cover other agents, and they don't control what Claude Code does through its shell or the scripts it writes.

Do MCP allowlists stop an agent from reaching systems we haven't approved? Not on their own. They control which MCP servers the agent connects to. The agent can still run command-line tools or write a script that calls the same system. Covering that means checking what the agent and its processes actually do, on the machine.

What about agents nobody approved? Agent settings can't help with an agent you don't know about. Qpoint recognizes agents by behavior, so an unapproved agent is flagged as soon as it starts, with the user and host.

Can Qpoint block, or only report? Both. You can start in observe mode, then block actions that break policy, such as connecting to an MCP server that isn't approved or reading credential files, before they complete. See Qpoint Secure.

What happens when a laptop is off the network? Policies are enforced on the laptop. Events are stored locally and sync when it reconnects.

See it on your fleet

Book a demo and we'll show you one approved list of agents and MCP servers applied to every agent on a laptop, and walk through how it would roll out to your endpoints.

Related Articles

• How to Control Which MCP Servers Developers Add to Their Coding Agents