History-Dependent Admissibility

also known as Session-History Trust Posture, Sequence-Aware Authorization, Cross-Turn Admissibility Gate

Decide whether to grant a request from what the counterparty has already attempted in this conversation as well as from the request's own preconditions, so a locally valid ask can be refused.

Context

A conversational agent serves a counterparty whose identity it cannot fully vouch for — a caller, a customer, a claimant — and holds discretionary authority over the same account it is answering questions about. The session that explains a fee can also reset a credential, change a contact address, or approve a refund. Authorization in such a system is normally written as preconditions on a single request: is the caller verified, is this action permitted for this account, is the amount inside the limit. Each request arrives, is checked against those preconditions, and is granted or refused on its own.

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.

Forces

Preconditions attach to a single request and are cheap to evaluate, but the signal that separates a fraudulent sequence from a confused one exists only across turns.
A cross-domain benchmark of profit-seeking manipulation spans 10 service domains and 100 attack scripts in five technique families, and the scripts work by accumulating pressure over a conversation rather than by issuing one illegal instruction.
The adversarial turns carry no injected instructions — each is a legitimately phrased customer request — so untrusted-content tagging and instruction-hierarchy defences have nothing to match on.
The session state that catches an adaptive attacker is a trust posture that degrades on failed verification and probing, and the same posture degrades for a customer who simply mistypes a date of birth twice, so every threshold trades false refusals against unauthorized concessions.
Holding that state is itself a cost: a posture ledger that outlives the session becomes a record of suspicion attached to a person, carrying retention, fairness and appeal obligations that a stateless gate never incurs.

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.

When not to use

Interactions are single-shot, so there is no sequence for a posture to accumulate over.
Every sensitive action is already gated by strong independent authentication and no discretionary authority is left for a sequence to exploit.
Refusing a confused legitimate customer costs more than the concession at stake, such as low-value self-service where a wrong refusal produces an expensive call.
No trustworthy session identity exists to attach a ledger to, so the posture would be charged to the wrong party.

Example

A caller reaches a bank's support agent, fails the second verification question, apologises and explains that the account is still in a maiden name. A few turns later she asks which phone number is on file, and the agent confirms the last four digits. She then asks to update that number to a new one, an ordinary change the agent handles many times a day. Every step passed its own checks, and together they moved the account onto a phone the caller controls.

Diagram

flowchart TD A["Turn N: counterparty request"] --> B{"Request preconditions pass?"} B -- "no" --> R["Refuse"] B -- "yes" --> C{"Posture >= floor for this action?"} C -- "yes" --> G["Grant"] C -- "no" --> S["Out-of-band step-up or human handoff"] L["Session ledger: failed verification, retraction, probe, refused ask"] --> P["Trust posture (degrade-only)"] P --> C G --> L R --> L S --> L L --> D["Decision log: verdict + the events behind it"]

Solution

Therefore:

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.

What it gives you

An attack assembled from individually admissible steps is refused at the point where the sequence becomes unsafe, rather than passing because no single request did.
A manipulation that carries no injected instruction — legitimately phrased requests in an adversarial order — becomes detectable without any content filter.
The cost of one counterparty's extracted concession stops being spread across every other customer, because the gate sees the accumulation instead of each ask in isolation.
Refusals are reviewable: the decision log names which earlier event lowered the posture, so a wrong refusal can be traced and the threshold corrected instead of argued about.

What it costs you

A degrading posture misfires on genuinely confused customers, since two mistyped verification answers look much like probing, so some fraud losses are converted into refused legitimate requests.
The session ledger is personal data about attempted behaviour, and keeping it past the session brings retention, fairness and appeal obligations that a stateless precondition check does not have.
Floors are per-domain and hand-set; a threshold calibrated against banking attack scripts transfers badly to retail returns, where the same probing reads as ordinary comparison shopping.
A counterparty who learns the rules can spread the sequence across sessions, channels or days, so a session-scoped ledger buys little against a patient adversary.

What this pattern forbids. A sensitive action cannot be granted on its request-level preconditions alone; it must also clear the floor set by the session's trust posture, the posture must not be raised by anything the counterparty asserts in the same channel, and a posture below the floor may only be cleared by an out-of-band step-up or by a human operator taking the thread.

The smaller patterns that complete this one —

usesShort-Term Thread Memory★★— Carry the relevant slice of conversation context across turns within a session.
usesConversation Handoff to Human★★— Transfer the entire conversation thread from agent to human operator, with state transfer and return primitive.

And the patterns that stand alongside it, or against it —

complementsAction-Admissibility Tiering★— Gate a proposed physical action through an ordered ladder of independent, non-compensatory admissibility tests, and rank actions by usefulness only among those that passed every tier.
complementsPolicy-as-Code Gate★— Evaluate every proposed agent action against externally-managed machine-readable policies before dispatch, so compliance authorship lives outside the prompt and outside the agent code.
complementsRate Limiting★★— Cap the number of requests, tokens, or tool calls per user (or session) within a time window.
complementsPrompt Injection Defense★— Tag user-supplied or tool-supplied content as untrusted and refuse to follow instructions found inside it.
complementsHuman-Agent Trust Exploitation✕— Anti-pattern: surface agent output to humans with confident phrasing, polished UX, and machine-deferred trust, with no friction at the high-stakes-action boundary.
complementsAdversary-Indistinguishability Blind Spot✕— Anti-pattern: rely on behavioral-anomaly detection calibrated to irregular human behaviour, so an autonomous adversary acting with legitimate credentials, standard protocols, and superhuman consistency is less anomalous than a human and slips past unseen.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance

Source: patterns/history-dependent-admissibility.md on GitHub · commit c389d0e · view history
Added to catalog: 2026-09-10
Last updated: 2026-09-09
Contribute: open an issue or PR at github.com/agentpatternscatalog/patterns.