MCP Security Review Checklist: How to Assess Tool-Connected LLM Systems
A security checklist for MCP servers, clients, OAuth flows, tokens, tools, permissions, trust boundaries, logging, and blast radius.
Start With The Boundary
MCP security is not only about whether a Model Context Protocol server works.
It is about whether the system can safely connect LLMs and AI agents to real tools, real credentials, real APIs, real files, and real business actions.
The security review needs to answer:
If the agent, prompt context, MCP server, tool description, OAuth flow, or tool output is manipulated, what can the system access or change?
Official MCP security guidance describes MCP-specific attack vectors and best practices for developers, server operators, and security professionals evaluating MCP implementations. It specifically discusses risks such as confused deputy behavior, authorization flow weaknesses, token passthrough, SSRF, session hijacking, local server compromise, consent handling, state validation, and scope minimization.
Why MCP Changes The Security Model
MCP is useful because it standardizes how AI systems connect to tools and data. That same standardization creates a high-value trust boundary.
Before MCP, a chatbot might only answer questions.
With MCP, the system may be able to:
- Search files.
- Query databases.
- Create tickets.
- Send messages.
- Modify records.
- Read code.
- Trigger workflows.
- Call internal APIs.
- Run local tools.
- Connect to third-party SaaS platforms.
That means MCP should be reviewed as an execution and authorization layer, not just an integration detail.
MCP Security Review Goals
A practical MCP review should determine:
| Question | Why It Matters |
|---|---|
| What MCP clients exist? | Each client may have different trust and authorization assumptions. |
| What MCP servers exist? | Each server introduces a tool and data boundary. |
| What tools are exposed? | Tool descriptions and schemas become part of model decision-making. |
| What credentials are used? | Tokens determine real blast radius. |
| Who authorizes actions? | User consent, per-client consent, and server-side authorization must be explicit. |
| What can be read or modified? | Tool scope determines business impact. |
| What is logged? | Response and remediation require traceable artifacts. |
| What actions require approval? | High-impact operations need deterministic gates. |
1. Build The MCP System Inventory
Start with an inventory.
| Component | Example | Review Question |
|---|---|---|
| MCP client | AI assistant, IDE agent, internal workflow agent | Who controls the client and what trust level does it have? |
| MCP server | SaaS connector, local filesystem server, database server | What does the server expose to the client? |
| Tool | search_docs, send_email, update_customer, run_query | What can the tool actually do? |
| Credential | OAuth token, API key, service account, local secret | Is access scoped to the user, tool, tenant, and action? |
| Data source | CRM, GitHub, Google Drive, internal DB, filesystem | What sensitive data can be exposed? |
| Runtime | Local machine, container, serverless, internal service | What network, file, and process access exists? |
If the organization cannot produce this inventory, the MCP environment is not ready for production.
2. Map Trust Boundaries
MCP systems usually cross multiple trust boundaries.
At minimum, diagram this path:
User
-> AI Client / Agent Runtime
-> MCP Client
-> MCP Server
-> Tool Implementation
-> Third-Party API / Internal Service / Local Resource
Then mark where the following cross boundaries:
- User instructions.
- System/developer instructions.
- Tool descriptions.
- Tool parameters.
- Tool output.
- OAuth tokens.
- API keys.
- Retrieved data.
- Local files.
- Logs.
- Approval events.
The highest-risk areas are usually where natural language crosses into structured action.
3. Review OAuth And Authorization Flows
Authorization is one of the most important MCP review areas.
Official MCP security guidance describes the confused deputy problem in MCP proxy servers, where static client IDs, dynamic client registration, consent cookies, and missing per-client consent can allow malicious clients to obtain authorization codes without proper user consent.
Review these items:
| Control | Review Question |
|---|---|
| Per-client consent | Does each MCP client require explicit user approval? |
| Redirect URI validation | Are redirect URIs exact-match validated? |
| OAuth state | Is state cryptographically random, single-use, and validated? |
| Token scope | Are tokens scoped to the minimum required resources/actions? |
| Token lifetime | Are tokens short-lived where possible? |
| Token storage | Are tokens encrypted and server-side protected? |
| User attribution | Can every action be tied to the correct user? |
| Service accounts | Are service credentials avoided or heavily constrained? |
The review should verify that authorization happens outside the model. The model can request an action, but deterministic code must decide whether it is allowed.
4. Identify Token Passthrough And Credential Hazards
Credential misuse is where MCP risk becomes operationally serious.
Look for:
| Hazard | Why It Matters |
|---|---|
| Token passthrough | Downstream services may receive tokens outside intended trust boundaries. |
| Long-lived API keys | Compromise creates durable access. |
| Shared service accounts | Actions cannot be tied to individual users. |
| Overbroad OAuth scopes | One compromised workflow can access too much. |
| Credentials in tool output | The model may expose or reuse secrets. |
| Local secret access | Local MCP servers may access files or environment variables. |
A safe design minimizes the number of places where credentials exist, scopes each credential tightly, and avoids giving the model visibility into secrets.
5. Review Tool Descriptions And Schemas
Tool descriptions are not just documentation. They are model-facing instructions.
Review:
| Item | Risk |
|---|---|
| Tool name | Ambiguous names can lead to wrong tool selection. |
| Tool description | Malicious or misleading descriptions can influence behavior. |
| Parameter schema | Loose schemas allow unsafe parameters. |
| Allowed values | Missing allowlists increase abuse potential. |
| Return values | Tool output may be interpreted as trusted context. |
| Error messages | Errors may leak sensitive paths, IDs, or secrets. |
A safe MCP tool should have a narrow purpose, strict schema, clear input validation, and minimal output.
6. Classify Every Tool By Action Impact
Not all tools are equal.
Use a matrix like this:
| Tool | Action Type | Data Touched | Impact | Required Control |
|---|---|---|---|---|
docs.search | Read | Internal docs | Medium | Authorized retrieval and logging |
crm.update_contact | Write | Customer records | High | User-scoped auth and confirmation |
email.send | External communication | Email recipients/content | High | Draft-first or approval |
github.create_issue | Write | Engineering workflow | Medium | User attribution and rate limits |
shell.execute | Code execution | Runtime/filesystem | Critical | Deny or strict sandbox |
billing.refund | Financial action | Customer billing | Critical | Human approval and policy engine |
OWASP's AI Agent Security Cheat Sheet recommends minimum necessary tools, per-tool permission scoping, separate tool sets for different trust levels, and explicit authorization for sensitive operations.
7. Review Destructive-Action Controls
Every MCP system should classify high-impact actions.
High-impact actions include delete, send, publish, deploy, approve, refund, transfer, invite, permission changes, production-data modifications, code execution, and external commitments.
For each action, define:
| Control | Requirement |
|---|---|
| Human confirmation | Required before execution. |
| Policy check | Server-side decision independent of the model. |
| Scope check | Tenant, user, role, and resource validation. |
| Replay protection | Prevent repeated or stale execution. |
| Logging | Preserve prompt, parameters, authorization, and result. |
| Rollback | Define whether the action is reversible. |
A prompt should never be the only thing standing between an agent and a destructive action.
8. Treat Tool Output As Untrusted Input
Tool output can poison the next step.
| Tool Output Source | Risk |
|---|---|
| Webpage fetch | Hidden or visible hostile instructions. |
| Ticket/email body | Attacker-controlled content enters context. |
| Database field | Stored injection through user-controlled data. |
| API response | Malicious or malformed output influences next tool call. |
| Log output | Prior execution traces become instructions. |
| Retrieved document | RAG poisoning or instruction injection. |
OWASP's prompt injection guidance calls out agent attacks such as thought/observation injection, tool manipulation, and context poisoning.
The system should label tool output as data, not instruction. It should also constrain how tool output can influence subsequent tool calls.
9. Review Local MCP Server Risk
Local MCP servers deserve special scrutiny.
They may have access to:
- Local files.
- Developer credentials.
- Shell commands.
- Browser sessions.
- SSH keys.
- Source code.
- Local databases.
- Clipboard or editor context.
- Environment variables.
Review whether local MCP servers:
| Check | Question |
|---|---|
| File access | Are readable paths restricted? |
| Command execution | Are commands allowlisted or blocked? |
| Startup behavior | Can configuration load untrusted servers? |
| Secret exposure | Can the server read .env, keys, tokens, or credentials? |
| User consent | Does the user understand what the server can access? |
| Logs | Are local actions recorded and reviewable? |
For enterprise use, local MCP servers should be treated like privileged endpoint software.
10. Validate Logging And Auditability
MCP systems should log enough to reconstruct actions.
Minimum useful event fields:
| Field | Purpose |
|---|---|
| User ID | Who initiated the workflow. |
| Client ID | Which MCP client was used. |
| Server ID | Which MCP server handled the request. |
| Tool name | Which tool was invoked. |
| Tool parameters | What the model requested. |
| Authorization result | Whether policy allowed it. |
| Approval event | Whether human confirmation occurred. |
| Downstream API target | What service/resource was touched. |
| Result | Success, failure, partial completion. |
| Trace ID | Correlates prompt, retrieval, tool call, and result. |
Logs should be redacted, access-controlled, and retained according to the sensitivity of the workflow.
Sample MCP Security Checklist
Use this as a starting checklist before MCP reaches production.
| Area | Review Question | Pass Criteria |
|---|---|---|
| Inventory | Do we know every MCP client, server, tool, and credential? | Complete system inventory exists. |
| Authorization | Does each client require explicit consent and scoped authorization? | Per-client consent and exact redirect validation. |
| Tool scope | Are tools scoped to minimum necessary actions? | Read/write/delete/send/execute separated. |
| Credentials | Are tokens short-lived, scoped, and protected? | No broad service tokens exposed to the model. |
| Destructive actions | Are high-impact actions gated? | Confirmation and server-side policy required. |
| Tool output | Is tool output treated as untrusted data? | Output cannot override system/developer instructions. |
| Local servers | Are local filesystem/shell/secrets constrained? | Strict path/command/secret controls. |
| Logging | Can actions be reconstructed? | Prompt, tool, auth, approval, and result traces preserved. |
| Kill switch | Can risky tools be disabled quickly? | Operational disable path documented. |
What A Good MCP Review Leaves Behind
A useful MCP review should leave the team with a clear inventory, a smaller permission set, and enough traceability to explain what happened after every tool call.
| Deliverable | Description |
|---|---|
| Tool Inventory Matrix | Inventory of tools, permissions, OAuth scopes, credentials, data touched, and allowed actions. |
| MCP Trust-Boundary Review | Analysis of MCP client/server trust, upstream APIs, token flow, session handling, and local-server exposure. |
| Destructive-Action Control Plan | Classification of high-impact actions and required approval, policy, or sandboxing controls. |
| Blast-Radius Map | Clear explanation of what an abused agent/tool path can read, write, modify, delete, send, or execute. |
| Scope Reduction Plan | Practical roadmap for least privilege, allowlists, user-scoped auth, egress limits, and tool-call logging. |
Final Thought
MCP makes tool-connected AI systems easier to build. That is exactly why MCP security matters.
The risk is not that MCP exists. The risk is deploying MCP servers, clients, tools, and credentials without a clear trust model.
Before production, every organization using MCP should be able to answer:
Which tools can this agent use, under whose authority, against which data, with what approval, and with what audit trail?
If the answer is unclear, the MCP environment is not ready.
What TKOResearch Reviews
TKOResearch performs MCP & Tool-Use Blast-Radius Reviews for teams connecting LLMs to production tools, SaaS systems, internal APIs, local resources, or sensitive data.