A new integration layer, hiding in plain sight
If you are on a security team and MCP is still a vague acronym, this article is the briefing. The Model Context Protocol (MCP) is quietly becoming the standard way AI agents connect to tools and data. Where APIs connect applications, MCP connects agents to capabilities: reading files, running commands, querying databases, calling services.
That makes MCP servers an integration layer — and integration layers are exactly the kind of thing security teams have spent careers learning to govern. The catch is that this one grew up on developer laptops, bottom-up, without the inventory, approval, and audit disciplines we apply to every other integration. The good news: the disciplines transfer directly. You already know how to do this. You just need visibility into a surface you probably cannot see yet.
What an MCP server actually is
An MCP server is a process that exposes capabilities to an MCP client (an AI agent or AI-enabled app). It can be:
- A filesystem server that reads and writes files.
- A shell server that executes commands.
- A database server that runs queries.
- An API connector that calls internal or external services.
- A custom server a developer wrote in an afternoon.
The client — Claude Desktop, Cursor, Claude Code, and a growing list of others — discovers these servers from configuration and can invoke their tools as part of completing a task. The agent decides which tools to call and with what arguments, often without a human approving each step.
That last sentence is the whole security story. You have autonomous software, on a developer machine, invoking capabilities — including filesystem and shell — based on its own reasoning.
The five disciplines MCP needs
Security teams already apply a familiar set of controls to integrations. MCP needs the same five.
1. Inventory
You cannot govern what you cannot see. The first requirement is knowing which MCP servers and clients exist across your fleet, what each can do, and which agents use them. Because MCP config is local and changes often, this has to be continuous, automated, and read-only — discovering servers through process signals and configuration without scooping up secrets or code.
2. Approval
Adding a powerful MCP server should be a decision, not a silent config edit. A governed registry with administrative approval turns “someone added a shell server to their agent” into a reviewable event. High-capability servers — shell, filesystem, database — warrant more scrutiny than a read-only documentation lookup.
3. Policy
Not every agent should reach every tool. Policy expressed by user, agent, device, and resource lets you allowlist specific MCP tools, restrict filesystem and shell scope, and deny unknown servers by default. A contractor’s agent and a platform engineer’s agent should not have identical reach.
4. Least privilege
The principle that governs every other integration applies here with force. An agent that needs to read documentation does not need shell access. An agent that needs to run tests does not need to read .env files. Scoping tool access to the task is the single most effective way to shrink the blast radius of autonomous behavior.
5. Audit
When a review or incident asks “which agent invoked which tool, with what arguments, and under which policy,” you need an answer. Attributed, tamper-evident records of MCP tool calls turn agent behavior from a black box into reviewable evidence.
How to get there without blocking developers
The wrong move is to ban MCP. Developers adopt it because it makes agents dramatically more useful, and a ban just pushes usage underground. The right move mirrors how you deploy any endpoint control:
- Observe. Discover MCP servers and clients, attribute their activity, and learn the real inventory. Most teams find more — and more powerful — servers than they expected.
- Approve and scope. Bring high-capability servers into a governed registry, apply least privilege, and allowlist tools.
- Enforce and audit. Where MCP activity is routed through a control path, block disallowed actions, restrict scope, shield secrets, and record everything.
This sequence keeps developers productive while giving security the inventory, approval, policy, and audit it needs.
Where Cup’n’String fits
Cup’n’String treats MCP as a first-class governance surface. It discovers MCP servers and clients on the workstation read-only, and where activity is routed through its Active Proxy & Shielding path, it can audit tool calls, apply tool allowlists and parameter boundaries, restrict filesystem and shell scope, redact sensitive output, and shield local secrets. A governed MCP server registry supports administrative approval workflows.
See Control MCP Server Access for the workflow, Claude Desktop MCP Security for an environment-specific view, and MCP Is Becoming the New Shadow IT Surface for the strategic case. As always, this is cooperative, proxy-based governance — strongest when MCP traffic is routed through the gateway and paired with host and network controls, and honest about that boundary.
Checklist
- Can you inventory MCP servers and clients across the fleet?
- Can you require approval for high-capability servers?
- Can you allowlist specific MCP tools per agent?
- Can you enforce least privilege on filesystem and shell scope?
- Can you audit MCP tool calls with attribution?
- Can you run the control plane self-hosted?
You already know how to govern this
MCP feels new, but the security work is not. Inventory, approval, policy, least privilege, audit — these are the disciplines you already apply to every integration in your environment. The only thing missing is visibility into a layer that grew up outside your line of sight. Get that visibility, apply the disciplines you already have, and MCP becomes a governed capability rather than the fastest-growing blind spot on your developer fleet.