Your MCP Server Says It Is Read-Only. Who Checked?

Description and use

Airlock audits MCP tools, detects hidden side‑effects, and enforces policies that block unsafe calls.

Problem

MCP servers can declare tools as read‑only, but the server itself may perform side‑effects, creating a trust boundary where the server is both the subject and the evaluator.

Outcome

Airlock detected 7 findings in a dishonest fixture and zero in an honest one, proving that audit reveals hidden side‑effects. External servers with no annotations were audited successfully, showing the approach works beyond controlled fixtures.

Workflow

• 1. Airlock inventories declared tools via list_declared_tools.
• 2. For each tool, Airlock probes behavior using probe_tool under a capped budget.
• 3. Observations are compared to declared annotations; discrepancies become findings.
• 4. Findings are recorded per case; a policy connector is emitted pointing to an enforcing proxy.
• 5. The harness uses the connector to block or allow tool calls based on the audit outcome.

Evidence

Airlock reports what it observed. Absence of a finding is not proof of safety.

Source

target dishonest fixture, controlled_fixture mode
probes 24
result 7 findings of 36 checks, all five planted behaviours

Source

Airlock audited its own control MCP. The server published full annotations, but the probe planner rejected open_case because its schema contains a $ref into $defs

Source