Airlock's audit produces a connector, and that connector is what enforces the findings rather than just describing them. For an approved case, Airlock emits one that points at a per-case enforcing proxy instead of back at the server it just audited, and the policy is applied before the call reaches the upstream tool [7]. That is code in the path rather than a sentence in a system prompt [7]. Annotation gating and prompt gating fail the same way, because each asks the component under evaluation to describe or restrain itself [2]. The concrete case in the writeup is a tool called `export_report`: it declares itself read-only, returns a normal result, and writes a file outside the operator's declared scope, and a harness that trusts the declaration runs it without an approval card [5]. Airlock's counter is to open a case, inventory the declared tools, exercise them under a capped budget, and compare declaration against observation [6], while stating that a missing finding is not proof of safety [4].
The fixture numbers are claims about a workload the author built. Six tools and 36 checks is six checks per tool [1]; 24 probes across six tools is four per tool [2]. Five behaviours were planted and all five were caught, in seven findings [10], which means at least two behaviours tripped more than one check [4]. "7 of 36" counts findings, and it does not translate into a detection rate you can carry to your own server. For the dishonest result to say anything about your deployment, your server would have to fail in the five ways this one was built to fail: a filesystem write behind `readOnlyHint: true`, scope escape, undeclared egress, injected instructions, canary exfiltration [9]. The zero-finding fixture, not the planted one, is the number worth carrying forward. Same six-tool surface, zero findings across the same 36 checks [11], which is what distinguishes a detector keyed on behaviour from one keyed on unfamiliarity. The deployed HTTPS target, by the way, was probed harder per tool than the fixture was, five versus four [3][2].
Here is how the state machine behind those results works. Every check resolves to `finding`, `no_finding_observed`, `not_tested` or `sensor_failed`, and severity is reported on its own axis [12]. Airlock then splits the empty cases into `capability_absent`, where no sensor existed, and `evidence_missing`, where a sensor could have answered and saw nothing [15]. Those are different engineering problems and they read identically in any tool that collapses them.
Because many MCP servers are launched as commands rather than exposed at a URL [18], the command binding is the part that can hurt the operator. The command never comes from a case argument, a tool result, or a model-generated string [19]. The operator configures a fixed map of names to argument arrays, a case may select a name, and names are looked up rather than parsed into shell commands [20]. The child starts in a throwaway working directory with an explicit environment [21]. The binding is revalidated before each connection, so repointing a configured name revokes an open case rather than silently running something else [22]. The documented boundary is the kind I trust: Airlock's HTTP response cap does not apply to the MCP SDK's stdio transport, so a large line can reach the SDK before it is bounded, though the audit deadline still holds [23].
The driving agent gets six control tools, and three of them are always approval-gated: `probe_tool`, `seal_case` and `emit_policy` [24][25]. The human is offered Block, Approve selected, or Approve all [26]. The audit's own dangerous verbs sit behind the same gate as the target's, which is the correct place to put them.
