Policy decision point for AI agents

A policy decision point evaluates a trusted subject, concrete action, resource and current context; the enforcing component then has to apply the result to the same request.

01 / The operating case

What changes in a real workflow?

A finance agent asks to release an $8,400 payment. Its runtime knows the task but the payment API knows the payee and account state. A decision without both sets of facts would be incomplete.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision contract

What the executor must check

Normalize the operation, target and amount before asking for a decision. Bind the result to the requesting principal, originating grant, policy version and short validity window. The payment executor must reject a call whose parameters differ from the evaluated request.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

The policy engine returns ALLOW on a broad “payments” resource while the executor releases to a different payee or after the parent grant is revoked.

Evidence to retain

Record the evaluated subject/action/resource/context, policy version, decision ID and reason; correlate with the actual payment attempt and settlement state.

04 / Canonical scope

Why this reference stands alone

The PEP reference owns where the result is enforced. This page owns the PDP input contract, evaluation responsibility and decision freshness.

Implementation review / distinct boundary

A decision request is a contract, not a role lookup.

AuthZEN standardizes communication between a policy enforcement point and a policy decision point using subject, action, resource and context. An agent workflow adds a practical modeling question: which trusted task and delegation facts become subject or context, and which normalized argument values affect the resource? Choose that mapping before writing policy. A PDP should not infer a payee from an agent’s narrative when the payment API can supply the actual payee.

Conceptual PDP input: not a ProofGrid API
subject: verified agent + originating task
action: payment.release
resource: account A / invoice I-42
context: payee, amount, grant, policy version
result: DENY | ALLOW + request digest + expiry
01

Input integrity

Obtain identity and grant references from trusted infrastructure; normalize amount and target after tool selection.

02

Decision binding

Tie the result to request digest, policy version and validity interval; reject execution on a changed digest.

03

PDP availability

State whether an unavailable or partial PDP response denies the write, escalates, or permits a separately scoped read.

Source context: primary specification or guidance ↗. The worked test and mapping are ProofGrid analysis.

Continue with the runtime authorization library for neighboring decision and execution questions.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation