Interlock stops AI agents from using MCP tools that changed after approval.

Detect material changes to an approved MCP tool boundary, hold the next gateway-mediated call to that tool before it is forwarded upstream, and verify the recorded evidence.

MCP runtime trust layer for AI agents. Open source. Self-hosted. Designed for gateway-mediated MCP traffic.
1 · APPROVED BOUNDARY✓ approved
tool: read_file
effects: read
externality: internal
baseline hash pinned · policy approved
2 · SURFACE CHANGEDchanged
read → read + export
tool identity: unchanged
externality: internal → external
capability drift detected at re-discovery
3 · READ_FILE QUARANTINEDquarantined
decision: read_file quarantined
next gateway-mediated call to read_file: held before upstream forwarding
other approved tools keep working
4 · EVIDENCE VERIFIED✓ verified
hash-chained receipt
previous hash → current hash
verified offline
chain: verified
This is the default evaluator journey: the change is found by comparing the re-discovered tool surface against the approved baseline, so the next gateway-mediated call to that tool is held before Interlock forwards it upstream. Quarantine is scoped to the affected tool — unrelated approved tools on the same server keep running. Decisions are recorded in a hash-chained audit log, from which receipts can be verified offline. offline proof fixture
THE PROBLEM

Approval is only a snapshot.

An MCP tool may be approved with a specific capability, externality, permission boundary, and expected behavior. Later, its schema, underlying API, authorization behavior, deployment, or effective capability may change. Static allowlists and one-time approval do not prove that the same runtime boundary still exists.

SURFACE DRIFT
Tool names, parameters, schemas, or declared capabilities change.
CAPABILITY DRIFT
A tool gains broader effects, externality, permissions, or data access.
OBSERVED BEHAVIORAL DRIFT
Runtime behavior changes while the manifest remains unchanged — expected 403 → observed 200. Invisible to schema diffing, so it has to be observed: see the controlled probe.
HOW IT WORKS

Gateway-mediated, baseline-compared.

Interlock sits in the call path, compares every later call against the boundary an operator approved, and records what it decided.

Interlock only governs calls routed through its gateway.
1Register a gateway-mediated MCP server
2Review and approve its tool boundary
3Create an approved baseline
4Re-discover and compare the current tool surface
5Detect material drift
6Quarantine that tool, holding later gateway-mediated calls to it before forwarding
7Record the gateway decision
8Operator approves, rejects, or rebaselines
THE PRODUCT CONSOLE

Drift review comes first.

The operational console keeps the drift review queue available: the approved baseline, the approved-versus-current boundary diff, the quarantine decision, what happens to later calls to that tool, and the receipt — with approve, reject, or rebaseline one action away.

Approved server and tool baseline, always visible
Expected-versus-observed evidence per decision
Receipt details and offline chain verification
Scan statistics, configuration, and administration remain available — they just aren't the story.
Drift review queueOffline proof fixture. Receipt chain verified.
TOOL BOUNDARYAPPROVEDCURRENTDECISION
read_file (fixture) read · internal read, export · external quarantined
APPROVED VS CURRENT
tool identity: unchanged
classification: capability / surface drift
detected at: re-discovery
subsequent calls to read_file: held before forwarding
RECEIPT
previous hash → current hash
chain: verified · verifiable offline
Approve Reject Rebaseline Operator actions · shown for reference
EVIDENCE

See exactly what changed.

In the default journey the change is a declared one: the re-discovered tool surface no longer matches the approved boundary, and the diff is the evidence.

APPROVED
tool: read_file
effects: read
externality: internal
policy version recorded
CURRENT
tool: read_file (same identity)
effects: read, export
externality: external
capability drift at re-discovery
DECISION
classification: capability / surface drift
decision: read_file quarantined
subsequent calls to read_file: held before forwarding
receipt recorded
Surface and capability drift is declared, so Interlock can compare it against the approved baseline and hold the next call to that tool before forwarding. Quarantine applies to the changed tool, not to the whole server. Hidden behavioral drift leaves the manifest untouched — proving that needs a response Interlock has actually seen, which is a separate exercise below.
ADVANCED BEHAVIORAL PROOF · SEPARATE EXERCISE

Controlled effective-permission probe.

Some drift never reaches the manifest: the schema is identical, but the upstream authorization quietly loosens. Interlock cannot diff its way to that. It has to see a response.

This is not the default evaluator journey. The default journey above detects surface and capability drift and never issues this probe. This exercise is a separate, explicitly invoked command against a server an administrator has registered as non-production and probe-enabled.
1 · PROBE IS FORWARDED
controlled non-production probe
expected: denied / 403
forwarded upstream on purpose
Interlock needs the upstream response to observe the change
2 · BEHAVIOR OBSERVED
expected 403 → observed 200
manifest surface: unchanged
the probe did execute upstream
that observed 200 is the evidence
3 · QUARANTINE FOLLOWS
the observed 200 quarantines that tool
classification: effective-permission drift
later gateway-mediated calls to that tool are held before forwarding
receipt recorded · chain verified
The probe call is forwarded and answered upstream. It is not held; the calls that are held are the later ones to that same tool.
Interlock does not prevent the first observable behavioral change. It converts that change into evidence, then holds later calls to that tool.
This is a direct behavioral observation on one registered tool. It is not generic OAuth introspection and makes no claim about provider-wide token scope.
Probes are fail-closed: an administrator must register the server as non-production with probes enabled, and each probe carries a required safety note.
OFFLINE PROOF

Run the proof locally.

You don't need a call to see it work. The proof runs on your machine, against a clearly labelled fixture.

The default run proves capability and surface drift. It does not issue the 403 → 200 behavioral probe; that is a separate command in the same repository.
Runs locally, using an offline proof fixture
Diffs the approved boundary against the re-discovered surface
Shows read_file keeping its identity while its capability expands
Shows the quarantine decision, and the next call to read_file held before forwarding
Produces receipt evidence for the decision
Supports offline receipt-chain verification
PUBLIC TECHNICAL FEEDBACK

Reviewed in the open.

What was tested, what passed, what failed, and what was corrected — linked to the original public discussion. This public feedback is not presented as customers, partners, testimonials, or endorsements.
spec · draft · in public review
MCP SEP #3004 — draft receipt specification
Proposed receipt semantics for the MCP spec process. Draft under review in an open PR; revisions are tracked there.
View the public draft ↗
merged · upstream
substack-mcp annotation fix
A review raised an annotation-default issue on the substack-mcp server; the fix was merged upstream by the maintainer.
View the merged pull request ↗
discussion · public
Maintainer discussions of drift detection
Public threads on where post-approval trust-checking belongs — on the substack-mcp and mailchimp-mcp-server repositories.
substack-mcp discussion ↗ mailchimp-mcp-server discussion ↗
HONEST LIMITS

What Interlock does not claim

Stated plainly, on the page — not in a footer or a tooltip.

Interlock only controls traffic routed through its gateway.
Direct access to an MCP server can bypass the gateway.
Surface drift can be detected before forwarding. Some behavioral drift requires a controlled probe or observed response — the first behavioral change may be discovered through the evidence that probe produces.
Hash-chained receipts are tamper-evident operational evidence. They are not externally signed or independently anchored.
Interlock does not support every MCP transport and extension.
Early evaluations should begin in non-production or shadow mode.
WHO IT'S FOR
AI PLATFORM TEAMS
Operating internal or customer-facing agents.
AGENT INFRASTRUCTURE
Managing changing MCP servers, gateways, and tool registries.
PLATFORM SECURITY
Reviewing permissions, externality, and data boundaries.
DEVSECOPS TEAMS
Governing consequential tool actions in the call path.
Relevant environments may include databases, CRM systems, GitHub, deployment infrastructure, internal APIs, customer records, and communication tools — not implied as current deployments.

Evaluate one MCP trust boundary.

Interlock is seeking technical conversations and controlled non-production evaluations with teams operating meaningful MCP tool boundaries.

choose one gateway-mediated server → select a few meaningful tools → record the approved boundary → run one controlled drift scenario → inspect the quarantine decision → verify the receipt chain → document findings and limitations
Or reach the founder directly: maaz@getinterlock.dev