What MCP is and why it needs governing
Model Context Protocol is how an AI assistant gets hands. Without it, an assistant can only produce text. With it, it can read your files, query your database, open issues, fetch web pages, send messages.
That is also the entire security problem in one sentence: MCP is where a language model stops talking and starts acting.
Two kinds of server, two ways to govern
Local servers run as processes on the developer's own machine, started by the AI tool itself. The Gateway never sees them — they never touch the network Sentilai is on. These are governed by the Sentilai shim, installed by the Endpoint Suite.
Remote servers are reached over HTTP. These can be governed centrally by pointing the tool at a Sentilai routed endpoint instead of at the server directly.
There is also a third, weaker signal: the AI tools declare the MCP tools available to them inside their chat requests, which the Gateway can see even without the shim. That is enough for inventory and for coarse policy, but not for per-tool decisions.
What can go wrong
- A server nobody reviewed, installed by one developer, with access to everything.
- A server whose tool descriptions change after you approved it — the "rug pull".
- A perfectly good set of servers that together give an agent private data, untrusted content and a way out at the same time.
Sentilai addresses all three: an inventory with an approval gate, schema fingerprinting to notice changes, and the lethal-trifecta detector for the combination.
Where to start
Run with MCP default action: Report for a week. Then look at MCP Inventory and be surprised. Almost every organization finds at least one server they did not know about.