Step-Up & Attestation

Blueprint · ← PDP surfaces · Step-up · Audit & replay →

STEP_UP is a PDP verdict, not a model feature. The LLM was never given the limit that triggered step-up. The agentic app owns the approval UX; the PEP re-submits with attestation in context.

THE CLAIM

Step-up completes only when context.approval is set and the PDP returns ALLOW on re-evaluation, not when the user says "yes" in chat.

Flow

1. PEP receives proposal → PDP returns STEP_UP (wire_above_auto_approved)
2. PEP returns step-up-required to agentic app (no downstream call)
3. Supervisor completes four-eyes in your auth system (not the LLM)
4. Agentic app re-submits same proposal with:

Step-up context with approval (JSON)

"context": {
  "amount": 47500,
  "approval": {
    "type": "supervisor_four_eyes",
    "attestation_id": "apr-9f2c",
    "approver_sub": "supervisor-456"
  }
}

5. PDP re-evaluates → ALLOW → PEP forwards to downstream

Worked example: refund $750

Same control pep-step-up-refund as Operating. The model never sees the AUD 500 band.

Step	What happens
1	Priya's app proposes issue_refund $750, purpose duplicate_charge
2	PDP returns STEP_UP refund_above_auto_approved. Ledger not called. Audit v-10058
3	Supervisor four-eyes in the bank's auth system. Not "approved" typed in Slack
4	App re-submits with attestation_id: att-2026-03-11-1842
5	Re-eval ALLOW. Ledger called. New audit id, same proposal

Refund step-up context with approval (JSON)

"context": {
  "amount_aud": 750,
  "purpose": "duplicate_charge",
  "approval": {
    "type": "supervisor_four_eyes",
    "attestation_id": "att-2026-03-11-1842",
    "approver_sub": "supervisor-lee"
  }
}

HR FAQ has no STEP_UP rule. If you need four-eyes on a retrieve, you are on the wrong surface.

What the LLM should not do

• Collect supervisor approval in natural language only
• Proceed after user says "approved" without attestation id
• See why STEP_UP fired (limit values live in PDP)

Failure classes

• Chat-based approval: no attestation id in context
• Stale re-submit: approval expired but PEP forwards anyway
• Wrong approver: attestation not valid for action/resource class
• Skip re-eval: PEP treats chat confirmation as ALLOW

Scenario tests

Scenario	Expected
Over limit, no approval	STEP_UP, downstream not called
Over limit, valid attestation	ALLOW after re-eval
Over limit, forged attestation	DENY
Expired attestation	DENY or STEP_UP

Trace fields

step_up_reason, attestation_id, approver_sub, re_eval_verdict, step_up_duration_ms

See: Policy test scenarios