A permission scan keyed on the gated verb misses a request that entails the act without naming it

The lesson

A guard that reads a request for permission is doing translation, not matching. The request is phrased in the vocabulary of what the person wants to be true afterwards; the guard is phrased in the vocabulary of the operation it intercepts. Those two vocabularies overlap often enough that a word-level scan looks like it works, and they diverge exactly when someone asks for a compound outcome — the case where the stakes are highest, because a compound outcome is several irreversible steps at once.

The asymmetry that makes this a design error rather than a tuning problem: a request can entail an act without naming it, but it cannot name an act it does not entail. So the scan's false negatives are structural and its false positives are not. Widening the word list does not fix it, because the missing grants are not synonyms of the gated verb — they are its consequences. "Ship it", "land this", "publish the update", "get it onto the branch" each entail steps whose names appear nowhere in them.

Three properties make the failure worse than an ordinary miss:

The denial is unfalsifiable from inside the gate. The gate observes only that the word is absent, which is equally consistent with "not authorised" and "authorised by implication". It has no way to tell the two apart, and it resolves the ambiguity in the direction that generates work.

The compliance path is already complete. These gates usually say "ask the person and try again". But the person's request was the answer; asking re-poses a question they already addressed, and their likely reply — a shorter, more irritated version of the same sentence — is no more likely to contain the word. The prescribed remedy has the same blind spot as the check.

The fixtures cannot catch it. Someone writing a test for a grant detector writes a fixture where the grant is stated, and the natural way to state it is with the word being detected. The whole class of entailing requests is invisible to a test suite authored by anyone who already knows which word matters. Every test passes and the gate is believed.

The failure that taught it

An agent harness had a pre-execution gate on an irreversible version-control operation. It matched the command by name, then scanned the recent conversation record for evidence that the person had asked for it, excluding machine-injected turns and negated sentences — careful work, and the careful parts were all correct. Its own denial cap and fail-open behaviour were tested by planting every state.

The person then asked, in plain terms, for the pending work to be published to the remote. That request is unambiguous and it authorises the intermediate step by necessity: the changes were not recorded yet, so there was nothing to publish until they were. The scan found no occurrence of the intermediate step's name, concluded nobody had asked, and refused.

It refused three times. The second attempt carried an explicit statement that the request had already been made and was only being carried out — the gate's own suggested remedy for exactly this situation — and the scan, still looking for the same word, denied that too. The operation completed only when the denial cap was exhausted and the gate failed open, which is the safety valve doing its job to compensate for the check being wrong, rather than the check being right.

The design note written alongside the gate had anticipated a different false positive: a sentence mentioning the operation in a context that was not a request. It had not anticipated a request containing no such sentence at all. The reasoning that made the gate tolerable — every misread is a denial, and one sentence from the person clears it — held for the anticipated case and failed for this one, because no sentence the person would naturally write clears it.

How to apply it

• Match the grant on the outcome, not on the operation. Enumerate what a person plausibly says when they want this to happen, before writing any pattern. If the list is dominated by words that are not the operation's own name, a scan for that name is the wrong instrument.
• Ask what the request entails, not what it mentions. A gated step reachable only as part of a larger outcome must accept authorisation of that outcome. Where one act is a strict prerequisite of another, permission for the second is permission for the first.
• Write the fixture for the entailing request first. A grant detector tested only on requests that name the act is tested on the half that was never in doubt. The honest test is a sentence a real person would write that authorises the act without containing its name — and it should be authored by someone told the outcome rather than the mechanism, because anyone who knows the word will use it.
• Check that the prescribed remedy is not blind in the same way. "Ask and retry" is only a remedy if the expected answer would pass the check. When the natural reply repeats the phrasing that already failed, the gate has no exit and the denial cap becomes the real control.
• Treat cap exhaustion as a defect report about the gate. A control that fails open because it ran out of denials on a legitimate request has just recorded the strongest evidence available that its predicate is wrong. That event should be as loud as a violation, not quietly the mechanism by which work gets done.
• Suspect this whenever a check re-fires after being told it was already satisfied. Repeated denial in the face of an explicit statement of prior authorisation means the check is reading a channel that cannot carry the answer, not that the answer is missing.