MCP security checklist for AI agents in production
An MCP server connects a model to real capabilities. Security therefore depends on a chain of trust, from the installed package to the ability to revoke a compromised credential, rather than one configuration switch.
Detailed checklist
- 1. Inventory the server and its scope
- 2. Limit identities, permissions, and secrets
- 3. Validate inputs, outputs, and destinations
- 4. Put human approval at the right boundaries
- 5. Log, test, and prepare for incidents
- Minimum controls to verify before production
- Frequently asked questions
- Sources and review basis
/1. Inventory the server and its scope
Record the publisher, source, version, transport, and every exposed tool. For each tool, note whether it reads, writes, spends, publishes, or reveals data. That map determines which controls are required.
- Pin versions and review changes before updating.
- Disable tools that are not needed.
- Separate test and production servers and accounts.
/2. Limit identities, permissions, and secrets
Give each agent or environment a distinct identity. A shared token makes attribution and revocation difficult. Store secrets in the runtime's secret manager, inject them at startup, and keep them out of prompts, logs, and versioned configuration.
- Start read-only.
- Limit scopes and token lifetime.
- Test rotation and revocation instead of only documenting them.
/3. Validate inputs, outputs, and destinations
Treat model-generated arguments as untrusted. Validate schema, size, format, currency, market, URLs, and identifiers inside the tool. Inspect responses before returning them to model context so external content cannot become a privileged instruction.
- Allow network domains and destinations explicitly.
- Reject unknown values instead of silently correcting them.
- Redact secrets and personal data from errors.
/4. Put human approval at the right boundaries
Approval is appropriate before spending, publishing, contacting a person, revealing contact details, or performing any irreversible action. The review screen should show the exact action, amount, currency, target, and expiration.
/5. Log, test, and prepare for incidents
Link each MCP call to a request identifier and agent identity. Log the tool, outcome, human decision, and applied policy without storing secrets. Alert on repeated denials, call spikes, new destinations, and budget overruns.
- Test prompt injection, replay, timeouts, double clicks, and unavailable approvers.
- Prepare an emergency stop and credential revocation procedure.
- Retain enough audit data to reconstruct the action.
/Minimum controls to verify before production
| Control | Evidence to verify | Failure signal |
|---|---|---|
| Identity and scope | A dedicated identity and least-privilege tool allowlist | A shared token or tools enabled by default |
| Secrets | Runtime injection, rotation, and revocation procedure | Credentials in prompts, logs, or source control |
| Approval | A server-side rule for financial or irreversible actions | The model can bypass the approval path |
| Audit | Request IDs, actor, tool, decision, and outcome | A transaction cannot be traced end to end |
/Frequently asked questions
Is a trusted MCP server enough to secure a client?
No. The client still needs explicit consent, safe token handling, validated redirect flows, tool visibility, and controls against confused-deputy and prompt-injection risks.
Should an MCP client store a bearer token in its configuration file?
Prefer a secret store or runtime injection. If local storage is unavoidable, restrict permissions, exclude the file from source control, and document rotation and revocation.
What should block a production launch?
Block launch when sensitive tools lack least privilege, approval cannot be enforced outside the model, secrets cannot be revoked, or actions cannot be reconciled with an audit record.
/Sources and review basis
This checklist was reviewed against the following primary security guidance on 18 July 2026.
Apply these controls to an MCP marketplace
See how ClawDeals combines permissions, approvals, idempotency, and an audit trail.