Proposal: MCP Enforcement Mode — Mandatory Action Routing for Enterprise Audit & Security

The Problem

MCP is excellent as a capability protocol — but in enterprise environments, it's only valuable as a security and audit layer if it's mandatory, not optional.

Today, an AI agent connected to MCP servers can still choose to bypass MCP entirely — shelling out to a CLI, making direct HTTP calls, writing files, or taking other side-effectful actions outside the protocol. When this happens, your audit log has gaps, your policy enforcement has blind spots, and your security posture is incomplete.

For enterprises adopting agentic AI, the core question isn't "can we connect agents to tools via MCP?" — it's "can we guarantee that every action an agent takes in our environment flows through a single, auditable control plane?"

Right now, the answer is no. MCP has no concept of enforcement mode.

How I'm Thinking About This

I'd frame the solution around a clear boundary: thinking vs. acting.

• Thinking (reasoning, planning, internal state) — no enforcement needed. This stays with the model.
• Acting (any side-effectful operation: file writes, API calls, CLI commands, database mutations, network requests) — MUST route through MCP when enforcement mode is active.

At the protocol level, this could look like a host-declared capability during initialization:

{
  "capabilities": {
    "enforcement": {
      "actionsRequireMcp": true
    }
  }
}

When actionsRequireMcp is true, the host is declaring a contract: this agent environment does not permit side-effectful operations outside of MCP tool calls. The host is responsible for enforcing this (sandboxing, runtime restrictions, etc.), and the capability signal allows servers, gateways, and audit systems to know whether they can trust that MCP is the complete record of agent actions.

Why This Matters for the Gateway Pattern

Discussion #804 proposes a gateway-based authorization model — centralized policy enforcement, per-request auth, credential isolation. That's the right direction. But a gateway only works if traffic actually flows through it.

Without an enforcement mode, the gateway pattern has a fundamental gap: it secures the front door while the agent can walk around the building. Enforcement mode is the prerequisite that makes gateway security trustworthy.

What This Enables

• Complete audit trail: Every agent action is captured in one place — no gaps from CLI side-channels or direct API calls.
• Uniform policy enforcement: Authorization, rate limiting, DLP, and anomaly detection applied consistently to all agent actions.
• Compliance confidence: Enterprises can demonstrate to auditors that agent behavior is fully observable and controlled.
• Gateway trust: Downstream systems (and the gateway proposals in Spec Proposal: A Gateway-Based Authorization Model #804) can rely on MCP as the authoritative record.

Context: Where I'm Coming From

Full transparency — I'm working on a policy product that covers both MCP and CLI interactions for enterprise environments. The consistent feedback from enterprise customers is that they need a uniform path for audit and enforcement, regardless of whether the agent decides to use MCP or go around it. The current protocol doesn't give them that guarantee, and it's the single biggest blocker to enterprise adoption with confidence.

That said, I'm not trying to push a product-specific solution into the spec. I'm raising this because I believe it's a protocol-level gap that affects every enterprise deployer, and I'd rather see it solved in the standard than in proprietary wrappers.

Open Questions (I'd Love Input On)

1. Is this a spec concern or a host implementation concern? I believe it's both — the spec needs the capability signal and behavioral contract; the host needs the enforcement runtime. But I'm open to arguments that this belongs entirely outside the protocol.

2. Where's the boundary of "acting"? Reading a file — is that an action? A DNS lookup? I have opinions but the community should define this taxonomy together.

3. How does this interact with existing capability negotiation? Should servers be able to require enforcement mode as a precondition for connecting? (e.g., "I won't serve tools to non-enforcing hosts")

4. Is a new capability the right mechanism, or is this better expressed as a transport/gateway-level concern?

5. Who else is hitting this problem? I'd especially like to hear from the Security IG participants and anyone deploying MCP in regulated industries.

Next Steps

If there's interest, I'm happy to:

• Build a prototype demonstrating enforcement mode in a reference host
• Draft a formal SEP once the problem space is validated
• Coordinate with the gateway proposal (Spec Proposal: A Gateway-Based Authorization Model #804) and Security IG

Looking forward to the discussion.