Runtime Playbooks
Governance · Runtime overview · Foundation →
Implementation guides for Policy-Governed Agent Runtime. The Runtime blueprint is the reference design. Estate how-to: Operating. These playbooks are the how for the request path: contracts, enforcement, boundaries, and tests.
RAG, tool manifests, and memory are other G.A.I.N subjects. PGAR gates their side effects. Their how-to lives in RAG, Agents: Manifests, and Memory.
The LLM proposes. The PEP enforces. The PDP decides. Every side effect gates at the PEP before downstream runs. These playbooks show you how to build that path.
Three playbook groups
| Group | Overview | What you build |
|---|---|---|
| Foundation | Open → | SARAC contracts, token custody, PEP/PDP loop, step-up, audit replay |
| Assurance | Policy test scenarios | Golden authorization cases in CI, adversarial bypass tests |
| Boundary | Open → | Five trust boundaries from ingress through downstream |
Plus Further reading (external) for third-party PDP/PEP and OAuth patterns mapped to this series.
Recommended path
- Foundation (6 playbooks): policy contracts → token & session → PEP → PDP → step-up → audit
- Assurance (2 playbooks): scenario library and adversarial bypass set (start in parallel once PEP exists)
- Boundary (5 playbooks + overview): ingress, agentic app, LLM proposal, PEP + PDP, downstream
Then call other G.A.I.N series for the thing being gated: Manifests, RAG, Memory.
Eval overlap: Action plane · Tool plane.
Worked example: bank refund agent
Same ids as Operating: uc-refund-agent, profile pdp-refund-write-v4, control pep-step-up-refund. Operating approved the row. This series is one request.
| Group | What happens on issue_refund |
|---|---|
| Foundation | SARAC for $80 / $750 / purpose-mismatch; token stays in the app; PEP asks PDP; STEP_UP above AUD 500; audit written before any ledger call |
| Assurance | Suite pol-refund-write-v4: ALLOW $80, STEP_UP $750, DENY purpose_mismatch, plus bypass fixtures |
| Boundary | Ingress binds Priya's staff token → app holds it → model proposes issue_refund → PEP/PDP verdict → payment hub only on ALLOW |
The evidence pack ev-refund-agent-2026-03 is those three verdict samples plus the policy pin. If Runtime cannot produce them, the pack is a slide.
A staff HR FAQ (uc-hr-policy-faq, pdp-hr-faq-read-v1) is the same five boundaries with no write tool and no STEP_UP. DENY is out-of-corpus retrieval. Do not copy the $750 fixture onto that path.
What "not done" looks like
| Symptom | Missing playbook |
|---|---|
| Model told "do not refund above $500" in the system prompt | PDP surfaces |
| App calls the payment hub with its own API key | PEP enforcement |
| Bearer token in the LLM messages | Token & session |
| User types "approved" in chat; $750 posts | Step-up |
| Examiner needs the Slack thread to reconstruct the refund | Audit & replay |
Inventory live, no CI fixture for issue_refund | Policy test scenarios |
All playbooks at a glance
Foundation
| Playbook | One-line purpose |
|---|---|
| Policy contracts | SARAC payload shapes the PDP evaluates |
| Token & session | Credentials stay out of the LLM boundary |
| PEP enforcement | Receive, ask PDP, audit, act on every proposal |
| PDP surfaces | ALLOW, DENY, STEP_UP rule authoring |
| Step-up & attestation | Re-eval after human approval |
| Audit & replay | Immutable verdict chain for examiners |
Assurance
| Playbook | One-line purpose |
|---|---|
| Policy test scenarios | Representative, edge, and incident replay cases in CI |
| Adversarial testing | Direct downstream bypass, injection, shadow tools |
Boundary
| # | Playbook | One-line purpose |
|---|---|---|
| ① | Ingress | Token validation and claims at the edge |
| ② | Agentic app | Orchestration, token custody, validation gates |
| ③ | LLM proposal | Tool schemas only; proposal not permission |
| ④ | PEP + PDP | Verdict before any side effect |
| ⑤ | Downstream | Re-auth, execute, return to app |
See Boundary overview for request flow and multi-agent patterns.
Cross-calls (not nesting)
| Side effect | G.A.I.N subject | Playbook |
|---|---|---|
| Tool execute | Agents | Manifest registry |
| Corpus retrieve | RAG | RAG retrieval |
| Prefs / episodes | Agents | Memory |
PGAR still evaluates SARAC on those actions. The store and contract live in the subject series.
Who should read what
| Role | Start with | Then |
|---|---|---|
| Security / IAM | Token & session, Ingress | PDP surfaces, Audit & replay |
| AI platform | PEP enforcement, Agentic app | MCP, RAG |
| Governance / compliance | Policy contracts, Audit & replay | Policy test scenarios · Operating |