MCP Security and Governance: Enterprise Control Map

The dangerous part of MCP is not that an agent can read a document. It is that, once connected to tools, an agent can read a document, decide what it means, call an API and change something you cannot easily unchange. That is a different category of software risk. The protocol makes integration easier; it does not make delegation safe.

I have watched teams approach MCP as a connector problem. They inventory APIs, wire up servers and celebrate when an agent can finally reach the systems it needs. Then security asks the question that should have come first: what exactly is this agent allowed to do, on whose authority, and how will we prove it did only that?

The answer cannot be a policy document. It has to be a control plane.

The mistake: treating an MCP server as a harmless adapter

An MCP server is executable software with access to data or actions. That puts it in the same risk family as every other integration runtime, with an extra complication: an LLM is interpreting ambiguous natural language on the way to the action. Red Hat’s practical risk review identifies authentication and authorisation, supply chain integrity, command execution, prompt injection, tool injection, sampling, logging and vulnerability management as separate issues — not one generic “AI risk”.1 (opens in a new tab)

That distinction matters. A server can have impeccable OAuth and still be unsafe because its tool description can be manipulated. A server can have a clean supply chain and still let a broadly privileged agent delete data without a human gate. Identity is necessary. It is not sufficient.

The first useful move is to stop asking whether MCP is secure. That is like asking whether HTTP is secure. The question is whether this server, this tool, this identity and this action are controlled well enough for the consequence.

The enterprise MCP control map

The map below is the minimum structure I would expect before an MCP estate moves beyond bounded pilots.

Control layer	Decision to make	Non-negotiable control	Evidence to retain
Inventory	What servers and tools exist?	Approved registry with owner, purpose, data class and environment	Server manifest and named business owner
Identity	Which user or workload is acting?	Per-user or per-workload identity; never a shared super-token	Token subject, audience and expiry
Authorisation	What can that identity do?	Least-privilege scopes per tool and action	Policy decision and granted scopes
Delegation	Can the agent perform the action alone?	Human approval for irreversible or high-blast-radius steps	Approval request, approver and action payload
Supply chain	What code is running?	Version pinning, signed releases, dependency scanning and change review	Build provenance and software bill of materials
Data handling	What can enter model context?	Classification, minimisation, redaction and boundary checks	Data-class decision and retrieval policy
Observability	Can you reconstruct what happened?	Correlated logs for prompt, tool selection, parameters, result and policy decision	Trace ID retained to the required period
Operations	Who responds when it fails?	Runbook, kill switch, incident owner and regular access review	Tested response record and review cadence

This is deliberately mundane. Mature security is usually mundane. The point is to make every line of delegation visible enough that it can be questioned, approved and revoked.

Start with a trust boundary, not a diagram of connectors

The first architecture diagram most teams draw has boxes labelled agent, MCP server and CRM. The one that matters has boundaries: user identity, agent runtime, gateway, tool server, target system and audit store.

Put a policy gateway between the agent and the MCP server whenever the server can affect a production system. The gateway is where you can enforce scope, rate, budgets, approval state, target environment and allowed parameters. Do not put those controls inside the agent prompt. A prompt is an instruction; a policy gateway is an enforcement point.

The same principle applies to local servers. A local server can execute on the user’s machine, which changes the blast radius but does not remove it. Run the server with the smallest viable filesystem, network and process permissions. If a task only needs to query a ticket, it should not inherit the ability to spawn shell commands or read a home directory.

Four gates that separate a pilot from production

1. Register every server. If you cannot answer who owns a server, what data it reaches and which agent uses it, it is not production infrastructure. It is a binary with a marketing name.

2. Bind actions to a real principal. The target system should receive a user or workload identity that is attributable and bounded. “The agent did it” is not an identity. It is an excuse for not having one.

3. Classify actions by reversibility. Read-only access, reversible updates and irreversible actions should not share the same approval path. Sending a draft for review is not the same as sending it to a customer. Deleting a test record is not the same as changing a supplier bank account.

4. Make the tool call inspectable. Before a high-risk call, display the selected tool, target object, parameters and proposed consequence. The person approving it should not need to infer the action from a paragraph of model output.

A practical approval policy

Use an explicit matrix rather than vague “human in the loop” language.

Action class	Examples	Default policy	When to relax it
Read	Search, retrieve, summarise, classify	Autonomous within approved data boundary	Rarely; focus on data minimisation instead
Reversible write	Create a draft, add a tag, open a ticket	Autonomous with durable logging and rate limits	After measured accuracy and rollback tests
External commitment	Send an email, publish content, modify a customer record	Human approval per action or approved batch	Only for narrow, well-observed workflows
Irreversible or high-impact	Payment, deletion, privileged access, production change	Human approval and independent system control	Do not relax by default

This makes the right operational trade-off visible. Autonomy is not a badge of maturity. It is a choice to accept a defined failure mode because the cost of review is higher than the cost of the residual risk.

The three failure modes people miss

Tool description injection. A tool’s name and description are part of the agent’s decision environment. Treat them as untrusted input if the server is not tightly controlled. A malicious or compromised server can make an ordinary-looking tool sound like the best option for an unsafe task.1 (opens in a new tab)

Privilege aggregation. Each individual tool scope can look reasonable while their combination is dangerous. An agent that can read customer data, create users and send mail may be able to complete a fraud workflow nobody intended. Review chains of tools, not just each tool in isolation.

Unbounded retries. Security and FinOps meet here. A failed action with a broad retry loop can create thousands of repeated calls, noisy logs and unexpected spend. Put retry budgets and circuit breakers at the gateway. If the agent is confused, it should fail cheaply and visibly.

What to do on Monday morning

Do not start by selecting an MCP marketplace. Start with five rows in a spreadsheet: server, owner, target system, highest-risk action and approval requirement. If any row has no owner or no approval answer, that server is not ready.

Then run the MCP security and governance checklist against the first three servers you intend to deploy. The checklist is deliberately short enough to use in an architecture review and specific enough to expose hand-waving.

MCP is useful because it makes tool integration composable. That same composability makes ungoverned privilege compound quickly. The winning architecture is not the one with the most servers. It is the one where every server can explain, in one trace, who asked, what was allowed, what happened and how to stop it next time.

Read the Model Context Protocol strategy insight for the architecture and adoption argument, then use the Agentic AI Patterns framework to decide where an agent should act at all.