Intercepting MCP Agent Write Requests with Policy Gates

Most local development environments give AI coding agents raw filesystem primitives: read_file, write_file, and execute_command. Once a model decides to mutate a file, the mutation occurs immediately. If the agent imports a dependency with a restrictive copyleft license, introduces a cyclic dependency, or breaks an internal interface invariant, you only find out when a linter fails, a test suite breaks, or CI rejects the pull request thirty minutes later.

Treating the filesystem as an unprotected resource turns agent governance into a cleanup operation. The correct posture is structural: intercept the write request at the tool boundary before any file mutation touches disk.

The Problem with Direct Filesystem Mutation

When a human developer works on a codebase, validation is social and procedural. We rely on IDE warnings, type checkers, and peer review. We do not write invalid state directly to shared branches, but we frequently write messy state to our local disks while experimenting.

AI coding agents do not work like humans. They produce rapid batches of modifications across multiple files in seconds. When an agent has unmediated write access, two distinct failure modes occur:

1. Policy violations happen silently: A model might resolve a missing utility by importing a library under AGPLv3 into a proprietary core module. The build passes, the unit tests pass, but the organization has incurred legal liability.
2. State pollution: If an agent executes four file edits to refactor an API and fails on the fifth due to a syntax issue, the workspace is left in an uncompilable half-state. The agent then spends additional context window cycles trying to debug the wreckage it just created.

Post-hoc CI pipelines catch these issues too late. By the time a GitHub Action fails, context is lost, tokens are spent, and human time is required to reset the environment. You need a gate between the agent deciding to write and the write actually executing.

Inserting the Build Intent Gate into the MCP Server

The Model Context Protocol (MCP) standardizes how LLMs interact with local tools. Rather than exposing a raw write_to_file tool over an MCP server, you expose a two-phase interface: proposal and commitment.

This is the core mechanic of governing code agents at the build-intent gate. When an agent wants to modify code, it does not call the disk. It registers a build intent.

// Proposed MCP Tool Definition
interface ProposeFileMutation {
  targetPath: string;
  patch: string;
  declaredDependencies: string[];
  intentDescription: string;
}

interface MutationVerdict {
  status: "ACCEPTED" | "REJECTED" | "REQUIRES_OVERRIDE";
  reasons: string[];
  stagedHandle?: string;
}

When the agent invokes propose_file_mutation, the MCP server executes policy checks out-of-process against the staged patch:

• License resolution: The tool inspects any new package imports against an organization allowlist (for example, allowing MIT/Apache-2.0 and blocking GPL/AGPL).
• Interface invariant enforcement: It checks whether exported signatures match required schema definitions or internal API contracts.
• Structural consistency: It parses the AST of the proposed change in memory to ensure it contains no banned primitives or forbidden cross-boundary imports.

If any invariant fails, the tool returns a REJECTED verdict along with the specific policy failure. The disk remains pristine. The agent receives actionable feedback ("Importing package X violates license policy: AGPL-3.0 is forbidden") inside its current turn, allowing it to pick an alternate approach without leaving broken artifacts behind.

Isolating Intent from Execution

This separation establishes a clear boundary. The agent is permitted to reason, generate diffs, and inspect code. It is not permitted to mutate project state without passing policy evaluation.

To implement this without breaking an agent's ability to iterate:

1. Stage writes in memory or isolated temp space: The gate applies the patch against a temporary tree or an in-memory representation of the target file. You can read more on this pattern in restricting agent filesystem access to preview sandboxes.
2. Execute fast, deterministic verifiers: Keep gate validation bounded. Parse ASTs, check dependency manifests, and verify static type contracts. If a verification takes longer than 200 milliseconds, move it out of the synchronous tool loop.
3. Issue a single-use commit handle: When policy checks pass, the gate returns an ephemeral stagedHandle. The agent then calls commit_mutation({ handle }) to apply the verified change to disk atomically.

This architecture moves verification from the end of the development lifecycle to the point of generation.

What to Do on Monday

If you are deploying coding agents to your team's machines, audit their tool definitions today:

1. Remove raw file-writing tools from the agent's active configuration.
2. Replace them with a custom build gate tool wrapper that intercepts patches before they touch the repository tree.
3. Write two initial gate rules: one that blocks the introduction of non-allowlisted package dependencies, and one that rejects diffs targeting protected configuration files (such as CI workflows or root package manifests).

Do not rely on the LLM to remember your engineering policies inside its system prompt. Prompts are advisory; tool boundaries are absolute.