MCPやAIエージェントのwrite actionに承認境界を置く設計 MCPやAIエージェントのwrite actionに承認境界を置く設計

As AI agents move from answering questions to taking actions, one design question becomes central: when a model can write to external systems, what decides that the write should actually proceed? This matters because the Model Context Protocol (MCP) and similar agent frameworks make it easy to connect a language model to tools that post messages, send emails, or change records. The convenience of granting that access can obscure a more important decision about where approval should sit.

The central argument here is that the first thing to settle is not whether the AI is technically capable of performing an action. Once a tool is exposed to an agent, capability is largely a given. The harder and more consequential question is which operations require what kind of approval boundary. A boundary in this sense is the checkpoint between the agent's intent and the action's real effect on a system of record or a channel that other people can see.

Consider three common write actions: posting to Slack, sending an email, and updating a CRM. From a tool-calling perspective they look alike, since each is a single function the agent can invoke. But they differ sharply in their consequences. A post to a shared Slack channel is visible to colleagues immediately and is awkward to retract. An email may cross an organization's boundary and reach a customer, where it cannot be recalled. A CRM update changes shared business data that other workflows and people depend on. Treating these as equivalent simply because they are all "writes" overlooks how differently they fail.

A practical way to size each boundary is to weigh reversibility and blast radius. An action that is easy to undo and affects only the agent's own scratch space can often run autonomously. An action that is irreversible, externally visible, or touches data others rely on tends to warrant a human-in-the-loop step, a preview, or a staged "draft then confirm" pattern. Some teams add intermediate options: auto-approving low-risk writes, requiring confirmation for medium-risk ones, and blocking certain high-risk operations entirely unless a person initiates them. The point is to match the strength of the gate to the cost of being wrong, rather than applying one policy to every tool.

This is where MCP's design is relevant. MCP is an open protocol, introduced by Anthropic in late 2024, that standardizes how applications supply context and tools to large language models. It defines servers that expose resources, prompts, and tools, and hosts and clients that let a model discover and call them. Importantly, the protocol does not mandate a particular approval model, so the responsibility for gating write actions falls largely on the server implementation and the host application. A well-designed MCP server can make approval boundaries explicit, for example by separating read-only tools from mutating ones, returning a preview before committing, or requiring an explicit confirmation token.

Several supporting techniques make these boundaries more reliable. Idempotency keys help ensure that a retried action is not executed twice. Dry-run or "what would happen" modes let an agent surface intended effects before they occur. Scoped credentials and least-privilege access limit what a compromised or confused agent can reach in the first place. Audit logging records who or what approved each action, which is useful both for debugging and for accountability. None of these are new ideas in software engineering, but agent autonomy raises their importance because the actor proposing the change is probabilistic rather than deterministic.

The broader industry is converging on similar concerns. Function calling and tool use, popularized through OpenAI's function calling and frameworks such as LangChain, LlamaIndex, and various agent runtimes, all face the same gap between generating an action and authorizing it. Many of these stacks now include some notion of human approval, interrupts, or confirmation steps for sensitive operations. MCP fits into this landscape as a connective layer rather than a policy engine, which means design choices about approval still belong to the people building and deploying the integration.

The takeaway is a sequencing one. Before asking how to give an agent more capability, it appears more durable to first decide which write actions are safe to automate, which need a preview or confirmation, and which should remain human-initiated. Defining those approval boundaries early tends to be easier than retrofitting them after an agent has already sent the wrong email.