PGAR Boundary ③: LLM Proposal
Blueprint · ← Agentic app · LLM proposal · PEP + PDP →
The LLM operates on conversation and tool schemas. It proposes tool calls. It does not permit them.
THE CLAIM
The LLM boundary is proposal-only. Authority, tokens, and policy text stop at the agentic app adapter.
Appropriate LLM work
| Task | Why prediction is fine |
|---|---|
| Parse user intent | Language understanding |
| Select tool sequence | Planning |
| Draft user-facing explanation | Fluency |
Propose retrieve_documents args | Search strategy |
Inappropriate LLM work (belongs in PDP)
| Task | Owner |
|---|---|
| "Is this wire allowed?" | PDP |
| "May this principal see corpus X?" | PDP |
| "Does amount exceed limit?" | PDP |
| "Record approval for audit" | PEP |
Worked example: what the refund model may see
| In the messages | Not in the messages |
|---|---|
| User text: "duplicate charge on acct-4412" | Bearer token, emts, fraud band AUD 500 |
Schema for issue_refund (account_id, amount_aud, purpose) | Policy text "never refund above 500" |
| Prior tool results after the app sanitized them | Ledger credentials |
The model may propose $750. That is planning. Permission is ④. If $750 posts because the framework auto-ran the tool, ③ leaked into ⑤.
HR FAQ: no issue_refund in the schema. A proposal to search payroll is rejected as unknown or sent to PEP and DENY corpus_forbidden.
Tool manifest
Only tools in the manifest appear in the LLM schema. Unknown proposals are rejected by the agentic app before PEP.
See Manifest registry.
Failure classes
- Policy in system prompt: limits as instructions instead of PDP
- Credential injection: env vars visible to model runtime
- Unbounded tools: dynamic schema includes admin operations
- Proposal = execution: framework auto-runs tools without PEP
Trace fields
model_id, tools_in_schema, proposal, proposal_in_manifest, llm_payload_hash