What changes when a model can call tools through an MCP server?

The tempting answer is to review the server description and trust the client to call the right tools. That answer is not useless, but it is too vague to operate. MCP security is the review of server trust, authorization, token handling, tool scopes, prompt-injection exposure, request destinations, logs, and approval paths for MCP-connected agents. The useful review asks what a compromised prompt could make the server do.

Generated hand-drawn illustration of an agent policy gate routing read, write, and external actions.

Direct answer

MCP security is the review of server trust, authorization, token handling, tool scopes, prompt-injection exposure, request destinations, logs, and approval paths for MCP-connected agents. The useful review asks what a compromised prompt could make the server do.

The common mistake

The sharper operating question is:

Where this gate sits

MCP security sits between agent orchestration and the systems the MCP server can touch. It should run before adding a server, when scopes change, and after any incident involving tool calls.

Signals to capture

SignalWhat to inspectGate action
Server trustPublisher, host, transport, update pathApprove or isolate
Token audienceWho token was issued forReject mismatch
Tool scopeRead/write/admin/side effectMinimize by task
Prompt injection pathExternal data becomes model contextDeny instruction inheritance
Network destinationMetadata, callbacks, fetched URLsConstrain and log

Running example

A local MCP server offers file search and file write tools. The safe version keeps search read-only, scopes writes to a project directory, blocks hidden path traversal, logs every file path, and asks for human approval before any publish or deploy action.

Implementation checklist

  • Inventory each server by owner, transport, update path, and reachable systems.
  • Reject token passthrough and validate audience at the MCP server boundary.
  • Separate read, write, admin, and external-send tools.
  • Constrain outbound request destinations before OAuth metadata discovery or remote fetches.
  • Test indirect prompt injection against the tools the server exposes.

What changes in production

In a demo, MCP security can look like a reviewer preference. In production, it has to become a branch in the agent runtime.

The branch is simple: if the system sees “Publisher, host, transport, update path”, it should approve or isolate. If it sees “Who token was issued for”, it should reject mismatch. If it hits “A server accepts broad or upstream-issued tokens without audience validation”, the run should not continue as if nothing happened.

For MCP security, that is the difference between a content checklist and a control gate. The gate changes the next action while the run is still alive.

What to log in the trace

  • mcp_server_id
  • tool_name
  • tool_side_effect_class
  • token_audience_valid
  • destination_policy_result
  • approval_required

Review packet

A reviewer, on-call owner, or future incident review should be able to answer three MCP security questions from the packet:

  1. What evidence triggered this MCP security gate?
  2. What action did this MCP security gate allow, deny, retry, or escalate?
  3. What would have happened if the MCP security gate had been absent?

For MCP security, the packet should point directly at the trace fields above and the specific signal row that caused the decision. If the packet only says “agent requested approval” or “policy failed,” it is not yet operational evidence.

When to escalate

  • A server accepts broad or upstream-issued tokens without audience validation.
  • A tool can reach internal network resources or arbitrary URLs.
  • Tool descriptions hide side effects.
  • The client cannot produce an incident-ready trace for restricted calls.

Frequently Asked Questions

What is MCP security?

MCP security is the set of controls that make MCP-connected tools safe to expose to agents: server trust, token validation, scope minimization, prompt-injection handling, destination limits, logging, and approvals.

Is MCP security only about OAuth?

No. OAuth and authorization are part of it, but the full review also includes server behavior, tool side effects, network destinations, local-server risk, audit logs, and approval gates.

What is token passthrough?

Token passthrough is the anti-pattern of accepting a client token and forwarding it downstream without validating that it was issued for the MCP server. It weakens accountability, auditability, and control enforcement.

The Takeaway

An MCP server is not just another connector. It is an execution surface, so security review has to follow the tool call all the way to its side effect.

Sources