PGAR Boundary ④: PEP + PDP
Blueprint · ← LLM proposal · PEP + PDP · Downstream →
Boundary ④ is where proposal becomes permission (or explicit DENY / STEP_UP). This is the PGAR choke point.
PEP enforces. PDP decides. Downstream never runs on DENY; never runs on STEP_UP until re-eval returns ALLOW.
PEP ↔ PDP loop
Worked example: three verdicts, one profile
Profile pdp-refund-write-v4. Audit written before the ledger hears anything.
| Proposal | Verdict | Audit | Ledger |
|---|---|---|---|
$80, duplicate_charge | ALLOW | v-10041 | Called |
| $750, no attestation | STEP_UP refund_above_auto_approved | v-10058 | Idle |
$80, goodwill_unmapped | DENY purpose_mismatch | v-10062 | Idle |
DENY on purpose mismatch is the control working. Do not retry around it with a rewritten purpose unless a human changes the SARAC.
DENY is success
When sanctions hit or entitlements fail, DENY with audit is the control working, not an error to retry around.
Co-location vs separation
| Pattern | When |
|---|---|
| PEP sidecar | Same cluster as agentic app; PDP remote |
| Central PEP service | Many apps; one enforcement API |
| PDP as product | OPA, Cedar, custom rules engine |
PEP and PDP are logically separate even if deployed together.
Failure classes
- PEP as pass-through: always forwards
- PDP in prompt: rules only in system message
- Missing DENY path: errors become 500 instead of refusal
- Async fire-and-forget: downstream called before verdict
Trace fields
pep_verdict, pdp_policy_version, reason_code, audit_id, pdp_latency_ms
See: PEP enforcement · PDP policy surfaces · Boundary overview