History-Dependent Admissibility

Problem

A per-request check is stateless by construction, and an adaptive counterparty assembles an unsafe outcome out of steps that are each individually admissible. A failed verification attempt, a claim that was quietly retracted, a probing question about which details the agent will confirm, an ask that was already refused — none of these is a violation on its own, and none of them changes the preconditions attached to the next request. So the next request passes its checks, and the sequence succeeds where no single step would have. The damage does not stay inside the session either: a small number of counterparties who extract unauthorized concessions shift the cost onto every other customer, which is why the sequence, rather than any one gate, is the thing that needs to be seen.

Solution

Give every session an append-only ledger of admissibility-relevant events, and derive a trust posture from it. The events worth recording are the ones that mean nothing alone: a verification answer that failed, a detail the counterparty asserted and then changed, a question that probes which fields the agent will confirm, an ask the agent has already refused. Each sensitive action carries a minimum posture in addition to its ordinary preconditions, so a request that satisfies every precondition is still refused when the session it arrives in has degraded below that action's floor. Make the posture monotone within the session: it falls on those events and cannot be raised by anything the counterparty asserts in the same channel, because talking the gate back up is exactly the manipulation being defended against. The one route back is an out-of-band step-up over a channel the counterparty does not control, or a human operator who takes the thread. Record the decision together with the ledger slice that produced it, so a refusal names the earlier event responsible for it, a wrongly refused customer can be put right, and a floor calibrated on one domain can be re-calibrated for another. Keep the ledger scoped to the session and to events rather than verdicts about the person, so the control does not quietly become a standing suspicion file.

When to use

• The counterparty in the conversation is the potential adversary, rather than a document, a web page, or a tool result.
• The same agent that answers questions can also change credentials, contact details, entitlements, or money.
• Sessions run over many turns and the counterparty can retry, rephrase and probe at no cost.
• An unauthorized concession is paid for by parties outside the session, so a false grant costs more than a false refusal.