Policy-Engine Subject Binding Check¶
Authorization decision point — instantiates Principal-Bound Authority Mediation
Sends each sensitive request to an externalized policy engine that evaluates it against the originating subject's own authority — not the deputy's — and returns permit, deny, or step-up.
The confused-deputy bug lives in the gap where a service checks its own permissions and forgets to ask whether the originator was entitled to cause the action. Policy-Engine Subject Binding Check closes that gap by moving the decision out of the deputy's own code and into an externalized policy engine that is handed the full triple — the subject who originated the request, the action and resource requested, and the context — and asked one question: may this subject cause this action here, now? Its defining trait is that it binds the decision to the originating subject, evaluating authority against the requester rather than the intermediary, and it returns a structured verdict — permit, deny, or step-up — that the deputy is obligated to honor. It is a decision function, not a credential or a record: it computes the answer, it does not carry identity or store history.
Example¶
A multi-tenant contract-management SaaS lets law firms store client documents. A shared document service can technically read any file in the store — a classic over-powered deputy. Rather than let that service reason about access itself, every read is gated by a call to an externalized policy engine. When associate d.calderon at firm northwind opens contract C-7781, the document service does not decide; it sends the policy engine a query: subject = d.calderon (firm northwind, role associate), action = read, resource = C-7781 (matter M-204).
The engine evaluates policy written as rules: the subject's firm must own the matter, the subject must be assigned to it, and privileged contracts require partner role. Calderon is at northwind, assigned to M-204, and the contract isn't partner-restricted — the engine returns permit, and only then does the service read. A request for a contract belonging to firm stellar, or from an associate not on the matter, returns deny; a partner-restricted document from a non-partner returns step-up. The document service's broad reach never gets to substitute for the associate's actual entitlement, because the decision was bound to the subject and computed outside the deputy.
How it works¶
- Externalize the decision. The deputy delegates authorization to a dedicated policy engine rather than embedding its own checks, so the rule that couples subject to authority lives in one auditable place.
- Pass the subject, not the deputy. The query carries the originating subject's identity, role, and tenant plus the requested action and resource — the engine authorizes the requester, not the calling service.
- Evaluate coupling as policy. Rules encode when the subject's authority covers this action on this resource in this context; the engine computes a verdict against them.
- Return a structured verdict. The answer is permit, deny, or step-up, and the deputy must act on it — the default for missing or contradictory inputs is refusal, not silent allow.
Tuning parameters¶
- Policy expressiveness — coarse role checks versus rich attribute- and context-based rules. Richer policy binds authority more precisely but is harder to write and reason about.
- Decision placement — a local sidecar engine (low latency) versus a central service (consistent policy, single audit point). The trade is latency and availability against uniformity.
- Default verdict — deny-by-default versus permit-with-exceptions. Deny-by-default is the safe stance the archetype demands; permit-by-default invites the exact gaps this mechanism exists to close.
- Step-up threshold — which actions escalate to confirmation rather than a flat allow/deny. Lowering it protects more but adds friction to legitimate work.
- Input completeness enforcement — whether the engine refuses to decide on an incomplete subject/context. Strict enforcement prevents defaulting to the deputy's authority when subject context was stripped upstream.
When it helps, and when it misleads¶
Its strength is that it makes the subject-binding rule explicit, centralized, and testable: authorization becomes policy-as-code you can review, version, and reason about, instead of scattered if statements inside each deputy.[n1] For a fleet of services that all borrow authority, one decision point is far easier to keep honest than many.
Its failure modes are about inputs and trust. The engine can only bind to the subject if the subject actually reaches it — if an upstream hop strips the originating identity, the query silently narrows to whatever context survives, and the decision quietly degrades. The classic misuse is passing the deputy's identity as the subject (because that's what's convenient), which turns a subject-binding check back into the deputy-permission check it was meant to replace. Rich policy can also drift into rules no one fully understands, granting more than intended. The guarding discipline is to fail the decision closed when the originating subject is absent, assert in tests that the subject reaching the engine is the real requester, and keep policies small enough to audit.
How it implements the components¶
principal_authority_coupling_rule— this is its core: the encoded rule that decides when the deputy may spend authority for this subject, evaluated as policy at the decision point.request_intent_scope— the query carries the specific action and resource, so the engine authorizes the intended effect rather than a generic capability.deny_or_step_up_default— the verdict is permit / deny / step-up, and missing or contradictory input defaults to refusal, which the deputy must honor.
It does not narrow or issue the deputy's execution identity — constraining the standing account into a short-lived scoped one is deputy_execution_authority, owned by its nearest twin Scoped Service-Account Impersonation; this mechanism decides, the twin re-credentials.
Related¶
- Instantiates: Principal-Bound Authority Mediation — supplies the externalized decision that couples the originating subject to the action.
- Consumes: Signed Delegation Token or On-Behalf-Of Authorization Flow — the subject identity it evaluates typically arrives via one of these.
- Sibling mechanisms: Scoped Service-Account Impersonation · Signed Delegation Token · On-Behalf-Of Authorization Flow · Object-Capability Reference · Delegation Audit Log · Confused-Deputy Abuse-Case Test · CSRF Token Challenge · Origin and Referer Gate
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Policy-Engine Subject Binding Check operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it sends each sensitive request to an externalized policy engine that evaluates it against the originating subject's own authority — not the deputy's — and returns permit, deny, or step-up.
Independent corroboration: The frozen evidence defines Policy-Engine Subject Binding Check as 'Sends each sensitive request to an externalized policy engine that evaluates it against the originating subject's own authority — not the deputy's — and returns permit, deny, or step-up', so its operative form is Control, Automation & Runtime.
Nearest alternative: Decision, Gate & Allocation — Policy-Engine Subject Binding Check includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: External policy engines and subject-bound authorization are products of computer-security and distributed-systems access control.
Related originating lineages:
- Law & Governance — Law and governance supply delegation limits and the principle that a deputy cannot enlarge the principal's authority.
Review resolution: Both blind reviewers agree that computer science is the primary origin. Reconciliation resolves domain reach disagreement, encyclopedia synthesis disagreement. Formative alternate lineages are retained as law_governance; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Open Policy Agent (OPA) is a widely-used general-purpose policy engine that externalizes authorization decisions as versioned "policy as code," queried with a structured input (subject, action, resource, context) and returning a decision. It is the canonical modern instance of a separate decision point that a deputy consults rather than deciding for itself. ↩