Skip to content

Confused-Deputy Abuse-Case Test

Adversarial test — instantiates Principal-Bound Authority Mediation

Deliberately constructs forged, replayed, and context-stripped requests that try to make a deputy spend its authority for an unentitled originator, and confirms each one is refused or stepped up.

A mediation design can look correct on the whiteboard and still leak authority through a path nobody drew. Confused-Deputy Abuse-Case Test is the adversarial exercise that goes looking for those paths on purpose: it enumerates the ways an unprivileged actor could induce a privileged deputy to act on its behalf, turns each into an executable probe, and asserts that the system denies, narrows, challenges, or escalates every one. It is defined by its stance — it is the party that attacks the boundary rather than one that guards it, and its output is not a decision or a record but a pass/fail verdict on whether the coupling between principal and authority actually holds under pressure. The name points at the classic failure it hunts: the deputy that is not compromised, just confused about whose will it is serving.[1]

Example

A tax-filing platform is weeks from opening its next season. Its filing service holds broad authority — it can read any household's prior returns and submit to the revenue agency — because it acts on behalf of whichever taxpayer is logged in. Before launch, the security team runs an abuse-case test against that boundary. They write a probe matrix: a request that carries taxpayer A's session but B's return ID; a valid on-behalf-of token replayed an hour after logout; a request arriving from the internal reconciliation queue with the subject field stripped; a preparer account reaching across into a client it was never delegated. Each probe is fired at the real staging service and each has a single expected verdict — refused, or bumped to step-up.

Eight of nine behave. The ninth surfaces the bug that matters: when the subject-bound request is rejected, the service silently retries the read using its own standing credential and returns the neighbor's return. Nothing inside the deputy is broken — it processed a valid input with valid authority. The test is what made the ambient-fallback path visible, and the fix (fail closed instead of falling back) ships before any real taxpayer touches it.

How it works

The test is a construction-and-assertion loop, not a scan:

  • Enumerate inducements. For each sensitive deputy, list the ways an outsider could shape a request it will honor: forged or swapped principal, replayed or stale delegation, stripped tenant/subject context, cross-tenant reach, and — the highest-yield case — the ambient-fallback retry, where a deputy that correctly rejects a scoped request quietly re-issues it under its own broad credential.
  • Make each an executable probe. Every inducement becomes a concrete request against a real (staging) deputy, paired with the one verdict that would prove the boundary held.
  • Assert the safe verdict. A probe passes only if the system denies or steps up; a locally-valid success is the failure signal. This inverts ordinary testing, where success is the pass.
  • Chase the fallback specifically. Because the deputy's own authority is the thing being laundered, the test always includes a probe that removes the scoped path and checks the deputy does not substitute standing power.

Tuning parameters

  • Probe breadth — how many inducement classes and how many boundaries you cover. Wider catches more but costs authoring time; concentrate on the deputies whose authority most exceeds their callers'.
  • Adversary model — how much the simulated attacker knows (a stranger, a low-privilege tenant, a malicious insider preparer). A stronger model finds subtler laundering but raises more findings to triage.
  • Realism of the target — probing a mock versus the live staging deputy. Mocks are cheap but miss exactly the ambient-fallback path that only the real credential graph exposes.
  • Regression cadence — one-shot pre-launch versus a suite re-run on every deploy. Standing suites catch reintroduced fallbacks but must be maintained against interface drift.
  • Verdict strictness — whether a step-up counts as a pass or only a hard deny does. Loose strictness reduces noise; tight strictness surfaces boundaries that lean on friction instead of refusal.

When it helps, and when it misleads

Its strength is that it finds the failures that have no broken rule — the confused-deputy bug is precisely the one that passes unit tests because every component did its job. By demonstrating an authority-laundering path rather than arguing one is possible, it converts a design debate into a reproducible defect, and its ambient-fallback probes hit the archetype's single most common failure mode head-on.

Its honest limit is that a test only covers the inducements someone thought to write. A green suite proves the enumerated attacks fail, not that the boundary is sound — the classic misuse is to treat passing probes as a security guarantee and stop, when the un-imagined path is the one that ships. It can also breed false confidence when run against mocks that never exercise the real standing credentials. The discipline that keeps it honest is to treat the probe set as a living, adversary-driven artifact, grow it from every near-miss and incident, and pair it with review of why each boundary holds rather than only that it did today.

How it implements the components

  • abuse_case_probe_set — its core deliverable: the enumerated, executable matrix of forged, replayed, stripped, cross-tenant, and fallback inducements.
  • deny_or_step_up_default — every probe asserts this default; the test's pass condition is that missing or contradictory context produces a deny or step-up rather than a silent success.
  • ambient_authority_exclusion — the signature probe checks that a deputy denied its scoped path does not fall back to standing authority, exercising the exclusion directly.

It does not record who caused what for later review — that after-the-fact accountability_binding_record and request_provenance_trace are Delegation Audit Log's job; this mechanism is the proactive attacker, its twin the passive historian.

Editorial Notes

Form Classification

Form family: Experiment, Test & Rehearsal

Rationale: Deliberately constructs forged, replayed, and context-stripped requests that try to make a deputy spend its authority for an unentitled originator, and confirms each one is refused or stepped up, making its operative form a bounded trial, probe, simulation, or adversarial exercise that generates evidence from performance.

Independent corroboration: The frozen evidence defines Confused-Deputy Abuse-Case Test as 'Deliberately constructs forged, replayed, and context-stripped requests that try to make a deputy spend its authority for an unentitled originator, and confirms each one is refused or stepped up', so its operative form is Experiment, Test & Rehearsal.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution

Primary origin: Computer Science & Software Engineering

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Specialized

Rationale: Computer security established the confused-deputy threat model and adversarial tests for authority misuse through forged or context-stripped requests.

Related originating lineages:

Review resolution: Both reviewers agree on computer_science as primary. Reading the source mechanism confirms that its defining operation belongs to that lineage; the final record retains security_intelligence only where it materially formed the mechanism and keeps present-day application breadth separate from provenance.

Review outcome: Reconciled after independent review; high confidence.

References

[1] Hardy, N. “The Confused Deputy: (or why capabilities might have been invented)”. ACM SIGOPS Operating Systems Review 22(4), 36–38 (1988). Shows an uncompromised deputy misapplying authority because it cannot distinguish which principal’s authority governs a request. registry