← Back to Repo Pulse
UCP Enhancement Proposal February 4, 2026 · View on GitHub →

UCP Risk & Abuse Signals: Building Trust Infrastructure for Agentic Commerce

A new proposal brings fraud prevention and rate limiting primitives to the Universal Commerce Protocol — essential infrastructure for enterprise adoption.

Author
Ilya Grigorik
Distinguished Engineer & Technical Advisor to CEO, Shopify
Former Google (Analytics, Chrome, Search). Founder & CTO of PostRank (acquired by Google). Author of High Performance Browser Networking (O'Reilly). Former co-chair of W3C Web Performance WG. Speaker at 100+ events on web performance.

Ilya is the second-most active contributor to UCP, responsible for core capabilities including the intent field, multi-parent schema support, cart capability, and two-layer error handling.

Why This Matters

When AI agents start making purchases on behalf of humans, how do merchants know they're not dealing with fraud? How do they rate-limit abusive bots? How do they decide when to require additional verification?

These questions are table stakes for any real commerce system. Without answers, enterprise merchants won't adopt agentic commerce — the risk is too high.

The core insight: There's a difference between completeness (is this checkout structurally valid?) and confidence (can I authorize without friction?). UCP already handles completeness. This proposal adds confidence.

What Changed

1. New signals Object

A transport-agnostic container for environment signals that help merchants assess risk:

{
  "checkout": {
    "id": "chk_123",
    "signals": {
      "buyer_ip": "203.0.113.42",
      "user_agent": "Mozilla/5.0...",
      "device_id": "fp_abc123",
      "ja4": "t13d1516h2_8daaf6152771_b186095e22b6"
    }
  }
}

The spec defines four well-known signals:

Signal Purpose
buyer_ip Geolocation, reputation scoring, rate limiting
device_id Device fingerprinting for fraud detection
user_agent Client identification, bot detection
ja4 TLS fingerprint for advanced bot detection

Additional signals can be defined via extensions and negotiated during the platform-business handshake.

2. New Message Type: hint

A non-blocking message type for expressing what signals affect merchant confidence:

{
  "type": "hint",
  "path": "$.signals.device_id",
  "code": "risk",
  "content": "Device fingerprint may reduce verification friction"
}

Two hint codes are defined:

Unlike error messages that block checkout progression, hint messages are advisory. A checkout can be ready_for_complete while still having hints — the platform can attempt completion, but should expect higher friction (step-up verification, 3DS challenges, etc.) without the requested signals.

The Completeness vs. Confidence Model

Concern Question Mechanism Blocks Status?
Completeness Is checkout structurally valid? error message Yes
Confidence Can I authorize without friction? hint message No

This separation is elegant: validation failures are deterministic (no email = can't complete), while confidence is probabilistic (no device_id = higher probability of step-up, not certainty).

Implications for Platform Developers

If you're building a platform that integrates with UCP (like Copilot Checkout), this proposal means:

  1. Collect signals proactively. When your agent initiates a checkout, gather available environment signals (IP, user-agent, device fingerprints if available) and include them in requests.
  2. Handle hints gracefully. When a merchant returns hints, decide whether to gather the requested signals (if possible) or proceed with higher expected friction.
  3. Expect signal negotiation. Different merchants will request different signals based on their risk models. Your platform should support extensible signal collection.

What's Next