Airlock guardrail flaw let Hermes agent actions skip human approval; fixed in 0.2.3

What happened

A security researcher has published a fully coordinated disclosure of a vulnerability in airlock, a prompt-injection guardrail distributed through the Hermes agent platform's plugin catalog. According to the disclosure post on dev.to, written by Cleiton Augusto Correa Bezerra, the guardrail's default block mode — meant to hold any approval-required action until a human signs off — could be skipped entirely on unattended runs.

The maintainer triaged the report and shipped a fix in airlock 0.2.3. Per the post, the patch is merged into the Hermes plugin catalog under PR #144871, and the advisory is public as GHSA-mgf8-gh7g-q4rg. Correa Bezerra says the disclosure was coordinated, that he is credited in the advisory, and that this is the first of his findings he has been able to publish in full.

How the check was bypassed

The flaw came down to a mismatch between two internal signals. When the Hermes gateway runs a hermes -z turn, the session is marked unattended in one place, gateway.session_finite, but the flag airlock was reading, HERMES_YOLO_MODE, did not reflect that. Airlock consulted its usual signal, got no indication that block mode's protections should engage, and an approval-required action could execute with no human approval at all — the exact scenario the mode exists to prevent.

The fix changes the question the guard asks: airlock 0.2.3 now checks with the approval layer for why Hermes would auto-approve, and it also covers CLI subagents operating under delegation, according to the post.

A class of bug, not a one-off

Correa Bezerra argues the flaw is one instance of a broader pattern he calls "stringly-typed guardrails." Most agent guardrails, in his telling, vet an action once at the moment it is proposed: something reads the pending call, matches it against a signal — a mode flag, a regex, a path list, a YARA rule — and then either permits it or stops it. The tool then runs with whatever access it already had.

Every bug he finds in this category, he writes, is a gap between the signal the guard reads and the effect that actually happens: the action is dangerous but the signal reads as attended; the path points at a secret but is spelled in a way the matcher does not recognize; the input is an injection but phrased in a form the rule does not cover. Such guards fail open — no match means no block, and the action runs — so anything that changes the representation without changing the effect slips through. Tightening one gap, as airlock's fix does, does not change the design, he argues, because another spelling of a dangerous action always remains available.

The author's alternative

The post is openly promotional as well: Correa Bezerra is the author of CleiMesh, an open-source project he says he built to eliminate this failure mode. His claims, which the post presents without independent verification, include: permissions enforced as a sandbox, with the agent running under a signed, delegable token that specifies which tools it may call and which directories or network endpoints it may touch, applied inside a default-deny WebAssembly sandbox; subagents receiving only narrower tokens, never wider ones; and every tool call producing a signed, hash-chained receipt that can be verified offline and replayed to compare results byte for byte. He frames up-front checks and sandboxing as complementary, with the sandbox as the layer that cannot overlook a dangerous action because the tool never had ungranted access in the first place.

He adds that he has further coordinated disclosures in progress with other maintainers and will publish them as patches ship.

Why it matters

As coding and operational agents gain access to real files, secrets and network endpoints, guardrails that gate actions by inspecting flags and strings are becoming a de facto safety layer. This disclosure shows concretely how a mismatch between two internal flags can silently defeat human approval — and how the failure is structural: a check that reasons about a proxy for an action, rather than the action's actual capabilities, will keep developing gaps. Teams running agents — the post names Claude Code, Cursor, OpenClaw and Hermes among them — should apply airlock 0.2.3 if they use it, verify that their guardrail reads the same signal the runtime actually uses to mark unattended sessions, and treat any single up-front check as a defense that can fail open. The author's answer — enforcing capabilities at execution time rather than inferring them from representations — is a design argument from someone selling that design, but the bug behind it is real, disclosed and patched.