An MCP permission audit answers a concrete question: what can this agent read, write, execute, send, remember, or spend through its connected servers? Teams often install MCP servers one at a time, then lose track of the combined authority created by filesystem access, browser automation, repository tools, databases, messaging, and internal APIs.
The audit should happen before production and again whenever a server, credential, model, prompt, or workflow changes. It is not paperwork for its own sake. It is how teams find overbroad scopes, secret exposure, missing approvals, weak logs, and actions that need a rollback plan.
This guide complements the MCP server security checklist at /mcp-server-security/, the checklist generator at /tools/mcp-security-checklist-generator/, and the production agent security guidance in /guides/agent-security-guide/.
Key takeaways
- Audit MCP permissions by capability and business impact, not only by server name.
- Read-only access can still expose sensitive customer, code, financial, or internal data.
- A useful audit produces decisions: keep, narrow, sandbox, approval-gate, monitor, or remove.
Inventory every MCP server and capability
Start with a complete inventory. For each MCP server, record what it connects to, which environment it reaches, which credential it uses, what operations it exposes, and which workflow depends on it. Avoid vague labels like 'GitHub access' or 'database access'. The audit needs to distinguish read issues from merge pull requests, inspect schema from update rows, and browse pages from submit forms.
Group capabilities into read, transform, create, update, delete, execute, send, deploy, bill, and remember. This turns a tool list into a risk map. A server with a small number of high-impact actions may deserve more review than a larger read-only server.
- Server name, package/source, owner, version, and hosting model.
- Credential type, scope, expiry, environment, and rotation owner.
- Allowed resources such as paths, repositories, domains, tables, channels, and APIs.
- Exposed operations and the business impact of each operation.
Classify data and action risk
Not every read is low risk. A read-only server may expose customer PII, private source code, security logs, invoices, payroll data, unreleased product plans, or internal conversations. The audit should classify data sensitivity separately from action impact.
Then classify actions by reversibility. Formatting text or reading public docs is low impact. Creating a draft is usually moderate. Sending a customer message, updating CRM records, changing permissions, deploying code, deleting data, or moving money is high impact and should be gated.
- Low risk: public docs, selected local examples, static calculators, read-only public pages.
- Medium risk: internal docs, issue trackers, draft creation, staging dashboards, non-public reports.
- High risk: customer records, source code, production databases, external messages, deployments.
- Critical risk: credentials, billing, payments, payroll, destructive deletes, permission changes.
Check secrets and credential handling
Secrets should be stored in platform secret stores or environment managers, not pasted into prompts, repository files, logs, screenshots, or generated reports. The audit should verify behavior without exposing secret values. For example, confirm a secret exists, deploy the workflow, and run a non-sensitive smoke test that proves the integration works.
Each MCP server should use a dedicated credential when possible. Shared personal tokens make incident response harder because revoking them can break unrelated systems. Production credentials should not be reused for demos, staging, or local experiments.
- No secrets in prompts, code, logs, screenshots, generated artifacts, or long-term memory.
- Separate credentials by environment, workflow, and server where practical.
- Use expiry, rotation ownership, and revoke paths for high-risk credentials.
- Verify secrets through behavior tests, not by printing or reading values.
Decide approval gates and rollback paths
The audit should define which actions can run automatically, which require review, and which are not allowed. Approval gates should show the exact proposed action, destination, affected records, source evidence, and expected side effects. Users cannot approve safely if the screen only says the agent wants to 'continue'.
For every write-capable or external-impact action, define a rollback path before launch. If an agent updates a ticket, sends a message, changes a database row, opens a pull request, or deploys code, the team should know how to reverse, pause, or investigate that action.
- Auto-allow low-risk reads and deterministic formatting.
- Require review for customer-facing, production, financial, destructive, or external actions.
- Require stronger confirmation for credential, permission, billing, and deletion operations.
- Document rollback commands, owners, audit log locations, and kill switches.
Turn audit results into a launch decision
A permission audit should end with clear decisions, not a long unresolved spreadsheet. Mark each server as keep, narrow, sandbox, approval-gate, monitor, replace, or remove. For unresolved risks, name the owner and the blocking evidence needed before production.
Repeat the audit when workflows evolve. The risky moment is often not first install; it is when a previously read-only agent gets a write tool, a broader credential, a new memory feature, or access to production data because the prototype worked well.
- Keep: scope matches workflow and monitoring is sufficient.
- Narrow: reduce paths, domains, repositories, tables, scopes, or actions.
- Sandbox: restrict to staging, test accounts, or synthetic data.
- Remove: server is unused, duplicated, unowned, or too broad for the value it provides.
Implementation checklist
- List every MCP server, owner, credential, environment, and exposed operation.
- Classify data sensitivity and action impact separately for each capability.
- Remove broad credentials, shared personal tokens, and unused servers.
- Define approval gates for writes, external messages, deletes, deploys, billing, and permission changes.
- Document logs, rollback paths, kill switches, and re-audit triggers.
FAQ
What is an MCP permission audit?
It is a structured review of what each MCP server can read, write, execute, send, remember, or spend, plus the credentials, approvals, logs, and rollback paths around those capabilities.
When should I audit MCP permissions?
Audit before production, after adding a server, after expanding scopes, after enabling write actions, after changing prompts or models, and after any security incident or near miss.
Is read-only MCP access always safe?
No. Read-only access can still expose sensitive customer data, source code, financial records, internal docs, credentials in logs, or private conversations.
Who should own an MCP permission audit?
The product or engineering owner should run it with security review for high-risk workflows. Each server should have a named owner responsible for scopes, credentials, and incident response.
What should I remove first?
Remove unused servers, broad personal tokens, production write access without approval, arbitrary command execution, and any credential that is shared across unrelated workflows.