Field guide / MCP assurance
An MCP server is not just a connector. It is a trust boundary that can expose data, invoke tools and move authority between an agent and the systems behind it. Use this checklist before a connection becomes production access.
Confirm who operates the server, pin the version and transport, inventory every tool and resource, require attributable least-privilege identity, classify side effects, constrain egress and secrets, capture an auditable trace, and prove that access can be revoked. If any of those answers is “unknown,” keep the server out of sensitive production paths until the gap has an owner.
Record the canonical repository or operator, release/version, transport, server card, expected tools and the environments in which the server is allowed to run. Do not treat a package name, marketplace badge or tool description as proof of identity.
Use a distinct service identity per environment, narrow permissions at action time, short-lived credentials where practical and an explicit revocation test. A prompt, server card or payment receipt is not identity authentication.
Read typed inputs and outputs, reject unknown or oversized values, label read versus write behavior, make irreversible effects explicit and require preview or independent approval for high-impact actions. Check idempotency before allowing retries.
Keep retrieved content, tool output and user instructions distinguishable. Record provenance for durable writes, prevent untrusted text from silently becoming policy, and review whether an MCP response can influence future authority.
Allowlist destinations and methods, enforce timeouts and payload limits, redact credentials from prompts and logs, and make uploads, webhooks and third-party calls visible. A server that can reach the internet can often reach more than its tool list suggests.
Observe caller, tool, target, result and side effect with a correlation ID. Define fail-closed behavior for timeouts and malformed responses, then prove that an operator can pause the server, revoke identity and recover without duplicating an irreversible action.
A shared, long-lived token or a personal credential grants more access than the single task requires.
A read-looking tool can write, spend, upload, message or alter durable state without an explicit boundary.
Outbound destinations, payloads or third-party calls are not constrained or observable.
The owner cannot identify the running version, stop it quickly, revoke access or reconstruct what happened.
This checklist helps a system owner decide whether an MCP connection is ready for a bounded review. Delx Security can map the evidence to its agentic control baseline and verify authorized behavior, but active techniques wait for written Rules of Engagement and a defined stop path.
Use the broader AI agent security review guide when MCP is one part of a larger agent, application or cloud system.
Start with the five-minute readiness checklist → or read the six-phase assurance method →
Verify the server's provenance, transport, identity model, tool schemas, side effects, approval boundaries, egress, secret handling, logging and revocation path. Treat every exposed tool as an authority boundary until evidence says otherwise.
No. The checklist prepares a safe connection and identifies evidence gaps. Any active testing of an MCP server needs an owner-approved scope and written Rules of Engagement defining assets, techniques, timing and stop conditions.
Read its typed input and output schema, classify read and write effects, test rejection of malformed and out-of-scope inputs in an approved environment, confirm least-privilege credentials and observe a trace that identifies the caller and side effect.
No. It is a preparation and assurance aid. A review can report the tested scope, evidence, limitations, findings and residual risk, but it cannot certify a whole server or guarantee future security.