Interlock baselines the approved tool boundary, detects material capability or observed behavioral drift, quarantines the changed gateway-mediated call, and records hash-chained evidence.
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.
Interlock sits in the call path, compares every later call against the boundary an operator approved, and records what it decided.
The first thing you see is the drift review queue: the approved baseline, expected-versus-observed evidence, the quarantine decision, forwarding status, and the receipt — with approve, reject, or rebaseline one action away.
Schema drift shows up in the surface diff. Behavioral drift shows up only in observed evidence — same manifest, different runtime behavior.
You don't need a call to see it work. The proof runs on your machine, against a clearly labelled fixture.
Stated plainly, on the page — not in a footer or a tooltip.
Interlock is seeking technical conversations and controlled non-production evaluations with teams operating meaningful MCP tool boundaries.