MCP Is Not a Feature — It Is a Permission Boundary for Agent Tool Access

Most teams adopt MCP as a tool integration standard. They treat it as a connectivity feature — a way to give agents access to more tools through a consistent protocol.

That framing misses the most important architectural implication.

MCP is not primarily a feature. It is a permission boundary. It is the architectural layer where an organization decides what an agent is allowed to do — and the layer where that decision can be enforced, audited, and controlled.

The difference matters because tool access defines agent authority. An agent that can read a database has a different blast radius than an agent that can write to it. An agent that can draft an email has a different blast radius than an agent that can send one. An agent that can query a CRM has a different blast radius than an agent that can update customer records.

MCP standardizes the interface where these permissions are granted. That makes it the right place to enforce governance — not as an afterthought, but as a design decision.

The Permission Accumulation Problem

During development, tool access is added for convenience. The agent needs to query a database, so a database tool is connected. It needs to create tickets, so a ticketing tool is added. It needs to send notifications, so an email tool is integrated.

Each addition is reasonable in isolation. But the aggregate effect is an agent that has accumulated more authority than anyone explicitly decided to grant.

This is permission accumulation — the gradual expansion of agent authority through feature development rather than through governance decisions. By the time the system reaches production, the agent’s tool access reflects what was convenient during development, not what is appropriate for a production system.

MCP makes this visible because it provides a single interface where all tool connections are defined. That visibility is the governance opportunity: the MCP configuration is the agent’s permission manifest.

Tool Classification by Blast Radius

Not all tools are equal. The governance overhead should match the blast radius of the tool.

Read-Only Tools

Tools that retrieve data without modifying state: database queries, API reads, document retrieval, search. These carry the lowest blast radius and should be governed primarily through data access policies and logging.

Even read-only tools have governance implications: an agent with read access to sensitive data (customer records, financial data, health information) must comply with the same data access policies that apply to human users.

Write-With-Approval Tools

Tools that can modify state but require human approval before execution: draft creation (not send), record update proposals, ticket creation queues. These are the sweet spot for most production agent systems — the agent does the work, a human validates and approves.

The governance design: the agent proposes the action, the MCP layer captures the proposal, a human reviews and approves, then the action executes. The approval creates an audit trail and a control point.

Write-Without-Approval Tools

Tools that autonomously modify state: direct database writes, automated record updates, system configuration changes. These carry high blast radius because the agent acts without human verification.

The governance requirements are more demanding: evaluation evidence that the agent handles these tools correctly, rate limits to prevent runaway actions, anomaly detection to catch unexpected patterns, and automatic escalation when thresholds are exceeded.

Irreversible Action Tools

Tools where the action cannot be undone: data deletion, external email sends, financial transaction execution, public content publication. These carry critical blast radius and should require explicit human approval for every invocation — not batch approval or pre-authorization.

MCP as Trust Architecture

Tool permissions are trust decisions. When an organization grants an agent access to a tool, it is making a trust statement: “we trust this agent to use this tool correctly, within these boundaries, under these conditions.”

MCP provides the architectural layer where these trust decisions can be:

• Defined: which tools are available and under what conditions
• Enforced: runtime permission checks before tool invocation
• Audited: complete logs of which tools were invoked, with what parameters, and with what result
• Versioned: permission changes tracked over time, reviewable at any point

This is the same architectural pattern used for human access control — but applied to agent systems. The principle is the same: minimum necessary privilege, explicit grant, complete audit trail, regular review.

from pydantic import BaseModel, Field
from typing import Literal, Optional
from datetime import date
from enum import Enum


class BlastRadius(str, Enum):
    READ_ONLY = "read_only"
    WRITE_WITH_APPROVAL = "write_with_approval"
    WRITE_AUTONOMOUS = "write_autonomous"
    IRREVERSIBLE = "irreversible"


class MCPToolPermission(BaseModel):
    tool_name: str
    tool_description: str
    blast_radius: BlastRadius
    approval_required: bool
    approval_workflow: Optional[str] = Field(
        default=None,
        description="Name of the approval workflow. Required when approval_required is True."
    )
    rate_limit_per_hour: Optional[int] = Field(
        default=None,
        description="Maximum invocations per hour. None means no limit enforced."
    )
    escalation_threshold: Optional[str] = Field(
        default=None,
        description="Condition that triggers automatic escalation. E.g. '>10 invocations in 5 min'."
    )
    data_sensitivity: Literal["public", "internal", "confidential", "restricted"]
    granted_by: str
    granted_date: date
    review_date: date
    justification: str
    audit_log_required: bool = True

Permission Review Cadence

Tool permissions should not be granted once and forgotten. As the agent system evolves, permissions should be reviewed:

• At every production deployment: has the tool manifest changed? Were new tools added? Were permission levels changed?
• On a recurring cadence: are the current permissions still appropriate? Has the agent’s role changed?
• After any incident: did the agent’s tool access contribute to the incident? Should permissions be tightened?

For the blast radius engineering principles that inform tool permission design, see Blast Radius Engineering: Tool Permission Design for AI Agents. For the logging requirements before granting write access, see What To Log Before an AI Agent Gets Write Access. For the rollback plan that should exist before any production agent operates, see The Rollback Plan Every Production AI Agent Needs. For how permission design should evolve as the agent system matures, see Tool Use Governance: How Tool Access Should Evolve with System Maturity. For the escalation problem that emerges when write access is introduced without governance, see The Permission Escalation Problem in Production Agents.

Classify every MCP tool connection by blast radius before production deployment.
Require explicit governance review for any tool above read-only access.
Implement approval workflows for write operations in production agent systems.
Log all tool invocations with enough context to audit the agent's decision chain.
Review tool permissions at every deployment, on a recurring cadence, and after any incident.
Treat the MCP tool manifest as a permission document, not just a configuration file.

FAQ

The Decision Rule

If an agent can invoke a tool, the organization has made a permission decision whether or not anyone wrote it down. Treat the MCP manifest as the source of that decision. Classify every tool by blast radius, require approval where the action changes state, and review the manifest whenever deployment, role scope, or incident evidence changes the trust boundary.