MCP Tool Authorization and Execution Control

Model Context Protocol (MCP) is rapidly becoming the standard interface by which AI agents connect to external services — payment APIs, databases, file systems, communication tools, and operational systems. MCP tools extend what an agent can do, dramatically. They also introduce an authorization gap that is not solved by the protocol itself: MCP has no built-in mechanism for pre-execution proof that a tool invocation has been independently authorized before it executes.

This article explains how MCP tools work, where the authorization boundary sits, what the RF-100 open standard specifies for tool-invocation control, and how ExecutionProof closes the gap as a wrapping enforcement layer.

How MCP Tools Work

MCP defines a client-server protocol. An MCP server exposes a set of tools — discrete, callable functions — to an MCP client, which is typically the AI agent or the agent runtime. The agent discovers available tools via a tool manifest, decides which tool to invoke based on its current task, and sends an invocation request with the required parameters. The MCP server executes the tool and returns the result.

What MCP Does Not Specify

MCP specifies the transport format and tool-discovery mechanism. It does not specify:

• How the agent's authority to invoke a specific tool with specific parameters is verified
• Whether any independent component evaluates the proposed invocation before it executes
• How a ProofRecord of the authorization decision is created and preserved
• How a human-in-the-loop HOLD pattern is triggered for high-consequence invocations

These are not oversights — MCP is a transport and discovery protocol, not an authorization framework.

The Authorization Gap in Payment Workflows

Consider an agent using an MCP tool named initiate_payment that wraps a treasury API. The agent invokes the tool with parameters: recipient_id, amount, currency, memo. The MCP server receives the invocation and calls the underlying payment API. The payment executes.

At no point in this flow does any component ask: Has this specific invocation — this recipient, this amount, at this moment, from this agent — been independently authorized?

OWASP AA3 — Tool and Plugin Misuse: The OWASP Top 10 for Agentic AI identifies tool misuse as a top-tier risk. An agent invoking an MCP payment tool outside its authorized scope — whether due to prompt injection, misconfiguration, or emergent goal drift — is the canonical AA3 scenario. Pre-execution control at the tool-invocation boundary is the primary mitigation.

What RF-100 Requires at the Tool Boundary

RF-100 specifies that at the authorization boundary — the point at which an agent's proposed action becomes an external consequence — the E2/E3 requirement cluster mandates:

• The invoking agent's identity must be cryptographically bound and verified — not merely asserted via the MCP client session.
• The proposed tool invocation — including its specific parameters — must be evaluated against a declared authority scope.
• The ALLOW/HOLD/DENY verdict must be rendered by an independent component before the MCP server processes the invocation.
• A ProofRecord documenting the verdict, the evaluated evidence, and the invocation parameters must be written to the Verification Decision Record (VDR) at verdict time.

How ExecutionProof Wraps MCP Tool Calls

ExecutionProof's enforcement interface can be positioned as a wrapping layer between the MCP client (the agent runtime) and the MCP server. In this configuration:

1. The agent issues a tool invocation request through the standard MCP client interface. No changes are required to the agent code.
2. The ExecutionProof enforcement interface intercepts the request before it reaches the MCP server, evaluates it against the configured authorization policy and the agent's declared authority scope, and renders a verdict.
3. On ALLOW, the invocation is forwarded and a ProofRecord is written. On HOLD, the invocation is paused for human approval. On DENY, the invocation is blocked.
4. The MCP server, the underlying API, and the agent code are unmodified.

A Practical Note on Scope

Not every MCP tool invocation requires pre-execution control at the RF-100 level. A tool that reads a public dataset does not cross an authorization boundary with real-world consequences. Organizations should map their MCP tool inventory to identify which tools cross the boundary — payment, identity, data mutation, resource allocation — and apply ExecutionProof selectively at those points.

---