AgentGateFeeReadiness checklist
AgentGateFee/Guides/UCP governance

Protocol boundary briefing · reviewed 04 Sep 2026

UCP Is Not Enough. The Governance Layer Merchants Still Need.

UCP gives agents and commerce systems a common language. A merchant still has to decide who to trust, what authority is sufficient, which policy applies, when a human must review, and what evidence survives the decision.

See the boundary Open the readiness checklist
Interoperability≠Authority≠Policy decision≠Automatic approval

A valid message is evidence for a decision—not the decision itself.

The useful distinction

A common language still needs a local rulebook.

UCP is explicitly designed for interoperability. Its profiles and capability negotiation help a platform discover what a business supports and how the two systems can exchange commerce data.

The specification also contains governance and security mechanisms. But those mechanisms cannot choose every merchant's appetite for loss, exception handling, attribution, approval thresholds, or evidence retention. Those remain business decisions.

Responsibility map

Where protocol conformance ends.

This is a division of responsibility, not a criticism of UCP. The protocol makes the exchange portable; merchant governance makes the action acceptable for a specific organization.

01UCP protocol layerPortable exchange

What can these systems do together?

Discovery and negotiation

A business profile declares supported protocol versions, capabilities, endpoints, payment handlers, and public keys.

Commerce primitives

Standardized checkout, order, fulfillment, discount, and identity-linking capabilities reduce one-off integrations.

Lifecycle exchange

Defined request and response shapes coordinate checkout sessions and post-purchase order updates.

Security inputs

Authentication, signatures, payment handlers, OAuth, and optional mandate extensions can carry verifiable context.

Read the UCP specification
02Merchant control layerLocal decision

Should this action proceed here and now?

Trust policy

Which principals, issuers, agents, credentials, and request paths are acceptable for this merchant?

Authority policy

Does the available evidence authorize this exact action, value, product, market, and moment?

Decision policy

Should the request be allowed, reviewed, challenged, or rejected under current business rules?

Evidence policy

What normalized input, policy version, reason codes, and outcome must survive for investigation and audit?

See the AgentGateFee product boundary
Important:

UCP or AP2 evidence may answer part of these questions. Merchant policy still decides whether that evidence is sufficient, fresh, internally consistent, and appropriate for the requested action.

The decision model

Five questions before an agent action.

Treat every answer as evidence with provenance and freshness—not as a permanent label attached to an agent.

01Identity evidence

Who is acting?

Bind the request to a principal, agent, issuer, and authenticated request source—not a display name alone.

02Authority evidence

What was delegated?

Compare the requested action with scope, amount, product, geography, expiry, and any buyer-approved mandate.

03Policy outcome

Does the request fit policy?

Evaluate merchant rules against price, inventory, attribution, risk, velocity, and the current commerce state.

04Review condition

When must a human review?

Escalate stale, incomplete, conflicting, exceptional, or high-impact evidence through an explicit review rule.

05Decision evidence

What proof remains?

Keep a deterministic record of the evaluated input, policy revision, reason codes, and resulting decision.

From signal to record

Keep protocols at the edge. Keep policy stable.

AgentGateFee's current OBSERVE path starts with a copy of an Agent Event. A customer or adapter maps the available protocol context into a stable evidence shape; the original commerce request remains unchanged.

  1. 01Integration edgeProtocol and provider evidence

    UCP, AP2, A2A, MCP, or another source remains an integration boundary.

  2. 02Normalized coreAgent Event

    Identity, authority, resource, commerce, attribution, and integrity context.

  3. 03Shadow ModePolicy evaluation

    The same policy version and normalized evidence produce the same outcome.

  4. 04Evidence outputDecision Receipt

    Outcome, reason codes, provenance, and an explanation remain inspectable.

Available nowOBSERVE

Asynchronous evaluation. Customer request unchanged.

Gated next stageDECIDE

Synchronous decision. Customer application still controls the action.

Later, opt-inENFORCE

Replaceable adapter. Explicit activation only.

Protocol names describe adapter boundaries. They do not claim bundled provider integrations.

Primary-source ledger

The boundary is grounded in the specifications.

Protocol capabilities are described from official UCP and Google documentation. Merchant-control statements are AgentGateFee's architectural interpretation, not additional UCP requirements.

  1. 01
    UCP — Official specification overview

    Protocol discovery, business-profile governance, version selection, and capability negotiation.

  2. 02
    Google — UCP implementation overview

    Merchant Center, payment setup, profile publication, checkout APIs, identity choice, and order synchronization.

  3. 03
    Google — Prepare your UCP profile

    Public declaration of capabilities, versions, endpoints, payment handlers, and signing keys.

  4. 04
    Google — Agent Payments Protocol announcement

    Authorization, authenticity, accountability, and mandate-based evidence for agent-led payments.

Boundary questions

What “not enough” actually means.

Does UCP include governance and security mechanisms?

Yes. The UCP specification covers business-profile governance and capability negotiation, and its ecosystem includes authentication, signatures, identity linking, payment handlers, and optional mandate-related extensions. The separate merchant layer described here is the organization-specific policy that decides how those signals are interpreted for a particular action.

Why is protocol conformance not the same as authorization?

A conforming request can be structurally valid while still exceeding a buyer mandate, merchant limit, geographic rule, inventory state, or risk threshold. Conformance validates the exchange; authorization requires a decision over the evidence and current policy.

Does AgentGateFee replace UCP, AP2, a PSP, or checkout?

No. AgentGateFee is designed as a protocol-neutral governance layer. Protocol and provider data stay at the integration edge while a normalized Agent Event supports policy evaluation and a Decision Receipt. It does not become the merchant of record, custody funds, or rebuild the checkout rail.

What is available from AgentGateFee now?

The current customer-facing stage is OBSERVE: submit a copy of an Agent Event, evaluate policy asynchronously in Shadow Mode, and inspect the resulting Decision Receipt. Synchronous DECIDE is a gated next stage, and ENFORCE is later and opt-in.

Continue the UCP field guide

Evidence first. Readiness next. Governance throughout.

Research · 01Who is actually live on UCP?

Separate production evidence from platforms, pilots, and announcements.

Open adoption tracker Guide · 02Is your merchant stack ready?

Assess implementation requirements and merchant-owned controls separately.

Open readiness checklist

Current customer-facing stage

Observe the decision before you automate the consequence.

Send a copy of an Agent Event, evaluate policy in Shadow Mode, and inspect the Decision Receipt while your existing request path stays in control.
Create Developer account