Execution Authority for UCP

Published by Decionis under its own reverse-domain namespace, which UCP permits without maintainer approval. Not a UCP membership, endorsement, certification or partnership.

UCP settles how an agent transacts with a business — discovery, cart, checkout, order. It does not settle whether the agent was permitted to commit the transaction it is about to complete.

That gap is load-bearing rather than accidental, because UCP’s own checkout state machine already carries requires_escalation, described in the specification as covering “regulatory requirements, merchant policies, or capabilities the agent does not yet support”. A checkout in that state MUST carry a continue_url. The protocol reserved a place for an authority and left it for someone else to fill.

Three verdicts, three dispositions. The wire tokens are carried through unchanged; a checkout is not the place to invent a fourth vocabulary.

UCP ships dated releases and negotiates them by exact version, so what a merchant can actually read depends on which release they serve. Present in every published release (2026-01-23, 2026-04-08):

• status.requires_escalation
• continue_url
• signals

On the specification’s main branch only, and therefore not usable against a live merchant today:

• actions
• request_constraints

This extension therefore escalates through the status enum, which every release has, and adds an outstanding Action only where the negotiated release carries one.

AP2 mandates and this extension answer different questions, and the specification is what settles which is which. AP2 names exactly two signers:

• The business signs ap2.merchant_authorization.
• The platform or the user's wallet signs ap2.checkout_mandate.
• The PSP verifies payment_mandate and creates nothing.

AP2 names exactly two signers, and no third party may generate or sign a mandate claim. So AP2 proves the terms were not tampered with and that consent was captured — it cannot express whether the principal held the authority to commit those terms. That is a different question, and it travels alongside the mandates rather than inside them.

The escalation case is the one worth reading closely. The agent is not refused; the completion is held, and continue_url is where a human authority resolves it.

https://decionis.com/reference/ucp-execution-authority/examples/escalate.json

Approval is evidence, not a verdict: resolving an escalation re-runs the original request through the protocol with the approval in context, and the new outcome is what decides. A recorded approval never becomes an allow on its own.

UCP's signals object accepts vendor-namespaced keys, so a platform already holding a verdict can pass it to a business without either side negotiating this extension.

{
  "com.decionis.authority_verdict": "ESCALATE",
  "com.decionis.dossier_id": "…",
  "dev.ucp.buyer_ip": "203.0.113.42"
}

• allow.json
• escalate.json
• block.json
• signals.json
• This reference as JSON
• This reference as Markdown
• JSON Schema

Every artifact on this page is generated from one module, and validated against the live specification at ucp.dev before publication.

Why this layer exists · The protocol-agnostic view · Agent authorization reference