An MCP setup can give an AI client access to files, repositories, databases, browsers, tickets, docs, and other tools. That makes permissions review part of setup, not an optional task after everything works.
This MCP security permissions checklist helps developers review what each server can read, what it can write, which secrets it needs, how prompt injection is handled, what gets logged, and how risky actions are approved before enabling tools in Claude Desktop, Cursor, custom apps, or local development workflows.
This is an independent safety-focused planning guide. It is not official documentation for any MCP client or server. Always verify the current client and server maintainer docs before using a config locally.
Key takeaways
- Start with read-only MCP access and add write tools only after approval, logging, and rollback are clear.
- Never put real tokens, cookies, database URLs, or private credentials into public config examples, browser forms, screenshots, or committed files.
- Treat files, web pages, issues, docs, database rows, and tool outputs as untrusted input that may contain prompt-injection attempts.
- Use the browser-only MCP Security Checklist Generator to create a review checklist without uploading configs, secrets, or files.
What an MCP permissions checklist should cover
A useful MCP permissions checklist connects the agent workflow to concrete access decisions. For each server, document what data it can read, what actions it can take, which credentials it uses, how outputs are logged, and who approves risky operations.
Do not treat MCP configuration as a simple install step. A config file defines the operating boundary for an AI agent, so it should be reviewed before private files, production databases, or write-capable APIs are connected.
- Server purpose
- Read permissions
- Write permissions
- Required secrets
- Untrusted input sources
- Logging and redaction
- Approval and rollback
Review server access before enabling tools
Start from the workflow, then enable only the server categories needed for that workflow. A coding assistant may need a narrow project folder and GitHub issues. A research assistant may need docs and search. Most first versions do not need broad filesystem, production database, browser, email, and deployment access all at once.
For local tools, use explicit folder paths instead of a whole home directory. For API tools, use narrow scopes and separate credentials. For database tools, start with sandbox data or read-only roles.
- Enable one server at a time
- Use narrow filesystem paths
- Prefer read-only API scopes
- Avoid production data for first tests
- Remove stale servers
Separate read-only, write, and destructive actions
Read-only tools are easier to test safely. Write-capable tools need stronger controls because an assistant may create commits, edit tickets, update records, send messages, deploy code, or delete data.
Group actions by risk. Low-risk reads can run directly. Medium-risk writes should require review. Destructive or external-facing actions should require explicit human approval, previews, and rollback documentation.
- Read-only first
- Preview before write
- Human approval for destructive actions
- Rollback steps before enablement
- Clear tool names for risky actions
Handle MCP secrets and environment variables safely
MCP servers often need tokens, API keys, database URLs, or service-account credentials. Public examples should show placeholder names only, such as ${GITHUB_TOKEN}, ${DATABASE_URL}, or ${BRAVE_API_KEY}. Real values belong in private local setup or a secret manager.
Separate development, staging, and production credentials. Rotate credentials after demos, screen shares, leaks, or public debugging. Redact secrets from logs, errors, traces, screenshots, and support messages.
- Use placeholders in docs
- Commit .env.example, not .env
- Use least-privilege tokens
- Separate dev and production credentials
- Redact logs and errors
- Rotate after exposure
Reduce prompt injection risk from untrusted content
Prompt injection matters for MCP because servers can bring external content into an agent loop. Web pages, search results, GitHub issues, docs, emails, database rows, and local files may contain instructions that try to override the user's goal or reveal secrets.
Treat retrieved content as data, not authority. It should not be allowed to change tool permissions, request secrets, bypass approvals, or execute unrelated actions. Keep browser/search tools separated from destructive tools when possible.
- Treat external content as untrusted
- Do not let content change permissions
- Keep browsing separate from writes
- Ignore requests to reveal secrets
- Log suspicious instructions without raw secrets
Log enough for debugging without leaking data
Logs are useful when a server fails to start or a tool returns unexpected output, but raw logs can leak tokens, file paths, database rows, customer data, or private repository names.
Log structured events such as tool name, status, duration, and redacted error category. Avoid full environment dumps, raw request bodies, complete SQL results, and unredacted stack traces in shared debugging output.
- Log tool name and status
- Redact tokens and connection strings
- Avoid env dumps
- Minimize returned fields
- Limit access to debug logs
Test MCP servers in a sandbox before production use
A safe first test proves that the MCP client can discover the server, call a narrow tool, handle invalid input, and fail safely. Use a harmless project folder, sample repository, sandbox database, or test account before connecting production resources.
For write-capable tools, test the full review loop: preview, approval, execution, verification, and rollback. If the workflow cannot be rolled back, do not enable it for production data until the risk is explicitly accepted.
- Use sample files or test repos
- Use sandbox databases
- Test invalid input
- Verify rollback
- Document production go/no-go criteria
Use the MCP Security Checklist Generator
The MCP Security Checklist Generator creates a Markdown review checklist from server type, data sensitivity, deployment model, write-action risk, secrets, and prompt-injection exposure. It runs entirely in the browser.
The generator is designed for planning only. It does not ask for real tokens, upload config files, call an AI API, install MCP servers, or store inputs in a database.
- Browser-only generation
- No login
- No uploaded configs
- No real secrets
- Copy the checklist locally
- Review official server docs before use
Implementation checklist
- Define the agent workflow before choosing MCP servers
- Enable only the servers needed for the current workflow
- Start with read-only permissions wherever possible
- Use narrow filesystem paths instead of broad home-directory access
- Use least-privilege API tokens and service accounts
- Keep real secrets out of public examples, screenshots, browser inputs, and Git commits
- Use placeholders such as ${GITHUB_TOKEN}, ${DATABASE_URL}, and ${BRAVE_API_KEY} in shared examples
- Separate development, staging, and production credentials
- Avoid production databases during first tests
- Treat web pages, search results, tickets, issues, docs, and database rows as untrusted content
- Keep browser/search tools separated from destructive tools when possible
- Require human approval for write, delete, deploy, payment, email, or external-posting actions
- Document rollback steps before enabling write-capable tools
- Redact secrets from logs, errors, traces, and shared debugging output
- Remove stale MCP servers, unused env variables, and old credentials
- Rotate credentials after demos, screen shares, leaks, or public debugging
- Verify client-specific config behavior before copying examples into Claude Desktop, Cursor, or another MCP client
- Run a final security review before connecting production resources
FAQ
What is an MCP security permissions checklist?
It is a pre-launch review for MCP server access, tool permissions, credentials, prompt-injection exposure, logging, approval rules, and rollback steps.
Why do MCP servers need a permissions review?
MCP servers can expose files, repositories, databases, browsers, and other tools to an AI client. Reviewing permissions before use reduces overbroad access, leaked secrets, and unsafe actions.
Should I start MCP servers with read-only access?
Yes. Start read-only when possible, test the workflow, then add write-capable tools only after human approval, logging, and rollback behavior are clear.
Can prompt injection affect MCP tools?
Yes. Web pages, issues, docs, messages, database rows, and file contents can include malicious instructions. Treat external content as untrusted and do not let it change permissions or reveal secrets.
Should MCP config examples include real API keys?
No. Public examples should use placeholders such as ${GITHUB_TOKEN}, ${DATABASE_URL}, and ${BRAVE_API_KEY}. Real values belong only in private local setup or a secret manager.
How should I handle database MCP servers safely?
Use sandbox databases first, prefer read-only roles, scope access to selected schemas or views, avoid production credentials during testing, and redact query errors or logs.
Can a browser-only tool safely generate an MCP checklist?
Yes, if it runs entirely in the browser and does not require login, call an API, upload files, store inputs, or ask for real secrets.
Is this official MCP documentation?
No. It is an independent planning checklist. Verify the current MCP client and server maintainer documentation before enabling any server.