Skip to content
MCP & Tools 5 min read

MCP security from server inventory to runtime enforcement

MCP servers behave like a supply chain. Learn how to inventory them, authorize them, scope their credentials, apply tool-call policy, and keep evidence reviewers can use.

By Halo Security Engineering

The Model Context Protocol (MCP) is an open protocol, introduced by Anthropic in November 2024, for connecting AI applications to tools and data. An MCP server exposes tools such as searching tickets, reading files, or sending messages. An AI application discovers those tools and lets a model call them.

That convenience creates a supply chain. Each server is code that someone wrote, packaged, and installed. It holds credentials that someone granted, and it responds to a model that reads text from many sources.

MCP security means managing that chain, from the first inventory to each runtime call.

Why MCP servers behave like a supply chain

A software supply chain has sources, versions, maintainers, and dependencies. MCP servers have the same properties and add one more. The model decides which tool to call, and the model's input can include text that a stranger wrote.

Ask these questions about any server before it reaches production.

  • Who wrote and maintains it, and where does it come from, such as a package registry, a vendor, or an internal repository?
  • Does it run on a laptop, on a shared host, or as a hosted service?
  • Which tools does it expose, and do read tools and write tools share one credential?
  • What happens when a new version adds a tool or changes a tool description?

The answers differ for local and remote servers. A local server runs as a process on a laptop or host, with access to local files and to any network that machine can reach. A remote server runs on someone else's infrastructure and holds credentials there.

Local servers call for endpoint and host controls. Remote servers call for a review of the operator and of the data that leaves your boundary.

Treat each MCP server as a dependency with an owner, a version, a credential, and a review status.

Inventory the servers

You cannot secure servers you do not know about. They show up in several places, including IDE and desktop AI app configuration on developer machines, agent runtimes, shared hosts, and gateways.

Halo Endpoint helps with the first of those places. It does metadata-first discovery of IDE plug-ins, developer AI tools, and AI-related configuration files on macOS and Windows, and it records paths, hashes, and permissions as evidence.

Discovery will not find every configuration, so add a rule that agents reach servers through a registered gateway. Servers registered at the MCP and tool gateway give you a known list for the traffic that passes through it.

For each server, record the owner, the source and version, where it runs, the tools it exposes, the credentials it uses, the data it can reach, and its review status.

Authorize before anyone connects

Classify each server as sanctioned, monitored, or blocked, and write down who may use it for which purpose. A server that nobody has reviewed should have no access by default.

Authorization applies to the agent as well as the server. An agent that triages support tickets needs a ticketing server. A file system server on the same agent widens its reach without helping the task.

Keep each agent's list of allowed servers short, and tie it to the agent's identity so changes are visible.

Approval also has a shelf life. A server can publish a new version that adds a tool or changes a tool description. Record the version you approved, and send each new version through review before agents rely on it.

Scope the credentials

MCP servers need credentials to reach the systems behind them. Those credentials tend to land in local configuration files or environment variables, where more people and processes can read them than intended.

Credential brokering keeps the credential at the gateway. In Halo, provider and app credentials stay bound at the gateway, and agents receive scoped capabilities and never see raw keys. Scope each capability to the tools and actions the agent needs.

Separate read access from write access wherever the target system allows it. Revoking a capability at the gateway ends one agent's access without rotating a key on a developer laptop.

Check each tool call against policy

Authorization decides whether a server can be used. Policy decides whether a particular call should go ahead. Policy as code can express rules at the level of the tool, with allow, deny, and alert outcomes and a decision explanation for each result.

For example, a team might allow the read tools on a ticketing server, deny the delete tools, and require human approval before a tool posts to an external channel. Halo's gateways support human approval gates for higher-impact actions, so the call waits until a person decides.

Tool descriptions and tool results are untrusted input. A model that reads a poisoned description, or a result with hidden instructions, may ask for a call it should not make.

Policy evaluated at the gateway checks the call itself, whatever persuaded the model to ask. The glossary entry on prompt injection covers that risk in more detail.

Keep evidence you can review

When an advisory lands for a popular MCP server, the first question is which of your agents use it. When an agent does something unexpected, the questions are what it called and who allowed it.

Record the same fields for each call, listed here.

  • Actor. The agent and the person who delegated the work.
  • Target. The server and tool, plus any arguments you choose to retain.
  • Decision. Allow, deny, or alert, with the policy version and an explanation.
  • Approval. Who approved a gated action, and when.
  • Outcome. What came back, including errors.

Halo records decisions, approvals, denials, costs, and configuration changes, and audit logs and gateway decisions export as CSV and JSON for reviewers.

A checklist to start with

  1. List the MCP servers in use and the agents that connect to them.
  2. Assign an owner and a classification to each server.
  3. Move credentials behind a gateway and scope them per agent.
  4. Write tool-level rules for reads, writes, and deletes.
  5. Add approval for actions with real consequences.
  6. Export a week of decisions and check that a reviewer can follow them.

The MCP governance checklist goes deeper on each step.

How Halo helps

Halo's MCP and tool gateway applies identity, policy, approvals, and evidence to tool calls, and credential brokering keeps credentials at the gateway. Halo Endpoint adds metadata-first discovery of IDE plug-ins, developer AI tools, and AI-related configuration files on macOS and Windows. Read about AI agent governance or book a walkthrough with one server you want to govern.

  • mcp
  • tool gateway
  • credential brokering
  • tool policy
  • agent security
H

Halo Security Engineering

Halo Security Engineering works on agent isolation, credential brokering, runtime policy, and the controls that keep agents safe.

All articles

Put a halo around the AI your business runs.

See discovery, runtime policy, approvals, and evidence working together on your own use cases.