From Policy to Enforcement: PDP, Decision, and PEP in AI Execution
Decision Is Not Execution
English · 本站阅读。方法定义见 AI Execution Boundaries。
1. A Policy Is Not Yet Enforcement
The previous article pinned down one thing: Policy Evaluation is not a binary function. Evaluation must be able to return PROOF, VIOLATION, or an explicit UNDEFINED.
Many teams hear that, put the three results into a table, a function, even a system prompt, and conclude that the runtime execution boundary is already in place.
It is not.
Evaluation answers one question: for this Action that has entered Policy Evaluation, can the policies in force resolve it — including by saying they cannot. It does not yet answer two others:
- Was this result enforced before any write?
- Is the write that actually changes business state the one this Decision covered?
What often looks like a landing is this. Policy lives in a document or a prompt. The model is asked to do its best to comply. The model can propose a refund, a master-data change, a posting. It can also treat the rules as advice. A prompt is guidance, not enforcement.
This article will not prove again why an AI Execution Boundary is needed, and it will not prove the three states again. It pins down the runtime duties that have to be separable: who proposes, who decides, who enforces, who writes.
A Decision that is not enforced is not a boundary.
2. Four Roles. Decision Is Not a Fifth Product
For an Action that will change production state, runtime has to distinguish at least four things. They are architecture roles, not four systems to buy.
The LLM / Agent proposes. It issues an Action request: which order to refund, which record to change, by how much. It is not the PDP, not the PEP, and not the Executor.
The PDP — Policy Decision Point — decides. Given the policies in force and the current business facts, it runs Policy Evaluation on this request. The output is still one of the three Canonical Evaluation States, with an Obligation or fallback handling when needed. The PDP judges. It does not write.
A Decision is the result of that judgment. It is not a new piece of middleware, and it is not another layer in the governance architecture. A Decision is not the loose Allow or Deny of everyday speech. It carries the evaluation state together with any obligations or handling that state requires. Allow, block, and waiting for a human are handling talk. They are not the definition of a Decision.
The PEP — Policy Enforcement Point — enforces. Before the Action reaches the target system, it carries out the Decision: allow, block, or fulfill an obligation first — pause, wait for approval — and then allow. The PEP is not the system of record.
The Executor writes. What actually changes business state is the executor: an API call, a database write, a posting. Even after the Action is allowed through, the write can still fail. That is an execution result, not another round of Policy Evaluation.
The model proposes.
The PDP decides.
The PEP enforces.
The Executor writes.
Decision is a result, not a component.
The same refund can walk this chain without another lecture on the three states. The amount is over the threshold. Policy says a human must approve. The PDP returns PROOF, with an obligation. The PEP pauses, waits for approval, then allows the Action through. Only then does the Executor write. The wait appears on the PEP side. It does not turn HITL into a fourth evaluation state. The previous article already separated the two sources of waiting for a human.
3. Responsibility Is Not Call Order
The first view is not a call sequence. It is a responsibility view: who produces what.
The PDP produces a Decision. The PEP enforces that Decision. The Executor performs the Action.
The second view is the runtime call sequence: the PEP intercepts the request, the PDP evaluates, a Decision returns, the PEP enforces, the Executor writes.
The two views do not conflict. One is responsibility. One is call order. Responsibility and call order are two views of the same runtime, not two architectures.
On site, call order is often mistaken for architecture: the PEP is taken to be an API gateway; the PDP is taken to be a vendor rule engine. They are roles, not products. The same runtime can host both the PDP and the PEP, as long as the duties stay distinct.
Fold judging and writing into one act, and the duties blur again.
4. Allowed Is Not Written
PROOF is not already posted. Being allowed through by the PEP is not a successful write.
Policy Evaluation uses the business facts seen at evaluation time. The write happens later. If the business facts on which this Decision depended no longer hold — someone else changed the order status, available credit was consumed, a freeze flag was just set — do not write on the strength of the old Decision.
The correct failure is to stop. Do not write. The wrong move is: "It was already allowed a moment ago. Write it anyway." Treating a half-write plus a rollback as if the boundary were already in place is not governance either.
This article will not teach how a conditional write is implemented. It pins one principle: a Decision covers this evaluation. The write is a different act. Allowed is not written.
5. Evidence Is Governance Meaning, Not Logging
A runtime that can stand up to later review cannot leave behind only a record of what happened.
A log is a recording mechanism. Evidence is governance meaning: afterwards it must be possible to reconstruct why this Action was allowed, stopped, or handled as it was. Evidence is a governance requirement, not a logging product. It can be stored in logs, or somewhere else. This article does not define it as a table or a store.
A Decision has to be reviewable: which version of Policy, which business facts were seen at the time, why this result. The PEP also has to show whether that result was enforced before the write. Without that meaning, a later review sees only a call that succeeded or failed. It cannot tell whether the rule allowed the action, forbade it, or could not decide and the case was handled in silence.
This article will not list fields. Fields are an implementation detail, and they are not the job of this article.
6. Do Not Let the Model Be the Final PEP
If the rules exist only in a prompt, the model ends up serving as both the decision point and the enforcement point. That stacks the four roles back into one model.
AI can propose an Action. It can also pick which tool to call. It cannot be relied on, by itself, to obey Policy. The execution boundary has to be enforceable by the system — stopped before the write tool is invoked, not hoped for after the model agrees.
An earlier article already said the agent does not have to be replaced. The gate sits in front of the write tool. This article adds one sentence: runtime duties must distinguish the PDP from the PEP, even when the same runtime hosts both. What you cannot have is a black box that both judges and writes, with the duties inseparable.
A prompt is guidance, not enforcement.
AI must not be the final PEP.
7. What This Article Pins Down
This article pins down one thing: from Policy to Enforcement there must be a separable Decision, and there must be enforcement before the write.
The model proposes.
The PDP decides.
The PEP enforces.
The Executor writes.
Decision is a result, not a component. Responsibility and call order are two views of the same runtime. Allowed is not written.
The test is still simple. Take one production Action — already running, or already built but held back from automated writing. Look at the path you already have: which part judges, which part blocks or allows the Action through, which part actually changes business state. If those duties cannot be distinguished, or if the judgment lives only in a prompt, the boundary has not yet landed at runtime.
The next step is not a metrics essay. The next step is still to see this chain on a live system, instead of leaving Policy in a document.
The formal definition of the methodology is on the AI Execution Boundaries method page. The previous articles are When AI Can Act, Beyond Allow and Deny, and the series index on Insights.