MCP Tool Security Checklist for Agent Workflows

Scope the exact connection

Record client, host, user population, server package and version, launch command or remote endpoint, transport, authentication, data classification, tools, resources, prompts, network destinations, filesystem paths, and environments. Review development and production separately. A server safe with a synthetic test account may be unacceptable with customer data or deployment credentials.

Enumerate capability from code and observed behavior, not only the tool descriptions shown to the model. A “read documentation” tool may accept arbitrary URLs; a “manage files” server may invoke a shell; a local process may inherit broad environment variables. The security boundary is the implemented process, identity, and operating-system access.

Apply evidence-based pass and rejection rules

A checklist answer of “supported” is insufficient. Attach repository and release identifiers, configuration extracts, scope lists, test results, architecture diagrams, and named owners. Date the evidence because server versions, dependencies, authorization guidance, and hosted endpoints change.

Verify provenance and the software supply chain

Identify the publisher, maintainers, source, build path, package registry, license, release cadence, vulnerability process, dependencies, and update mechanism. Pin a reviewed version and digest where possible. Inspect installation scripts and runtime downloads. A trusted protocol does not make every server trustworthy.

Prefer reproducible or inspectable builds and narrow dependency sets. Scan artifacts and dependencies, but do not treat a clean scan as proof of safe behavior. Review code paths that access secrets, files, network, subprocesses, dynamic modules, updates, and tool dispatch. Document who approves upgrades and how rollback works.

Trace authorization end to end

Draw user, MCP client, authorization server, MCP server, downstream APIs, and protected resources. For each hop, state which identity acts and which policy is authoritative. Validate token audience and never accept a token intended for another resource. Avoid forwarding a client token through the server to an unrelated downstream service.

Enforce authorization at the server and downstream resource, not only in the client UI or model instructions. Scope tokens by user, task, resource, action, environment, and time. Test revoked, expired, wrong-audience, wrong-user, replayed, and over-scoped tokens. Verify that an attacker cannot register or redirect to an untrusted endpoint through weak metadata or redirect handling.

Keep credentials outside model context

Use a secret manager or credential broker and inject credentials only into the execution boundary that needs them. Do not place secrets in prompts, tool descriptions, returned content, serialized agent state, or routine logs. Redact authorization headers, URLs containing tokens, environment dumps, and downstream error bodies.

Use short-lived credentials and test rotation and emergency revocation. A shared service credential removes user attribution and may give every agent the union of all permissions. If delegation is unavailable, reduce the server’s functions and data boundary rather than pretending the model provides access control.

Review every tool as an API with side effects

Normalize tool name, description, input schema, output schema, data sources, destinations, writes, network calls, subprocesses, and failure behavior. Use enumerations, bounded lengths, canonical identifiers, allowlisted paths and hosts, and server-side business rules. Validate after model generation and again at the execution boundary.

Separate reads from writes and drafts from commits. A tool should not quietly send, delete, publish, purchase, or execute while described as search or preparation. For consequential calls, present normalized arguments and expected effect to a policy engine or human approver. Bind approval to the exact call and expire it.

Constrain local servers

Run local servers under a dedicated low-privilege account or sandbox. Pass an explicit environment rather than inheriting every shell secret. Mount only required directories, use read-only access by default, restrict network egress, cap CPU, memory, process count, file size, runtime, and output, and deny access to sockets or host controls unless essential.

Test path traversal, symlinks, special files, archive expansion, command arguments, environment expansion, and returned binary data in a safe environment. Do not expose an unauthenticated local listener beyond its intended host. Treat output as untrusted data before it returns to the model or user interface.

Constrain remote servers and transports

Use authenticated encrypted transport, validate endpoints and certificates, configure timeouts and payload limits, and review browser-origin protections where applicable. Separate production and test endpoints. Ensure errors do not reveal tokens, internal addresses, stack traces, or sensitive resource contents.

Inventory server-initiated callbacks, redirects, webhooks, and downstream connections. Apply egress policy and DNS protections to arbitrary URL parameters. Remote hosting transfers some operations to a provider but adds dependency, jurisdiction, availability, and incident-coordination questions.

Test prompt injection as a source-to-sink path

Place hostile instructions in documents, web pages, issue descriptions, tool output, and resource metadata. Verify that they cannot expand tool authority, reveal secrets, change destination, or bypass approval. Separate untrusted content from trusted policy and system metadata. The model may summarize data, but data cannot grant permission.

Map each untrusted source to dangerous sinks such as network, file, message, database, shell, identity, or payment actions. Remove unnecessary paths, validate arguments, require approval at consequential boundaries, and preserve evidence for blocked attempts.

Assign a disposition

Document residual risk, compensating controls, owner, expiry, monitoring, and re-review triggers. Re-review after server, dependency, client, identity, scope, transport, host, or data-class changes. A low-risk pilot does not automatically authorize production.

Monitor and prepare response

Log user and service identity, server version, tool and normalized argument class, policy and approval result, destination, external transaction ID, duration, outcome, and error category without storing unnecessary sensitive content. Alert on new tools, scope changes, repeated denials, unusual destinations, secret-like output, execution spikes, and unexpected updates.

Maintain a kill switch that revokes credentials and disables the server or tool route. Practice identifying affected runs, rotating secrets, preserving evidence, restoring known-good versions, notifying owners, and adding regression cases.

Minimum evidence bundle

Retain the reviewed version and digest, owner, capability inventory, data-flow diagram, identity and scope list, configuration, test results, residual risk, disposition, expiry, and emergency revocation steps. A future reviewer should be able to tell whether a changed server is still the artifact that was approved.

Limitations

This checklist cannot prove a server free of vulnerabilities or malicious behavior. Code review, dynamic testing, dependency scanning, architecture review, and monitoring each cover different risks. Hosted servers may limit evidence, increasing residual uncertainty.

Protocol specifications and security guidance evolve. Verify the current MCP and OAuth documents for the implemented version. High-impact systems may require formal threat modeling, penetration testing, legal review, vendor assessment, and separation of duties.

Related guides

Apply the broader agent security checklist, place decisions using human approval patterns, and test behavior through the agent evaluation framework. Use the prompt-injection threat model for web-connected tools.