MCP Policy Gates Are Not Decision Authority

The agent governance conversation has moved from visibility to interception.

That is progress.

It is also where the next category error begins.

A policy gate around MCP can decide whether a tool call is permitted. It can inspect tool definitions, block suspicious arguments, sanitize responses, enforce approval rules, and produce an audit event. Every serious production agent stack will need that kind of control.

But a permitted tool call is not the same thing as a valid business decision.

If an agent calls apply_discount with a clean schema, an approved server, a known identity, and a policy-compliant payload, the infrastructure has still not proven that this discount applies to this customer, under this contract, on this date, with this margin state, inside this approval scope.

That proof belongs to decision infrastructure, not the transport layer.

The tool call is not the decision

Microsoft's Agent Governance Toolkit framing is directionally right: MCP standardizes the execution surface, but does not define how that surface should be governed. A checkpoint is needed between the model's intent and the tool server's execution.

The .NET implementation makes the control point more concrete. It can scan tool definitions, evaluate tool calls before execution, sanitize responses before they re-enter the model, wire policies through YAML, and emit audit events. That is exactly the shape MCP governance needs.

But the tool call is still only the outer envelope of the decision.

Take a revenue agent preparing a renewal action. The MCP policy gate can answer:

• Is this tool allowed for this agent?
• Are the arguments shaped correctly?
• Does the requested operation require approval?
• Does the payload contain obvious injection, secrets, or exfiltration indicators?
• Should the response be redacted before it returns to the model?

Those are execution-surface questions. They matter because MCP turns tool access into a common operating layer. A compromised tool description, poisoned response, excessive permission, or malformed argument can create real damage.

The decision question is different:

• Does this renewal action apply to the current contract?
• Is the account inside the agent's decision scope?
• Which pricing policy version is active today?
• Is there a margin exception or legal hold?
• Which approval overrides supersede the default rule?
• Can the system replay why this action was allowed?

The first list can be handled by MCP governance and policy-as-code.

The second list requires a decision context graph.

MCP governance solves a real gap

This distinction is not an argument against MCP policy gates. It is an argument for putting them in the right layer.

MCP has made tool access cheap. That creates a larger blast radius for every agent mistake. The IETF MCP security draft states the core issue plainly: tool call parameters originate from LLM reasoning, which can be influenced by prompt injection, so MCP servers must treat parameters as untrusted. Chrome's WebMCP security guidance makes the same operational point from the browser side: untrusted content, cross-origin interactions, state mutation, classifiers, critics, and human confirmation all need explicit defensive handling.

This is a healthy market signal. MCP is no longer just an integration story. It is becoming a governed execution surface.

The right stack now includes:

• server and tool discovery controls
• tool definition scanning
• identity and authorization checks
• deterministic policy evaluation before invocation
• response sanitization before model re-entry
• audit events for tool activity

Without those controls, MCP-connected agents become an unbounded supply-chain and prompt-injection surface.

But those controls still operate around the call. They decide whether the agent may invoke a tool with these arguments through this path. They do not necessarily decide whether the represented business action is legitimate in the current enterprise context.

That is the same boundary The Context Graph drew in MCP Solved the Pipes. Who Solves the Water Quality?. MCP connects. Governance of the connection is necessary. Governance of the decision is a separate layer.

Decision authority needs graph-shaped context

A valid enterprise action is rarely a single rule.

It is usually the intersection of customer state, policy version, contract language, product entitlement, jurisdiction, approval history, source authority, time, exception hierarchy, and actor scope. Those dependencies are not naturally represented as a flat allowlist. They are graph-shaped.

That is why applicability logic matters. The core question is not only "is this call allowed?" It is "which rules apply to this exact situation, and which facts make them active or inactive?"

A decision context graph turns the proposed tool call into a decision request:

• actor
• target entity
• intended action
• affected system
• policy scope
• current state
• retrieved evidence
• applicable time
• expected side effect

The graph then traverses the relevant context: contracts, policy nodes, exception records, approvals, ownership, entitlement state, risk thresholds, temporal validity, and provenance. It returns allow, block, or escalate with a causal decision trace.

That trace is not just an audit log. It is the explanation of why the action was valid or invalid under the rules in force at the time.

This is where Rippletide fits as a reference implementation: a decision context graph that evaluates the proposed action before it reaches production systems. The important pattern is broader than any one product. MCP governance catches unsafe invocation. The decision graph catches invalid action.

Where the handoff belongs

The clean architecture is a handoff, not a turf war.

An agent registry or agent control plane says which agents, tools, MCP servers, and skills exist.

An agent gateway controls the path an agent can use to reach models, tools, APIs, and data systems.

An MCP policy gate evaluates the invocation: tool identity, argument structure, request policy, sensitive operation, response handling, and audit event.

A decision context graph evaluates the action: applicability, scope isolation, temporal validity, policy compliance, exception handling, and traceability.

In practice, that means an MCP gateway should not only ask, "may this agent call this tool?" It should also ask, "what decision does this call represent?"

If the call mutates state, sends a message, changes money, updates a customer record, modifies access, escalates a workflow, or commits an operational decision, it should be converted into a decision request and checked before execution.

This mirrors the boundary drawn in A Sandbox Is Not a Decision Boundary. A sandbox proves the agent stayed inside its execution environment. A policy gate proves the tool call met invocation rules. A decision boundary proves the action was valid in context.

Confusing those layers creates false confidence.

The line to draw

The enterprise agent stack is maturing in the right order.

First, agents needed better connectors. MCP answered that.

Then, teams needed visibility into agents, tools, and skills. Registries and control planes are answering that.

Now, tool execution needs enforcement. MCP policy gates are answering that.

The next layer is decision authority.

Every production team should ask one question before celebrating its MCP governance story:

If the policy gate allows the tool call, what proves the decision behind that call is applicable, scoped, current, and traceable?

If the answer is "the model chose it," the system is trusting reasoning where it needs enforcement.

If the answer is "the tool was approved," the system is confusing inventory with authority.

If the answer is "the policy gate allowed the call," the system is stopping one layer too early.

MCP policy gates are necessary. They are not the decision substrate.

The accountable agent stack needs both: governed tool execution through MCP and pre-execution decision validation through a context graph. One protects the invocation surface. The other protects the business outcome.

---

The Context Graph is a weekly newsletter for AI engineers building production agents. Read the context graph glossary for the canonical vocabulary behind decision context graphs, pre-execution enforcement, accountable agents, policy-as-code, and causal decision traces.