Loki Intelligence — Security Briefs · Published July 4, 2026

MCP Security Testing Checklist

Model Context Protocol, or MCP, gives AI applications a standard way to connect with tools, data sources, and services. That makes MCP useful for enterprise agents, developer tools, support workflows, and internal automation. It also creates a security boundary that must be tested. An MCP server can expose sensitive resources, powerful tools, misleading tool descriptions, broad OAuth scopes, or unsafe actions through a friendly interface. This checklist helps teams test MCP implementations before they become a hidden path from prompt to production impact.

Method step 01

Inventory every MCP server, tool, and resource

Start with a complete inventory. List every MCP server, transport, exposed tool, resource, prompt template, connected API, backing service, environment, and owner. Record which tools are read-only, which can modify state, which can access secrets, and which can reach customer, financial, production, or internal data.

Why it matters: You cannot enforce least privilege on tools you have not mapped. MCP makes integration easier, but ease of integration can hide blast radius. The first security question is simple: if an agent is compromised or confused, what can this server actually do?

Method step 02

Test authorization and scope boundaries

Verify how users authenticate, how consent is granted, how tokens are issued, how scopes map to tools, and whether one user can influence another user's connected resources. For HTTP transports, review the authorization flow, token audience, redirect handling, session binding, revocation, and whether a tool can be called outside the intended user context.

Why it matters: MCP authorization failures can turn an AI assistant into a confused deputy. The agent may believe it is acting for one user while the server accepts authority from another context. Scope design should be narrow, explicit, revocable, and aligned with tool impact.

Method step 03

Review tool descriptions as prompt surface

Tool names, descriptions, schemas, examples, and errors are not just documentation. They become model context. Test whether malicious or confusing descriptions can cause the agent to choose a dangerous tool, leak data, ignore user intent, or treat tool-provided text as a higher-priority instruction.

Why it matters: Agents often trust tool metadata more than they should. A compromised or low-quality MCP server can influence decisions without exploiting a traditional vulnerability. Treat tool text like untrusted input and validate how the client separates instructions from data.

Method step 04

Exercise read, write, and destructive actions separately

Separate tools into read-only, low-impact write, sensitive write, and destructive actions. Test whether the agent can call each class directly, indirectly, repeatedly, or through ambiguous user intent. Sensitive actions should require confirmation, clear target display, policy checks, logging, and in many cases a human approval gate.

Why it matters: Most teams overfocus on whether an agent can answer a question. MCP risk comes from what the answer can trigger. A safe read tool and a dangerous write tool should not live behind the same loose permission boundary.

Method step 05

Check secrets, files, and data minimization

Test whether tools expose secrets, environment variables, credentials, internal file paths, customer records, system prompts, hidden notes, logs, or oversized data blobs. Limit returned fields, redact sensitive values, enforce resource-level access control, and make sure tool outputs do not include data the model does not need for the task.

Why it matters: Data returned to the model can be repeated, summarized, logged, or sent into later tool calls. Minimization is a security control. MCP servers should return the least data required and make sensitive access explicit, observable, and auditable.

Method step 06

Verify logging, replay, and incident response

Log the user, agent, MCP server, tool, arguments, resource identifiers, approval state, result status, and correlation ID for each meaningful call. Test whether security teams can replay a suspicious chain, revoke tokens, disable a tool, rotate affected secrets, and determine which data was exposed.

Why it matters: Without evidence, MCP incidents become guesswork. Logs should answer who asked, what the model saw, what tool was called, what data moved, and which control allowed the action. This is essential for both debugging and incident response.

Method step 07

Validate client-side MCP behavior

The MCP client should clearly present connected servers, tool permissions, sensitive actions, and approval prompts. Test whether the client distinguishes trusted instructions from tool output, warns before high-impact actions, prevents silent server changes, and gives users a way to disconnect or revoke access. Also test how the client behaves when a server returns malformed, oversized, or hostile content.

Why it matters: Server-side controls are not enough if the client overtrusts what it receives. A secure MCP deployment depends on the client making authority visible and preventing untrusted tool output from becoming hidden instructions to the model.

Method step 08

Validate server-side MCP controls

The MCP server should enforce authorization before every tool call, validate arguments, reject unexpected resources, minimize returned data, rate-limit sensitive operations, and keep durable audit logs. Test negative cases, not only happy paths. A tool should fail safely when the agent asks for a resource, action, or field outside the user's approved scope.

Why it matters: Agents are not a security boundary. The MCP server must enforce its own rules even when the model chooses poorly. Strong server controls keep a confused or manipulated agent from turning broad integration access into a production incident.

Primary references

Related briefs

Relevant Loki service: AI Agent Risk Assessment — Private Preview.