MCP security and governance

Why MCP is a security surface

Every MCP server is software that runs with real access, chosen and invoked by a model that may be responding to adversarial input. Servers are wired in from public registries, often carry credentials in plaintext config, and are rarely reviewed. Our MCP security explainer covers the threat model in depth.

Where Anomity finds MCP servers

Not every MCP server sits in an agent's config file, so the Endpoint Sensor looks in six places:

• Servers configured in AI agents' own config files, user-level and project-level, across Claude Code, Claude Desktop, Cursor, VS Code and many more.
• MCP packages installed globally with npm.
• MCP packages installed with pipx.
• MCP packages installed as uv tools.
• MCP configs bundled inside IDE extensions.
• Docker MCP Toolkit profiles.

What Anomity tells you about each server

• Trust: official, community or unknown, from vendor, command and fingerprint signals.
• Capabilities: shell execution, filesystem write, outbound network and credential access, plus dangerous combinations on the same device.
• Authentication posture: OAuth, local, or a static secret in the config, so you can require OAuth for remote servers.
• Secrets: credentials in env blocks and headers, redacted on the endpoint. Only the pattern name, location and severity reach the cloud.
• Version and change history: when a server appeared, changed or was removed, on which device.

How MCP servers are governed

An approved-MCP allowlist turns discovery into policy: anything not on it raises a finding, and the console suggests servers already seen on the fleet for one-click approval. Further policies block specific server commands, flag unknown-trust servers with high-risk capabilities, and require OAuth.

At runtime, a call to a tool on an unapproved MCP server can be denied at the agent's pre-execution hook before it runs. Remote MCP servers are also joined against identity and gateway sources where connected, such as Okta AI agents and Cloudflare MCP portals.

What Anomity does not do

• It is not a network proxy or an AI gateway, and it does not read prompts, responses or source code. It reads configuration and metadata.
• Blocking happens at an agent's own pre-execution hook, so it applies to agents that expose one. Agents without a hook interface are discovered and evaluated against policy, but their tool calls are not intercepted.
• The Browser Sensor covers managed Chrome and Edge. AI used in an unmanaged browser is outside its view.
• It complements EDR/XDR, DLP, CASB and your AI gateway rather than replacing them.

Related reading

How to build an MCP server registry, MCP server secrets exposure, OAuth for MCP servers explained and MCP tool poisoning.

Frequently asked questions

How do I find MCP servers installed on employee laptops?

Deploy a sensor that reads AI agents' MCP config files and package installs on each device. Anomity's Endpoint Sensor checks six surfaces, including npm, pipx and uv installs, extension-bundled configs and Docker MCP Toolkit profiles, and reports them to one fleet inventory.

Can Anomity detect hardcoded secrets in MCP configurations?

Yes. Secrets in MCP env blocks, headers and arguments are matched against a credential pattern catalog on the endpoint and redacted before anything leaves the machine. The console shows the pattern, location and severity, never the value.

Can I allow only approved MCP servers?

Yes. The MCP allowlist raises a finding for any server not on it, and on agents with a pre-execution hook a call to an unapproved server's tool can be denied before it runs.

Does Anomity replace an MCP gateway?

No. A gateway governs traffic routed through it. Anomity covers the servers configured on the laptop, including those that never route through a gateway, and works alongside one.

See it on your own fleet. The Endpoint Sensor deploys through the MDM you already run, and the first findings typically arrive within 30 minutes.

Get a demo