July 28, 2026 · 9 min read

The MCP security review: what enterprise buyers ask about Model Context Protocol in 2026

Two years ago, Model Context Protocol was a line in your architecture diagram that reviewers skimmed past. Not anymore. MCP, introduced by Anthropic in late 2024 and since adopted across the major model providers, became the default way agents reach tools. Enterprise security teams noticed. If your product connects agents to anything through MCP, expect the review to ask about it by name.

This guide covers the questions that come up, why the reviewer asks each one, and what evidence answers it. It assumes you already know the general shape of an enterprise AI review. If not, start with the 20 AI security review questions enterprises ask vendors and come back.

Why MCP gets its own section now

MCP standardizes tool discovery and tool calling over JSON-RPC. That is exactly what makes it useful, and exactly what worries a reviewer. The protocol lets an agent load tool definitions at runtime from servers your customer has never audited. The agent then acts on whatever those definitions say.

The failure modes are public and well documented by now. Tool poisoning: a tool description carries hidden instructions that steer the model. Rug pulls: a server changes a tool definition after it was approved. Injection through results: a tool returns content that the model treats as instructions. Confused-deputy problems: a server holds broad credentials and performs actions the end user was never entitled to. None of this requires an exotic attacker. A single compromised or careless third-party MCP server is enough.

Reviewers know all this because their own internal teams are wrestling with the same protocol. So the questions are specific.

Question 1: which MCP servers are in the deployment, and who vets them?

This is the inventory question, and it comes first. The reviewer wants a list: every MCP server your product ships with or connects to, who publishes it, what tools it exposes, and what data flows through it. Third-party servers get treated like subprocessors. Internal servers get treated like code.

The evidence that closes it: a maintained server inventory with a vetting step before any server is added, plus a statement of what happens when a server changes its tool definitions. If your platform pins or re-validates tool definitions instead of trusting whatever the server sends today, say so. That single control answers the rug-pull follow-up before it is asked.

Question 2: what stops a poisoned tool from acting?

A system prompt that tells the model to be careful is not a control, and reviewers have stopped accepting it as one. What they want to see is an enforcement point between the agent and the tool: something that inspects each call, applies policy, and can refuse.

Concretely: per-tool allow and deny rules, argument inspection before execution, a human-approval gate for consequential actions, and filtering of which tools the agent can even see. A denied tool that never appears in the agent's tool list cannot be talked into use by a clever prompt. If your enforcement lives in a gateway rather than in each agent's code, the answer is stronger, because it holds for every agent, including the ones you add later.

Question 3: where do the credentials live?

Most MCP servers need credentials for the systems behind them. The review probes three things: whether the model can ever see a raw secret, how broadly each credential is scoped, and how long it lives.

The pattern that passes: secrets injected at a boundary the model never crosses, scoped per tool, short-lived where the upstream API allows it, with issuance and use logged. The pattern that fails: an API key in an environment variable that every tool call can reach and that has not rotated since the pilot. We wrote more about why the shared-credential architecture fails reviews in the fintech AI security review guide, and the same logic applies to MCP deployments in any vertical.

Question 4: can you show us what the agent actually did?

Every MCP question eventually lands here. Discovery, policy, and credentials are preventive. The reviewer also wants the detective control: a complete record of every tool call, with the arguments, the decision, and the result, in a form that holds up later.

An application log in your own database is a weak answer, because you can edit your own database. A tamper-evident record, hash-chained so any change breaks the chain, is the strong answer, and it converts several questionnaire rows at once. The hierarchy of what reviewers accept is its own topic, covered in what evidence buyers actually accept.

Where Daylite fits

Daylite is a self-hosted gateway that sits at the MCP tool-call boundary. Each tools/call passes a secret scan, a PII scan, a classification check, and per-tool policy before it runs, and every decision lands in an append-only, hash-chained, signed audit log a reviewer can verify offline. That is one architectural answer to questions 2 through 4. It is not the only one, and it does not replace vetting your servers or scoping your credentials. If you are building the enforcement and evidence layer yourself, the questions above are still the spec your reviewer will hold you to.

FAQ

Written by Dmitrii Karataev. Twenty years in infrastructure and security. Corrections welcome: hello@daylite.ai.