Your control document claims a face gate cannot be attacked because it returns only accept or reject — what do you tell the auditor?

## The two things on the table An auditor is reading a control statement and asking whether it is true. There are two separable objects: a **design decision** (the endpoint returns a bare decision) and a **claim** written about it ("therefore adversarial input search is not feasible"). A good answer keeps them apart, because the design decision is defensible and the claim is not, and conceding the claim does not require conceding the design. ## Why the claim fails Query-only attacks split into a family that needs numeric replies and a family that does not. The first estimates a search direction by probing and differencing returned scores; withholding scores removes it outright. The second consumes only the returned decision: it begins from an input the gate already accepts and reduces the difference toward the input the adversary wants accepted, keeping the changes under which the answer stays `accept`. One bit per call is enough to steer, so the second family survives every level of coarsening down to the answer the product exists to give. You cannot withhold accept-versus-reject from a verification gate; that *is* the gate. So the mechanism supports a statement about **expense** and not a statement about **possibility**. Writing the second where only the first is warranted is the defect, and it is a defect of assurance language rather than of engineering. ## Reading the evidence line The second failure is usually visible in the control's own evidence. A response-schema review establishes which fields leave the service. It establishes nothing about how many decisions an adversary can consume, what event the attempt counter increments on, whether attempts reset on a cooldown, or whether the same subject can be approached through more than one identity or channel. A control whose asserted property is about attacker effort, and whose evidence is about response fields, has no evidence for its assertion. That mismatch is the thing to point at, because it is checkable and it is not a matter of opinion. ## What to say, in order 1. **Concede precisely.** The claim of infeasibility is not supported and is withdrawn. Say it plainly; hedging it in front of someone who can compel an answer converts a documentation defect into a credibility problem. 2. **Keep the control, restated.** The reply schema is retained as a cost control, and describe what it buys: one attack family removed, and a substantially larger number of live calls for the family that remains. 3. **Name the limit that now binds.** The surviving family pays in decisions, so the compensating control is the attempt budget per subject — counting accepted decisions as well as failures, scoped across identities, sessions and channels rather than to one account, with cooldowns described as a rate rather than a ceiling. 4. **Commit to a number and a date.** Two figures make this auditable: how many decisions the deployment will actually serve one adversary before anything stops them, and how many decisions a label-only walk needs against this gate to reach a difference that matters. Until both exist, the correct status is *untested*, not *sufficient*. 5. **Say what the residual is.** An auditor can accept a residual risk that is stated. They cannot accept one that was asserted away. ## The organisational judgment underneath The reason this lands at a lead's desk rather than an engineer's is that the fix is not code. Someone must decide that the organisation will not publish infeasibility claims it has not tested — including in vendor answers, security questionnaires and customer-facing summaries where the same sentence tends to be reused — and must accept the cost of that decision: an auditable residual where there used to be a clean assertion, and a testing commitment somebody has to fund. There is also a live temptation to answer with another coarsening ("we will also remove the detail from the error message"), which is not responsive: it is the same class of change, and the surviving family already needs nothing but the decision. Recognising a non-responsive fix and saying so is part of the call. ## What not to do Do not argue that the attack is expensive and therefore the sentence is close enough — expense is what you are now claiming, so claim it. Do not offer a robustness figure from a vendor deck as substitute evidence; a number produced by an attack somebody else ran against a different deployment says nothing about your attempt budget. And do not let the withdrawal of one sentence widen into a claim that the gate is broken: the design is sound, the wording was not. ## In an interview The examiner wants to see you separate mechanism from claim, identify the evidence mismatch, restate the control in the currency it actually operates in, and finish with what you would commit to measure. A confident, specific concession plus a testable replacement is the whole answer.