What an MCP server really is
From the model's side, an MCP server is a list of named tools with descriptions. From your infrastructure's side, it is a process holding an API token, a database connection, a filesystem path, or all three.
The model never sees the credential, which is the design working correctly. It also means the model's view of a tool tells you nothing about that tool's authority, so the review has to happen on the infrastructure side.
Check these before connecting one
Every item here is answerable before the server goes anywhere near production, and each one has produced a real incident somewhere.
- What credential does it hold, and what scope does that credential actually carry
- Which of its tools write, and which of those writes are irreversible
- Does it read anything the agent's user is not entitled to read
- Where does its code come from, and who can publish an update to it
- Does it make outbound network calls, and to where
- Are tool calls logged with arguments, somewhere outside the server itself
Tool descriptions are untrusted input
The model decides which tool to call by reading the tool's name and description. Those strings come from the server.
A third-party server you did not write therefore gets to put text directly into your model's context on every turn. That is an injection path, and it is the one people miss because it does not look like data.
Aggregate authority is the number that matters
Each server reviewed on its own usually looks reasonable. The exposure is the union: one server reads your documents, another posts externally, a third holds a cloud credential. The agent can reach all three in one turn.
So the review is of the whole set, not of each server in isolation. Read your documents plus post externally is an exfiltration path that neither server contains on its own, and no per-server review will show it to you.
What this looks like as a service
CyberArc's AI and agent security work includes review of MCP server and tool permissions alongside prompt injection testing, because the two questions only make sense together.
agent-permission-graph, which maps what AI agents and MCP servers can touch, is public on GitHub, so you can see the approach before engaging anyone.