MCP Tool Permissions and Least Privilege

Core idea: expose the smallest useful capability to the right user for the shortest useful time. A model should select among permitted actions, never manufacture permission.

MCP makes tools discoverable and callable across applications. That convenience can turn a broad backend credential into broad agent authority unless permissions are deliberately narrowed. Least privilege is the discipline of giving each request only the access it needs—across identity, tool, resource, tenant, environment, time, and data scope.

TL;DR

• Filter tool discovery as well as tool execution; unavailable actions should not be advertised.
• Authorize using verified user and tenant identity, not model-generated parameters.
• Separate read, propose, approve, and execute capabilities.
• Require specific confirmation for consequential or irreversible actions.
• Treat annotations and descriptions as interface hints, not security controls.

Permission has several dimensions

A simple “can call tools” role is too coarse. Evaluate at least these dimensions:

Dimension	Question
Principal	Which user, service, or workload is acting?
Tenant	Which organization owns the data and action?
Tool	Is this exact operation permitted?
Resource	Which repository, account, table, or record is allowed?
Environment	Is the target development, staging, or production?
Conditions	Is approval, business hours, or a ticket required?
Duration	How long is the grant valid?

The server should derive identity and tenant from authenticated context. Never trust a tenant_id supplied by the model as proof of authorization. Tool arguments describe the requested target; policy decides whether that target belongs to the caller.

Separate capability stages

High-risk operations become easier to control when decomposed. Instead of one deploy tool with sweeping authority, use distinct capabilities:

1. deploymentplancreate reads approved configuration and produces a plan.
2. deploymentplanvalidate checks policy and dependencies.
3. deployment_execute requires a plan ID and explicit approval.
4. deploymentstatusget observes the result.
5. deployment_rollback is separately restricted.

This structure reduces ambiguous parameters and creates natural approval points. It also lets a user receive planning help without granting execution permission.

Filter discovery and recheck execution

Tool discovery influences the model's choices. A finance intern should not even see a production payroll-transfer tool. Filter the tool registry by current identity, tenant, environment, and task. This reduces accidental selection and prompt-injection leverage.

Discovery filtering is not enough. Permissions may change between discovery and execution, cached lists may be stale, and arguments affect authorization. Recheck policy immediately before the action and again in the downstream system where possible.

Risk tiers and approvals

Classify tools using side effects, reversibility, data sensitivity, financial value, and blast radius. A practical scheme is:

• Low: bounded reads of non-sensitive data.
• Moderate: sensitive reads or reversible writes.
• High: external communication, production changes, money movement, deletion, credential changes, or broad exports.

Approval should display what will happen, not merely the tool name. Show the target, key parameters, affected scope, environment, and irreversible consequences. “Allow records_delete?” is weaker than “Delete 438 customer records from production? This cannot be undone.”

Avoid approval fatigue. If every harmless read triggers the same dialog as a production deletion, users stop evaluating prompts. Apply friction in proportion to risk and allow narrowly scoped, time-limited grants for repeated safe work.

A concrete permission decision

A support representative asks an agent to refund an order. The host knows the user identity and tenant. Discovery exposes orderget and refundpropose, but not refund_execute until the order is verified. Policy checks that the order belongs to the tenant, the refund is below the user's limit, and the reason code is allowed.

If the amount exceeds the limit, the system creates an approval request for a supervisor. The model can explain the requirement but cannot bypass it. After approval, the server issues a short-lived, operation-bound grant and records who requested and approved the refund.

Credential design

Prefer delegated credentials representing the user. When service credentials are unavoidable, constrain them at the server and downstream layers. Do not expose raw tokens to the model or return them in tool results. Store secrets outside configuration visible to prompts, rotate them, and keep development and production credentials separate.

For remote servers, validate token issuer, audience, expiry, and scopes. A token accepted by one resource must not automatically become usable against another. For local stdio servers, restrict environment variables, file access, executable provenance, and child-process capabilities.

Common mistakes

• One administrator token shared by all users.
• A single tool combining preview and execution.
• Authorization based on parameters rather than verified identity.
• Tool annotations treated as enforcement.
• Discovery lists cached beyond permission changes.
• Broad “always allow” consent without target or time limits.
• Read tools allowed to return entire datasets when one record is needed.

Least-privilege checklist

• Map each tool to required backend permissions.
• Split reads, proposals, execution, and rollback.
• Filter discovery and authorize every execution.
• Bind access to user, tenant, resource, and environment.
• Minimize fields and records returned by reads.
• Use explicit, risk-based approvals.
• Prefer short-lived and operation-scoped credentials.
• Test stale discovery, revoked access, and cross-tenant identifiers.
• Log policy decision, requester, approver, and effect.
• Review permissions whenever tools or downstream APIs change.

My Take

Least privilege improves agent quality as well as security. A smaller, relevant tool set reduces selection errors, shortens context, and makes approvals intelligible. Broad access often looks convenient during a demo but becomes operational ambiguity in production.

Make authority legible. A user should be able to understand why a capability appeared, which identity it uses, and what boundary prevented an unsafe action.

Sources

• Model Context Protocol specification: Authorization
• Model Context Protocol specification: Tools and security considerations
• OAuth security guidance referenced by the MCP authorization specification