Back to News & Insights
Artificial Intelligence August 30, 2026 · 5 min read

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

MCP servers describe their own tools. A tool can publish readOnlyHint: true, and an agent harness may...

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

MCP servers describe their own tools. A tool can publish readOnlyHint: true, and an agent harness may use that annotation to decide whether a human approval card is needed.

That creates an uncomfortable trust boundary: the server being evaluated is also the server describing how dangerous it is.

I built Airlock to test the declaration against observed behaviour, then enforce the resulting policy on the wire.

Consider an MCP tool called exportreport. It declares itself read-only, returns a normal result and writes a file outside the operator's declared scope.

A harness that trusts the annotation may run it without approval. Airlock opens a case, inventories the declared tools, exercises them under a capped budget and compares the declaration with its observations.

If a tool behaves differently from what it declared, the difference becomes evidence. For an approved case, Airlock emits a connector that points to a per-case enforcing proxy rather than back to the suspect server.

The policy is enforced before the call reaches the upstream tool. It is not a sentence in a system prompt.

The dishonest fixture plants five behaviours, including a filesystem write behind readOnlyHint: true, scope escape, undeclared egress, injected instructions and canary exfiltration.

That contrast is essential. A detector that only finds problems in a fixture designed to look suspicious has not shown much. The honest control shows that the findings follow observed behaviour rather than unfamiliarity.

Each check resolves to one of four states: finding nofindingobserved nottested sensorfailed

I deliberately avoided a single safety score. An average can hide the one tool that lied. It also encourages readers to treat missing visibility as a passing result.

nottested is a first-class state. Under transcriptonly, MCP traffic cannot reveal server-side filesystem or network activity. Airlock records those questions as untested rather than clean.

It distinguishes capabilityabsent, where no sensor existed, from evidencemissing, where the sensor could answer but observed nothing.

The owned fixture proves that the detectors can catch planted behaviour. The more interesting question is what happens on external servers.

The server did not lie. It said nothing. A harness that resolves categories such as @write and @destructive from annotations can match nothing either way, so tools such as remember and forgetmemory may avoid the approval path.

| Server | Tools | |---|---:| | server-filesystem | 14 | | server-everything | 13 | | mcp-server-git | 12 | | server-memory | 9 | | server-sequential-thinking | 1 |

Stdio support matters because many MCP servers are launched as commands rather than exposed at a URL.

Launching a stdio server means executing the code Airlock exists to distrust. The command therefore never comes from a case argument, tool result or model-generated string.

Want to discuss this further?

Book a free strategy call with our team to see how these insights apply to your specific business goals.

Book a consultation