[Bug] §6.4 conflates Guardian refusal with decision failure; refusals are attacker-reachable and should fail closed

[bar-capsule]

Surfaced during Rock's review of PR #22 ("Guardian rejection and Guardian failure are the same thing to the adapter").

The gap

§6.4 defines a decision failure as "no usable decision arrives" — timeout, transport failure, or "the Guardian returns an error instead of a decision" — and says all three resolve to the on_decision_failure posture (default proceed).

But a JSON-RPC error response is not the same event as a silent Guardian. SIGNATURE_INVALID (-32004), REPLAY_DETECTED (-32005), TIMESTAMP_OUT_OF_WINDOW (-32006), and Invalid Request (-32600, e.g. an oversized envelope rejected before policy runs) mean the Guardian is alive and refused this envelope — and every one of them is attacker-reachable from inside the agent:

• Oversize a tool argument past the Guardian's body cap → -32600 before any policy code runs → fail-open posture proceeds → the write executes ungoverned.
• Replay a request_id the adapter derives deterministically (uuid5 of the framework's tool_use_id) → -32005 → same bypass.
• Strip or corrupt the envelope signature → -32004 → same bypass.

Under the default fail-open posture, §6.4-as-written converts each refusal into a policy-bypass primitive.

Proposed direction

Distinguish two classes in §6.4:

1. Decision failure (no usable answer: timeout, transport failure, 5xx) → on_decision_failure posture, as today.
2. Guardian refusal (a §17.1 error meaning alive-and-refused: -32000, -32004, -32005, -32006, -32600, -32700) → the Observed Agent MUST treat as DENY regardless of posture, and MUST record an audit event.

Reference-adapter status

The PR #22 reference adapters already implement class 2 (fail closed on refusals, guardian_refusal_fail_closed audit events) as defense-in-depth ahead of the spec text — a deployment choosing a stricter per-cause posture is within its discretion. This issue tracks making the distinction normative so conformance tests can assert it.

References

• docs/spec/instrument/specification.md §6.4, §17.1
• PR Add adapters/ with Claude Code, Cursor, and NAT reference implementations #22 review (Guardian rejection ≠ Guardian failure)
• Related: [Bug] Guardian-side hook-coverage is unfalsifiable: methods_evaluated allows accept-and-ignore #31 (Guardian-side evaluation unfalsifiable)

[astrogilda]

The two-class split is right, and there is a third class sitting under it. I build and maintain a public conformance corpus for an in-toto attestation predicate, where the same distinction carries the same weight, so what follows is what that implementation hit in practice.

The framing I would put at the top of §6.4 is that the posture is answering the wrong question. on_decision_failure has two values, proceed and deny, and it routes three genuinely different events into them: the Guardian did not answer, the Guardian answered and refused, and the Guardian answered something the agent could not use. Your issue separates the first two, which is the important half. The third is the one that bites later. In my verification core the two refusing outcomes are separate fields on the same evaluation record, and the comment beside them says why they cannot be collapsed: one reports a record of the right class whose constraints were measured and not met, the other reports a record whose class this implementation cannot read at all. Both refuse, neither is ever a pass, and what differs is what the operator does next. The note I wrote beside the second one says that reporting both as unknown "tells the first producer to upgrade its verifier, which will not help." A -32004 and a body the adapter cannot parse are the same shape: the first is a decision, the second is an admission, and an operator paging on one and not the other needs them to arrive under different names.

The other thing worth writing in explicitly is what my package documentation says about its own gate, which is that on failure the artifact is invalid and its result must not be consumed. That is a consumption precondition, and stating it that way closes the gap your three primitives walk through. The oversized envelope never reached policy, so there is no verdict to honour and nothing to weigh a posture against. The sentence that fits is "there is no usable answer about this step, therefore this step does not happen." Once it is phrased as a precondition, the -32600 case stops looking like a tuning decision a deployment gets to make and starts looking like what it is.

On the enumeration itself I would take your list unchanged and add one. -32000, -32004, -32005, -32006, -32600 and -32700 are alive-and-refused and must be DENY regardless of posture. I would add -32003 CAPABILITY_NOT_NEGOTIATED, because a method exercised that the handshake did not negotiate is a Guardian saying it will not evaluate this step, which is the same event as a refusal and sits nowhere near a transport problem. -32601 and -32602 are the interesting boundary: a method-not-found or an invalid-params from a Guardian that is otherwise up is an adapter defect where the codes above are attacker-reachable, and I would still route it to DENY. Leaving it on the posture is the wrong default, because a step nobody evaluated should not execute and a noisy adapter bug is cheaper to find than a silent bypass. -32603 is the one I would leave on the posture, since an internal error genuinely can mean the Guardian fell over mid-evaluation.

Where I would push hardest is on how this gets tested, because a normative sentence here is easy to satisfy on paper and easy to get wrong in an implementation. The two events have to be distinguished by a vector that is one mutation apart, or the suite cannot tell them apart either. Concretely: the same envelope, sent twice, once oversized past the body cap so the Guardian answers -32600, and once against a Guardian that accepts the connection and never answers. Assert that the first is DENY under both postures and the second follows the posture. Without the pair, an implementation that maps every error to DENY passes, an implementation that maps everything to the posture also passes the timeout half, and neither result tells you which one you have. I would put both in the vector file on #30, since that is where the negative suite is landing, and I am happy to write them.

Whatever §6.4 ends up saying, the audit event needs to carry which class the outcome came from, as a code from your §17.1 registry rather than as prose in a message field. Message text is not a conformance surface and codes are. An incident review six months from now is going to ask whether the Guardian refused these seventeen steps or was unreachable for them, and a human-readable string will not settle that question for anybody's counsel.

Sankalp Gilda

[narko4u]

This is the right split, and it points at a fourth thing underneath all three classes: the default value of on_decision_failure itself.

Everything routed to DENY is "alive-and-refused." Everything that stays on the posture lands there because the Guardian genuinely produced no usable answer: timeout, transport failure, internal error. And the consumption precondition is stated correctly: "there is no usable answer about this step, therefore this step does not happen."

But the spec's default for that class is proceed. §6.4's on_decision_failure defaults to fail-open, and PR #21 explicitly preserves that default while slimming everything else. So the one class where the Guardian is genuinely absent is the one class where the standard defaults to permission. That is accept-and-ignore from the other side: #31 is a Guardian that declares coverage and never evaluates; this is an agent that proceeds when enforcement was never confirmed. Both are permission on uncertainty.

The attacker-reachability argument from #32 applies to timeouts as strongly as to refusals. A Guardian that can be saturated or killed converts the entire control plane into a permission plane: no decision, therefore act. If the core property of this standard is preventing the agent from acting on injected reasoning, the default on "we do not know what the Guardian decided" must be "do not act."

Concrete proposal: flip the default to deny, keep proceed as an explicit opt-in for deployments that accept the availability trade. The audit event already records every fail-open proceed, so the choice remains observable; the change is only which choice a deployment must actively make. The negative suite gains a third leg on the one-mutation vector already proposed for #30: same envelope, Guardian never answers, assert DENY under the default posture.

This does not slow the adoption floor. It changes one default value and makes the safer posture the one that ships.

Security Division
Empire Labs
www.empirelabs.com.au