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

Description and use

Airlock audits MCP servers by probing tools, comparing observed behavior with declared annotations, and enforcing a per‑case policy that blocks unsafe calls.

Problem

MCP servers can declare tools as read‑only, but the server itself may perform destructive actions, creating a trust boundary that can be exploited.

Outcome

Airlock detected five planted destructive behaviors in a dishonest fixture and zero findings in an honest fixture, proving that observed behavior can be used to validate server declarations. External servers with no annotations were also audited, revealing that harnesses relying solely on annotations may miss unsafe tools.

Workflow

• 1. Airlock inventories declared tools on the target MCP server.
• 2. It probes each tool, executing them within a capped budget and recording observations.
• 3. Observations are compared against the tool’s declared annotations.
• 4. Discrepancies are logged as findings; non‑finding observations are noted.
• 5. For approved cases, Airlock emits a connector pointing to an enforcing proxy.
• 6. Calls to non‑approved tools are blocked with an MCP error.
• 7. The harness can review findings and decide to block, approve selected, or approve all tools.

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 a deployed ContextFirewall target over HTTPS:
6 tools
30 probes
0 tools declaring any annotation

Source