MCP Tool Permissions: Security Best Practices

MCP tool permissions define which capabilities an MCP host registers for a given agent session, what each tool may do, and how application policy complements connection-level access. The Model Context Protocol advertises tools with names and argument schemas — but permission to cause side effects is enforced by your host and server code, not by MCP itself.

Without explicit permissions, agents inherit the full tool manifest on an MCP server: writes, external calls, and bulk reads become available to a model that may be steered by prompt injection. MCP tool permissions translate AI agent permissions into concrete MCP registrations and policy rules.

Two permission planes

MCP deployments involve two distinct planes:

Plane 1: Connection / deployment
  Who can open an MCP session to the server?
  (network, gateway auth, host configuration)

Plane 2: Application policy
  Which tools are registered for this agent?
  Which proposed calls are allow / review / block?
  (host orchestration + Agent Action Guard)

Plane 1 without Plane 2 means any authenticated host can invoke every tool. Plane 2 without Plane 1 means an unauthenticated client might reach the server directly. You need both.

MCP does not automatically enforce application policy. Your host must filter tool registration and evaluate each call before invocation.

Scoping tool exposure

Session tool allowlists

At session start, register only tools required for the task:

If a tool is not registered, the model cannot propose it in frameworks that respect tool lists — reducing excessive agency at the source.

Dynamic registration

For long-running workflows, add tools when the user escalates intent ("I need a refund") rather than exposing all write tools upfront. Revoke write tools when the sub-task completes. See Securing Long-Running AI Agents.

Multi-server composition

Connect hosts to multiple MCP servers with different credentials:

• Read server: broad search tools, read-only DB role
• Write server: narrow mutation tools, stricter ACL

Agents that only need lookup never receive a write server connection.

Read vs write vs destructive

Mirror the primary split from agent permissions:

Name MCP tools so policy rules map cleanly. filesystem_read and filesystem_write beat one filesystem tool with a mode enum.

Agent Action Guard default policy blocks destructive keywords in action and context, allows read-only action prefixes, and blocks secret-bearing context.

Application policy layer

For each proposed MCP tool call, evaluate policy before the MCP client invokes the server:

async function invokeMcpTool(proposal: McpToolCall): Promise<ToolResult> {
  const guard = await fetch("https://www.identicapi.com/api/v1/security/agent-action", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.IDENTICAPI_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      tool_name: proposal.server + ":" + proposal.tool,
      action: proposal.tool,
      arguments: proposal.arguments,
      context: proposal.sessionContext
    })
  });

  const result = await guard.json();
  if (result.decision === "block") {
    return { error: "blocked", reason: result.policy_reason };
  }
  if (result.decision === "review") {
    return await enqueueApproval(proposal, result);
  }
  return mcpClient.callTool(proposal);
}

Enforcement is mandatory in your host. The API returns decision; only your code prevents execution.

Custom policy rules

Examples aligned with MCP naming:

{
  "condition_type": "tool_name",
  "condition_value": "mcp_billing",
  "decision": "review"
}

{
  "condition_type": "destructive_action",
  "condition_value": "",
  "decision": "block"
}

Rule reference: Agent Action Guard docs. Policy patterns overlap runtime security and policy decisions.

Tenant and data scope

Multi-tenant SaaS must bind MCP permissions to tenant context:

• Host passes authenticated tenant_id from the user session — never from model-generated arguments alone
• MCP server enforces row-level filters using host-supplied identity tokens
• Policy rules may include data_scope conditions for export or bulk read tools

Cross-tenant ID in arguments should trigger block or review. Combine with source-to-sink security to prevent untrusted web content from driving cross-tenant reads.

External and network permissions

MCP tools that fetch URLs or call webhooks need network permission models:

• Allowlisted domains per agent profile
• Block private IP ranges and metadata endpoints at server
• Review first contact to new domains

Browsing tools compound injection risk — see secure agent web browsing and web page prompt injection.

Permissions vs schemas

Tool JSON Schema ensures amount is a number; it does not ensure amount is within refund policy. Permissions answer authorization questions schemas cannot:

Validate schema in the host for early rejection; validate permissions via validate AI tool calls pipeline before MCP invocation.

Auditing permission changes

Track:

• Tool manifest version deployed on each MCP server
• Host configuration which registers tools per agent type
• Policy ID and rule changes in Agent Action Guard

Unexpected tool appearing in manifest or new allow rule without review is a governance alert.

Best practices summary

1. Minimize registered tools per session — least privilege.
2. Split read/write tools and servers.
3. Evaluate every call with Agent Action Guard before MCP invoke.
4. Re-authorize on long sessions when scope escalates.
5. Server-side checks duplicate host policy — never trust the model for tenant IDs.
6. Screen tool outputs before re-prompting — permissions on invocation do not sanitize return path. See MCP prompt injection.

Operational checklist: MCP Security Checklist. Foundation: What Is MCP Security?.