Skip to main content
MCP Restrictions cover — connectors by permission, not by default. MCP servers extend what an AI agent can do: read your ticketing system, query a database, call an internal API. Each one widens what the agent can reach, and most arrive because a single developer added a few lines to a config file. AgenShield lets you decide, for the whole fleet, which MCP servers are acceptable.

​
Choosing a posture

MCP restrictions use the same three modes as every other part of your policy, set per fleet in the Frontegg Portal, under AgenShield → MCP servers (https://portal.frontegg.com/<environment>/agen/shielded/mcps): Monitor never changes anything on a developer’s machine. It reports what would be blocked so you can see the impact before committing. This is where a rollout should start. Enforce is approve-only. Any MCP server that is not explicitly approved is refused — which is what you want if your goal is “our agents use our approved servers and nothing else”. Move to it once Monitor shows you the real inventory.
Move one step at a time and read the reported activity between steps. Going straight to Enforce on a fleet you have not inventoried will block servers developers are actively using.

​
Approving and blocking individual servers

The Frontegg Portal lists every MCP server seen across the fleet, with where it was found and which agent used it. From there you can approve a server, block it, or block individual tools inside a server that is otherwise fine — useful when one destructive tool is the only problem.

​
Approving a server nobody has used yet

The list above only shows servers the fleet has actually run. To approve one ahead of time — so it works the first time someone tries it, instead of being refused — name it directly:
  • By address, for a server your agents reach over the network: the hostname it is served from, optionally with a port.
  • By package, for a server that runs locally on the developer’s machine: the package it is published as, written as npm:<package>, pypi:<package>, or oci:<image>. Naming the package is the only way to approve a local server in advance, because it has no address to name.
Approving by package covers every way the same server can be started. A developer who writes the package name with a version tag, or starts it through a different package runner, is running the same approved server and is treated that way. This also means an unapproved server cannot get in by borrowing an approved one’s name in a config file — what is checked is the package that actually runs, not the label a developer typed next to it. Entries are matched exactly, not as patterns. Approving npm:@example/server approves that package and nothing else — there is no way to approve a whole publisher or a whole domain at once, because that would hand approval to anything later published under the same name.
Blocking always wins. If a server is approved by package or address and also blocked in the list above, it stays blocked.
A blocked tool call is answered with an error the agent shows to the user, rather than a dropped connection. Agents retry dropped connections and report them as network flakiness; an error tells the developer what actually happened.

​
Using only your organization’s MCP gateway

If your organization runs an MCP gateway, you can require the fleet to use it:
  • Allow adds the gateway to the approved list. Developers point their agents at it themselves.
  • Provision also writes the gateway into the agents’ managed configuration, so a newly set-up machine has a working approved server without anyone configuring anything.
Either way the gateway is always permitted, so turning on approve-only mode can never block the gateway you told everyone to use.

​
Servers that are not in any config file

An agent can reach an MCP server without that server appearing in a config file — for example, by making the requests directly. Restrictions that only read config files miss exactly this case. When restrictions are enforcing, AgenShield inspects the agent’s own network traffic and recognizes MCP conversations wherever they occur, including to servers it has never seen before. This requires network inspection to be set up for your organization; without it, restrictions still apply to servers declared in configuration files.
Some servers cannot be inspected — a server that rejects inspection (for example, one that pins its own certificate) is allowed through rather than having its connection broken, and only the destination name is recorded. A server reached that way is reported but not blocked. If you need certainty for a specific destination, restrict it with a network policy as well.
Two things are deliberately left alone:
  • Anything that is not an MCP conversation. Agents fetch documentation, install packages, and talk to source control over the same connections. Only requests recognized as MCP calls to a server you have not approved are refused; ordinary traffic to the same destination is untouched.
  • The agent’s own required services. An agent’s model endpoint and its update and sign-in services are never blocked by MCP restrictions, even if an MCP server happens to be hosted on the same destination.
An agent’s built-in web search and page fetching are performed by the agent vendor’s service, not by the agent on your machine, so MCP restrictions do not affect them.

​
Preventing developers from adding unapproved servers

Restrictions can also be applied to the agent’s own configuration. When enabled, AgenShield keeps the agent’s managed settings aligned with your policy, so the agent itself declines to load servers you have not approved — rather than the server loading and being removed afterwards. When a developer adds a server that is not approved and enforcement is on, the entry is removed from the configuration and the event is reported in the Frontegg Portal, so you can see who is asking for what and approve it if it is reasonable.

​
What you will see

  • A report for every MCP server found, including which machine and which agent, and whether any credentials were embedded in its configuration.
  • A record of blocked attempts, so a developer’s “it stopped working” has an answer.
  • Would-be blocks while in Monitor, which is your rollout preview.