PGAR Boundary ②: Agentic App

Blueprint · ← Ingress · Agentic app · LLM proposal →

The agentic app is the orchestrator. It holds the token, talks to the LLM, forwards proposals to the PEP, receives downstream results, initiates validation, and only then sends validated context back to the model.

THE CLAIM

The agentic app is the only component that holds both the conversation and the credentials. It never sends the latter to the LLM.

Responsibilities

Owns	Does not own
Session state, token custody	PDP rule authoring
LLM call adapter (strip auth)	Downstream business logic
Route proposals → PEP	Generating verdicts
Step-up UX handoff	Vector search ranking
Initiate validation after retrieval	Policy in system prompt

Request loop

1. Receive user message + session from ingress
2. Load or pin tool manifest (manifest_version on session)
3. Call LLM with messages + tool schemas only
4. On tool proposal → validate against manifest → PEP with token + claims
5. On ALLOW result → receive downstream/context pack
6. Run validation gate (app-initiated)
7. Call LLM for synthesis with validated context only
8. Return response to user

Failure classes

• Direct downstream: app calls payment hub or vector DB without PEP
• Token forwarded to LLM: PGAR test failure
• Validation skipped: raw retrieval pasted into second LLM call
• Stateless chaos: multi-step flow loses approval context

Trace fields

session_id, orchestration_step, proposal_count, pep_calls, validation_passed

See: PEP enforcement · Manifest lifecycle · Domain: RAG retrieval · Boundary overview