MCP Server Trust Review

Review provenance and capability before connection

Confirm who publishes and operates the server, where its source or build comes from, how updates are signed or reviewed, and whether the endpoint or package matches the expected identity. Inventory the files, network destinations, APIs, tenant data, credentials, and external actions the server can reach under the actual runtime identity.

Review every exposed tool rather than trusting names or annotations. Determine whether it reads, writes, deletes, communicates externally, spends money, changes authorization, or operates across tenants. New tools must remain disabled until reviewed; a server update can change the effective capability even when the connection name stays the same.

Record the trust decision

For remote servers, validate HTTPS, authorization-server metadata, audience-bound tokens, least-privilege scopes, redirect handling, and secret storage. For local servers, inspect the executable and launch arguments, then constrain filesystem, process, and network access. Never pass through a client token to an unrelated downstream service.

Server and version: [IDENTITY, VERSION, DIGEST/COMMIT]
Publisher/operator: [OWNER, OFFICIAL SOURCE]
Deployment: [LOCAL PROCESS | REMOTE ENDPOINT]
Update path: [SOURCE, REVIEW, PINNING, ALERT]
Runtime identity: [USER/SERVICE PRINCIPAL]
Filesystem/process/network access: [ALLOWLIST]
Data classification and retention: [DATA -> POLICY]
Credential storage and scopes: [CAPABILITY, NOT SECRET]
Issuer/audience validation: [EXPECTED VALUES AND TEST]
Tool inventory: [NAME -> EFFECT, APPROVAL, IDEMPOTENCY]
Resources/prompts reviewed: [ITEM -> TRUST STATUS]
Logging and redaction: [EVENTS, EXCLUSIONS, RETENTION]
Failure/timeout behavior: [OBSERVED RESULT]
Containment: [SANDBOX, RATE LIMIT, DISABLED-BY-DEFAULT]
Decision: [APPROVE | APPROVE WITH CONDITIONS | REJECT]
Approver and expiry: [OWNER, YYYY-MM-DD]
Rollback: [DISABLE, REVOKE, REMOVE, RESTORE]
Evidence: [SOURCE REVIEW, TRACE, TEST, CHANGE ID]

Expected evidence and verification

The expected evidence is a time-bounded decision tied to a specific server version or digest, exact endpoint, reviewed capability inventory, runtime identity, data policy, and containment test.

Verify denied scopes and destinations with safe probes, confirm tokens are audience-bound and absent from logs, exercise an approval-required tool without approving it, and confirm newly discovered tools stay disabled. Test disconnection, credential revocation, and recovery of dependent workflows. Re-review after any server, owner, endpoint, tool inventory, scope, or data-flow change.