PGAR Blueprint: Five Boundaries, Three Verdicts
This is the implementation guide for Policy-Governed Agent Runtime. The executive piece explains why proposal is not permission. This series explains how to build runtime trust boundaries: token custody, PEP choke points, PDP surfaces, immutable audit, and domain-specific enforcement (tools, retrieval, payments).
A production PGAR keeps credentials out of the LLM, gates every side effect at the PEP, returns only ALLOW / DENY / STEP_UP from the PDP, and logs the verdict before execution.
What you are building
A Policy-Governed Agent Runtime is five connected capabilities:
- Ingress trust: validate token, issue claims, bind every request to a principal
- Agentic orchestration: hold session and token; route proposals; never leak credentials to the model
- Proposal boundary: LLM sees conversation and tool schemas only
- Policy enforcement: PEP asks PDP; verdict before downstream; structural choke point
- Audit replay: immutable verdict chain with policy version; answer examiners without chat logs
The PGAR test
If any of these appear in your LLM payload, you have prompt governance, not PGAR:
- Bearer token or API keys
- Roles, entitlements, or limits
- Policy rule text
- PDP verdict history
The model proposes. The agentic app holds authority. The PEP enforces. The PDP decides.
SARAC: the PDP contract
Every PEP → PDP call uses four fields:
| Field | Carries | Example |
|---|---|---|
| subject | Who (claims from IdP) | roles, emts, limits, tenant |
| action | What tool / operation | initiate_wire, retrieve_documents |
| resource | On what target | beneficiary id, corpus, account |
| context | Conditions at decision time | amount, sanctions_status, approval |
Deep dive: Policy Contracts
Three verdicts only
| Verdict | Meaning | PEP behavior |
|---|---|---|
| ALLOW | Policy permits execution | Forward to downstream; log first |
| DENY | Policy blocks | Stop; no downstream call; log first |
| STEP_UP | Attestation required | Return to agentic app for step-up UX; re-evaluate with updated context |
No fourth option. No "the model felt confident."
See PDP Policy Surfaces and Step-Up & Attestation.
Five boundaries, five playbooks
Each boundary gets its own implementation recipe, failure classes, and trace fields. Start with the boundary overview, then read ①–⑤ in order.
| Boundary | Owns | Playbook |
|---|---|---|
| ① Ingress | Token validation, claims issuance | Ingress |
| ② Agentic app | Session, orchestration, token custody | Agentic app |
| ③ LLM proposal | Tool schemas, no credentials | LLM proposal |
| ④ PEP + PDP | Verdict before side effects | PEP + PDP |
| ⑤ Downstream | Re-auth, execute, return to app | Downstream |
Domain extensions
PGAR is domain-agnostic. Two high-value patterns on this site:
| Domain | Side effect | Playbook |
|---|---|---|
| Tool registry | API calls, workflows | Tool registry · Manifest lifecycle · Worked example |
| RAG retrieval | Context pack assembly | RAG retrieval · Worked example |
Bridge reading: PGAR with RAG
Policy test scenarios (not optional)
Authorization regressions are deterministic. Build a scenario library parallel to eval golden sets:
| Scenario type | Example | Expected |
|---|---|---|
| Representative | Under-limit wire | ALLOW |
| Edge | At-limit amount | STEP_UP or ALLOW per policy |
| Adversarial | Direct downstream call bypassing PEP | DENY / blocked at infra |
| Incident replay | Sanctions hit on validate | DENY, no initiate |
See Policy Test Scenarios and Adversarial Testing.
Eval overlap: Eval Plane Action scores whether enforcement worked; PGAR playbooks explain how to build it.
Release gate matrix
| Change type | Re-run | Offline gate | Online follow-up |
|---|---|---|---|
| New tool in manifest | Tool + PEP scenarios | Schema 100%; manifest violations 0 | Alert on unknown tool proposals |
| Policy version bump | Full PDP regression suite | Verdict match 100% on golden scenarios | Policy version pinned in audit |
| New corpus / index (RAG) | Retrieval + scope scenarios | Scope adversarial 0 leaks | Context pack audit sample |
| Step-up rule change | STEP_UP scenarios | Re-eval path 100% | Step-up completion rate monitor |
| Agent prompt / model swap | Adversarial bypass set | No unauthorized downstream calls | PEP block rate dashboard |
Ownership
| Role | Owns |
|---|---|
| Security / IAM | IdP, token shape, entitlements model |
| AI platform | Agentic app, PEP integration, tool manifest |
| Governance / compliance | PDP policy surfaces, audit retention, examiner packs |
| Domain teams | Downstream re-auth, business rules in PDP context |
| SRE | Verdict log infra, replay tooling, choke-point monitoring |
Implementation sequence
Start at the PGAR Runtime playbooks overview, then:
- Foundation playbooks: SARAC, token custody, PEP/PDP, step-up, audit
- Assurance playbooks: CI scenarios and adversarial bypass tests
- Boundary playbooks ①–⑤ in order
- Tool registry and manifest lifecycle for your agent's tool contract
- Domain playbooks for side-effect patterns (RAG, payments)
Further reading (external)
Third-party PDP/PEP, OAuth, and policy-engine patterns — curated and mapped to this series.
Series index
PGAR Runtime: Playbooks overview
Foundations
- Overview · Policy Contracts · Token & Session Boundary
- PEP Enforcement · PDP Policy Surfaces
- Step-Up & Attestation · Audit & Replay
Assurance
Boundary playbooks
Domain playbooks
Reference