Principal Bound Authority Mediation

Let a deputy act only when the requesting principal, stated intent, delegated scope, and use of the deputy’s authority are explicitly bound and checkable.

Essence

Principal-Bound Authority Mediation solves the case where a legitimate intermediary has power, but a request reaching that intermediary may have been caused by someone who lacks that power. The key move is to stop asking only whether the deputy can act. The system must ask who caused this request, what they meant to authorize, what they are allowed to authorize, and whether the deputy is allowed to spend its own execution authority for that scoped purpose.

This is why the pattern is distinct from ordinary access control or authentication. Authentication may prove that a browser session, user, service, token, document, or caller is real. Access control may prove that the deputy can reach the resource. The confused-deputy failure occurs in the space between those checks: the deputy executes with its own authority even though the originator’s authority and intent were never bound to the action.

Compression statement

When a service, proxy, agent, official, workflow, or credentialed intermediary can perform actions that an outsider cannot perform directly, treat the request as a three-party authority problem. Identify who originated the request, what action and purpose are being requested, what authority the originator has for that action, what authority the deputy would use to execute it, and whether a policy allows the deputy to spend that authority on the originator’s behalf. Reject or step up when the binding is absent, stale, overbroad, or unauditable.

Canonical formula: Execute D(action) only if bind(P, I, S, A_d, C, T) passes policy, where P is the originating principal, I is request intent, S is permitted scope for P, A_d is deputy execution authority, C is delegation/context evidence, and T is current freshness/use context. Otherwise deny, constrain, challenge, or escalate.

Structural problem

A deputy is useful because it mediates work: a proxy, service account, clerk, web server, browser, workflow, agent, or official can do something on another party’s behalf. The same mediation becomes hazardous when the deputy’s capability is broader than the requester’s capability. If the request path loses the originating principal, tenant, subject, purpose, consent, or authority scope, the deputy may perform an action that looks locally valid but is globally unauthorized.

The resulting error is not always a broken rule inside the deputy. The deputy may correctly process an input, call an internal API, use a session credential, or follow a workflow. The failure is that authority has become ambient: it is available to the deputy without remaining attached to the person or entity for whom the deputy is acting.

Intervention logic

The intervention makes mediated authority explicit. A sensitive deputy boundary should preserve at least five things before execution: the originating principal, the requested intent, the principal’s allowed scope, the deputy’s execution authority, and the evidence that these belong together for this use. The decision is not “does the deputy have permission?” but “is the deputy allowed to perform this action for this principal, purpose, resource, and context now?”

A robust design usually does three things. First, it strips away or constrains ambient authority so the deputy cannot fall back to broad standing power. Second, it carries scoped delegation evidence, such as a signed request context, capability, CSRF token, user-presence signal, workflow approval, or on-behalf-of token. Third, it logs cause and execution separately so later review can see both who induced the action and who executed it.

Key components

Component	Description
Originating Principal Claim ↗	names the actor, tenant, user, role, beneficiary, or authority source whose will is being served. Without this, a deputy action is attributed only to the intermediary.
Request Intent Scope ↗	describes the action, resource, purpose, and intended effect. It prevents generic credentials from being replayed into different actions.
Deputy Execution Authority ↗	is the standing capability or office that makes the intermediary useful. The pattern treats it as a constrained resource, not a blank check.
Principal Authority Coupling Rule ↗	is the core guardrail. It says when the deputy may spend its authority for this principal and when it must deny, narrow, challenge, or escalate.
Ambient Authority Exclusion ↗	prevents automatic cookies, inherited service roles, internal network trust, or broad administrative accounts from substituting for explicit delegation.
Delegation Context Record ↗	carries scope, freshness, tenant, consent, approver, channel, audience, and revocation information. It is the bridge between authentication and authorization.
Request Provenance Trace ↗	and Accountability Binding Record make the action reviewable by preserving the causal chain from request to execution.

Common mechanisms

CSRF token challenges, origin checks, SameSite policies, and user-presence prompts are web-security mechanisms for the browser/session variant. They work by adding request-bound evidence that the action was intentionally initiated through the expected channel.

Signed delegation tokens, on-behalf-of flows, scoped service-account impersonation, and policy-engine subject checks are service-to-service mechanisms. They allow a downstream service to evaluate the real requester’s authority rather than accepting a broad internal credential.

Object-capability references are a stronger architectural mechanism: instead of asking a deputy to infer authority from identity or role, the requester passes a narrow, unforgeable reference that already carries the permitted action or object.

Audit logs, abuse-case tests, and access recertification do not replace prevention, but they keep the mediation design honest. They reveal fallback paths where context is stripped, tokens are overbroad, or service accounts have accumulated excessive privilege.

Parameter dimensions

Important design parameters include action sensitivity, authority asymmetry between requester and deputy, token or delegation freshness, scope granularity, tenant or subject isolation, reversibility of action, acceptable friction, audit retention, privacy exposure, and the feasibility of replacing ambient authority with scoped capabilities.

Low-risk actions may need only lightweight subject binding and logging. High-risk actions may require step-up confirmation, dual authorization, short-lived delegation, explicit user presence, or human review. Multi-tenant systems need especially careful subject and tenant partitioning because a deputy’s technical ability to cross tenant boundaries is often much broader than any requester’s legitimate authority.

Invariants to preserve

The originator must remain attached to the request. The purpose must remain attached to the action. The deputy’s authority must not exceed the originator’s permitted scope for that action. Delegation evidence must be current enough for the use context. Missing context must fail closed or move to explicit review. Audit must preserve both cause and execution.

Target outcomes

When the archetype works, borrowed-authority attacks become harder, service accounts can be broad enough to operate without becoming authority laundering channels, user intent is distinguished from ambient session presence, and accountability records show who caused what under which delegated scope.

Tradeoffs and failure modes

The main tradeoff is friction. Stronger request-bound evidence protects sensitive actions but may interrupt legitimate workflows. Another tradeoff is privacy: preserving principal and purpose context improves accountability but can expose metadata if retained too broadly.

The most common failure mode is ambient authority fallback. A deputy rejects invalid scoped requests but then silently retries with its own broad credential. Another common failure is caller-context stripping, where a queue, proxy, worker, or service mesh hop removes the subject or tenant context needed for policy. Token scope overbreadth, generic confirmations, and logs that collapse requester and deputy into one actor are additional failure modes.

Neighbor distinctions

Least-Privilege Access Design asks how much authority the deputy should have. Principal-Bound Authority Mediation asks whether the deputy may spend that authority for this originator and intent. Evidence-Bound Authentication asks whether identity or origin evidence is admissible. This archetype asks what the deputy may do with that identity evidence. Use-Time Precondition Binding asks whether a prior check is still valid at execution. This archetype asks whose authority is being executed. Proxy Mediation and Gateway Mediation can host the solution, but they can also be the source of the confused-deputy problem when they forward or execute without preserving principal-bound context.

Examples

In web security, a logged-in browser may automatically send cookies to a site. A malicious page can cause the browser to send a state-changing request. The server must not treat the cookie alone as proof of user intent; it should require request-bound evidence such as a CSRF token, same-site protection, origin checks, or user confirmation.

In cloud platforms, a deployment service may hold broad service-account credentials. A safe design carries the requesting user, project, tenant, and permitted scope to downstream APIs, and each API evaluates the action as being on behalf of that caller rather than trusting the deployer service account alone.

In operating systems, a print service should not open arbitrary file paths named by a user merely because the service has file-system authority. A safer design passes a specific file handle or capability that the user was allowed to delegate.

In organizational workflows, a clerk with payment-system access should not convert any submitted document into a payment. The workflow must bind requester, approver, budget authority, vendor, amount, purpose, and policy record before the clerk executes.

Non-examples

A direct administrator using their own credential for an authorized action is not this pattern. A failed login is authentication, not confused-deputy mediation. A simple audit trail that records a service account after execution is not enough unless it also supports prevention and preserves the originator-deputy distinction. A proxy that forwards all requests using its own trust is more likely a problem instance than a solution.

Implementation checklist

1. Identify every deputy that can act with authority broader than some requesters.
2. List sensitive actions and resources the deputy can affect.
3. Define the originator, tenant, purpose, action, resource, and freshness context required for each action.
4. Remove ambient fallback paths or constrain them to safe defaults.
5. Choose a mechanism: CSRF token, signed delegation token, on-behalf-of flow, object capability, workflow approval, or policy-engine check.
6. Require deny, challenge, step-up, or escalation when context is missing or contradictory.
7. Log both causing principal and executing deputy with scope and policy decision.
8. Test forged, replayed, stripped-context, cross-tenant, and overbroad-deputy scenarios.
9. Periodically review service accounts, delegation scopes, token lifetimes, and audit quality.

Common Mechanisms

• Confused-Deputy Abuse-Case Test
• CSRF Token Challenge
• Delegation Audit Log
• Object-Capability Reference
• On-Behalf-Of Authorization Flow
• Origin and Referer Gate
• Policy-Engine Subject Binding Check
• Scoped Service-Account Impersonation
• Signed Delegation Token

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (7)

• Access Control: Restrict system access.
• Authentication: Binding an asserted identity or origin to admissible evidence through a procedure that yields a verdict, before trust, access, or weight is granted.
• Confused Deputy: A privileged intermediary acts on its own authority while the intent originated with an outsider who lacks it, so authority is borrowed without intent being tracked.
• Delegation of Authority: Assign responsibility.
• Principle of Least Privilege: Granting each component only the minimum authority its function requires bounds the blast radius of its compromise or error.
• Traceability: The infrastructure of bidirectional links that lets any element be followed backward to its origin and forward to its uses, turning opaque processes into auditable, queryable histories.
• Untrusted Input Execution: Attacker-influenced input crosses a data-to-control (or authority) boundary and a correctly-operating intermediary executes it with the intermediary's own authority, so the attacker borrows the defender's privilege without ever violating the intermediary's rules.

Also references 23 related abstractions

• Accountability: Responsibility for actions.
• Agency: A system pursues representable goals through actions whose selection is sensitive to its beliefs about its situation, via a goal-representation, world-model, and action-selection coupling.
• Agency Problem: Misaligned incentives.
• Attestation: A verifiable, principal-binding, tamper-evident mark lets a third party confirm who committed to what.
• Authority: The recognized, legitimate right to issue binding decisions within a defined scope, distinct from raw coercive force or mere persuasive influence.
• Authority Handoff: A role with binding authority and attached state transfers between occupants without breaking either.
• Boundary: Defines system limits.
• Capability Separation: Issuance is restricted to a privileged party while verification is open, tied by a forgery-prevention mechanism.
• Conditional Access: A controller couples a desired item with an undesired one, leveraging access asymmetry to force acceptance of both.
• Consent: Voluntary agreement.

▸ Show 13 more

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

CSRF Intent-Authority Binding · domain variant · recognized

Web-security variant that refuses to treat ambient browser credentials as proof that the user intended the request.

• Distinct from parent: The parent covers any privileged intermediary; this variant centers on browser/session ambient authority and request-forgery defenses.
• Use when: A browser, client, session, or user agent automatically carries credentials to a privileged service; An attacker can cause a request to be sent without directly possessing the credential; The server must distinguish authenticated transport from user-intended authorization for this action.
• Typical domains: web security, platform security, api security
• Common mechanisms: csrf token challenge, origin and referer gate, same site cookie policy, user presence step up

Service-Account Deputy Scoping · implementation variant · recognized

Service-to-service variant that prevents a privileged service account from performing actions for a caller outside the caller’s permitted scope.

• Distinct from parent: The parent is cross-domain; this variant emphasizes service accounts, machine identity, tenant boundaries, and on-behalf-of authorization.
• Use when: Automated services, agents, workers, or bots act through accounts more privileged than the requesting user or tenant; The service needs some standing authority to operate, but individual requests should be bounded by the caller’s authority; Audit or policy must preserve who caused the action, not only which service account executed it.
• Typical domains: cloud security, enterprise software, multi tenant platforms, automation agents
• Common mechanisms: on behalf of authorization flow, scoped service account impersonation, policy engine subject binding check, delegation audit log

Object-Capability Authority Mediation · mechanism family variant · candidate

Capability-oriented variant in which possession of an unforgeable, narrowly scoped reference replaces ambient authority at the deputy boundary.

• Distinct from parent: The parent is the general mediation pattern; this variant chooses capability discipline as the main implementation family.
• Use when: A system can redesign authority as explicit unforgeable capabilities rather than global permissions; The deputy should never infer authorization from caller identity alone; Safe execution depends on passing only the authority needed for the specific requested object or action.
• Typical domains: operating system security, distributed systems, api design
• Common mechanisms: object capability reference, signed delegation token, capability revocation list

Near names: Confused Deputy Problem, Confused Deputy Guarding, Requester-Bound Authorization, Originator-Scoped Authority Mediation, Principal-Bound Authorization, CSRF, Cross-Site Request Forgery.