Deciding apart from enforcing

Why separate the thing that decides whether you may from the thing that stops you?

Picture a guard at a door. He knows the rules and he is standing in the way, so he can both judge you and stop you. Splitting him into two — a judge somewhere else who says yes or no, and a doorkeeper who only obeys — looks like pure loss. You have added a message, a wait, and a second thing that can fail.

So the split must be buying something the single guard cannot supply. What is it that one guard, at one door, is structurally bad at?

Start by adding doors. A system rarely has one entry point; it has an API gateway, a message consumer, a database proxy, a batch job, a mobile client, an admin console. If each of those carries its own copy of the rules, then the rules exist in six dialects, written by six teams, in six languages. Ask yourself the practical question: who can now answer "which staff can approve a refund over ten thousand?" Nobody can, without reading six codebases — and a rule change means six deployments that will not land on the same day.

That already gives most of the case. Pulling the judgement into one place — the policy decision point — makes the policy a single artefact you can version, review, test against synthetic cases, and query. The doorkeeper — the policy enforcement point — shrinks to something almost mechanical: gather the request, ask, obey. The vocabulary is old; RFC 2753 named these roles for network policy in 2000, XACML formalised them for access control, and NIST's zero-trust architecture (SP 800-207) reuses the same shape with a policy engine behind an enforcement point.

Now notice something that the "guard" picture hides. The decision point usually does not hold the facts it needs. Whether you may approve that refund depends on your role, your department, whether your device is managed, whether it is inside working hours, whether the customer is flagged. Those live in a directory, a device registry, a clock, a risk service. So the decision point queries them — the policy information point role — and the answer becomes a function of policy plus attributes, not of code plus attributes. That is the real separation: rules on one side, facts on another, and enforcement on a third.

What does the answer look like? Not simply true or false. XACML defines four outcomes — permit, deny, indeterminate, and not-applicable — and the last two matter, because "the policy did not evaluate" is very different from "the policy said no". Decisions can also carry obligations: permit, but mask these columns; permit, but write this audit record; permit, but only for the next five minutes. The enforcement point is not just a gate, then; it is a gate that must carry out attached instructions faithfully.

And what happens when the decision point is unreachable? This is the question that turns the pattern from a diagram into an engineering problem. Fail closed and an outage in the policy service becomes an outage in everything. Fail open and the same outage silently disables your access control. Most real systems buy their way out with cached decisions and short-lived tokens — which trades availability for staleness, since a revoked permission stays honoured until the cache expires. There is no answer here that is free; there is only the choice of which failure you prefer, made deliberately rather than discovered at three in the morning.

One more thing, and it is the one people get wrong. Separating the two does not move power to the decision point. The enforcement point still holds all of it. A decision is advisory data; if a request can reach the resource by a path with no enforcement point on it, the policy simply did not happen. Which is why enforcement is pushed into places that cannot be routed around — a sidecar proxy every call must traverse, a gateway that owns the only network path, a kernel that owns the syscall.

Three refinements tie this together.

First, "separate" means separate responsibility, not necessarily separate machines. A decision point can be a library compiled into the service, a sidecar on the same host, or a remote service; the pattern is preserved as long as the policy is authored and evaluated as one artefact rather than scattered through business logic. The distributed deployment is the version that costs latency, and it is chosen when you need one policy across many runtimes, not because remoteness is the point.

Second, this is not the same distinction as authentication versus authorization. Authentication establishes who is asking; the decision point consumes that as one attribute among several. A perfectly authenticated caller can still be denied, and much of the interesting policy is about context — device, location, time, sensitivity of the resource — rather than identity alone.

Third, the split makes auditability possible rather than automatic. Because every decision is a request and a response, you can record the attributes, the policy version and the outcome, and later answer "why was this allowed on that Tuesday?" — but a log line saying "permit" without the facts that produced it explains nothing.

• Fail-open versus fail-closed, and how short-lived cached decisions try to have both.
• Policy-as-code languages such as Rego or Cedar, and what makes a policy testable.
• Why revocation is hard once decisions are cached — the same problem that makes signing out everywhere difficult.

Every term the collection defines is gathered in the glossary.