Guides / Integration reviewSources reviewed 25 October 2026

MCP security for AI coding agents: a review checklist

Review MCP servers, tool definitions, permissions, credentials, updates, and data flows before connecting them to a coding agent.

For Platform, security, and developer tooling teams

The Model Context Protocol (MCP) connects AI applications to external tools and data. For a coding agent, each server can add a new path to files, services, or credentials. Review that path as an integration with its own owner, permissions, and change history.

This checklist uses the host, client, server, and tool terms described in the OWASP MCP Security Cheat Sheet. It is general deployment guidance, not a statement about Rechazo product capabilities.

Record what the server can reach

For each server, capture:

  • Its owner, publisher, source repository or package, version, and installation method.
  • The tools and resources it exposes, including the arguments each tool accepts.
  • The files, services, data, and network destinations it can reach.
  • The identity and credential scopes it uses, and where those credentials are stored.
  • Whether it runs locally or remotely, how it is isolated, and who reviews changes.

Do not treat a server name, registry listing, or successful installation as a security review. Verify the source and the exact package before use.

Inspect definitions and updates

Read tool names, descriptions, parameter schemas, annotations, and output formats before approval. Tool metadata and returned text can influence an agent. Treat both as untrusted input.

Record the reviewed definition and require a new review when it changes. Comparing definitions can reveal metadata changes; it does not prove that the server's underlying code or behavior stayed the same. Review package changes and runtime behavior as separate questions.

Limit permissions and credentials

  • Give each server only the access needed for its task.
  • Prefer read-only access when writes are unnecessary.
  • Use separate, narrowly scoped credentials instead of sharing broad tokens across servers.
  • Store tokens using an appropriate secure credential mechanism rather than plaintext configuration.
  • Isolate local servers from unnecessary filesystem paths and network destinations.
  • For remote HTTP connections, follow the current MCP authorization and transport requirements and verify the server identity.

The exact options differ by host, transport, and server. Use the protocol specification and your client documentation for configuration details.

Review the action, not only the tool name

Require explicit review for sensitive, destructive, externally visible, or data-sharing operations. Show reviewers the destination and actual arguments. Validate tool inputs and enforce authorization in trusted code that controls the operation; a model's interpretation of a policy is not an access-control check.

Treat output from an approved server as untrusted too. An agent may pass that output to another tool. If the data is sensitive, define which destinations are allowed and how that flow is recorded.

Keep records that do not create a second leak

Record enough to answer who invoked which server and tool, when, under what authorization, and with what result. Redact secrets and avoid storing full prompt or tool payloads unless there is a documented need, access control, and retention policy.

MCP approval checklist

  • Verify the server's publisher, source, package identity, and version.
  • Review every tool definition and its input/output schema.
  • List reachable data, files, services, and network destinations.
  • Reduce permissions and credential scope to the task.
  • Isolate the server and restrict network access where practical.
  • Set a review trigger for server, package, and tool-definition changes.
  • Require action-specific approval for high-impact operations.
  • Check cross-server data movement and redact sensitive records.

Sources

Sources reviewed 25 October 2026. Verify the current specification and host-specific behavior before deployment.

Continue reading

View all guides