When Bots Become Customers: UCP and the Shift to Identity-Based Detection

TL;DR: Google’s Universal Commerce Protocol (UCP) deprecates behavioral bot detection (mouse tracking, CAPTCHAs) in favor of cryptographic identity verification. The protocol includes strong security features - TAP for agent authentication, requires_escalation for human-in-the-loop, provable consent for payments. But adoption takes time. During the transition, merchants who implement UCP without its full security stack create a window of exposure.

The Uncomfortable Irony

On January 11, 2026, Google launched the Universal Commerce Protocol - an open standard co-developed with Shopify, PayPal, Visa, Walmart, and 20+ other major players.

Here’s what nobody is saying out loud: the companies that spent the last decade building bot detection are now mandating that merchants expose machine-readable checkout APIs to automated systems.

Shopify alone processed $236 billion in GMV in 2023. They’ve invested heavily in bot protection. Now they’re co-authoring a spec that requires merchants to publish discoverable API endpoints at /.well-known/ucp - the exact attack surface security teams have spent years trying to obscure.

This isn’t a criticism of UCP’s design. The protocol is technically elegant: standardized REST endpoints, OAuth 2.0 identity linking, transport-agnostic architecture. The problem is that legitimate AI agent traffic is now indistinguishable from sophisticated attacks at the protocol level.

We’ve been here before. And we lost every time.

A Pattern We Should Recognize

This is the third major paradigm shift that’s broken bot detection in 15 years:

2010-2015: Mobile APIs When native mobile apps became mandatory, companies had to expose REST APIs that browsers never needed. Scrapers immediately pivoted from HTML parsing to API consumption. Detection moved from DOM fingerprinting to API behavioral analysis. Many never adapted.

2015-2020: Single-Page Applications SPAs moved rendering client-side, which meant business logic lived in JavaScript bundles anyone could read. Headless browsers became trivial to operate. Client-side fingerprinting became an arms race that defenders were always losing.

2020-2024: AI-Powered Automation Vision-based agents (Operator, Computer Use, browser-use) learned to interact with UIs visually. They run real browsers with real fingerprints. Behavioral detection was the last line - and it started failing against AI-generated mouse movements and scroll patterns.

2026: Legitimized Automation UCP doesn’t just make automation easier - it makes automation expected. Merchants who block AI agents will lose the AI commerce channel entirely. Google, OpenAI, and Anthropic are all building shopping agents. The incentive structure has flipped.

Each transition caught the industry flat-footed. Each time, the response was “we’ll adapt.” Each time, the adaptation took 3-5 years while attackers had free rein.

We’re at the start of transition four.

How UCP Works: The Technical Foundation

Business Profile Discovery

Every UCP-compliant merchant must publish a machine-readable profile:

GET https://merchant.example.com/.well-known/ucp

Response:

{
  "ucp": {
    "version": "2026-01-11",
    "services": {
      "dev.ucp.shopping": {
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/overview",
        "rest": {
          "schema": "https://ucp.dev/services/shopping/rest.openapi.json",
          "endpoint": "https://merchant.example.com/api/v2"
        }
      }
    }
  }
}

This profile advertises:

• Supported capabilities (checkout, identity linking, order management)
• API endpoints and OpenAPI schemas
• Payment handlers and configuration
• Public keys for signature verification

Security implication: Any agent - legitimate or malicious - can discover your entire checkout API surface programmatically. There’s no obscurity layer.

The Three Core Checkout Endpoints

UCP’s native checkout requires merchants to implement three REST endpoints:

1. Session Creation

POST /checkout-sessions HTTP/1.1
UCP-Agent: profile="https://platform.example/profile"
Content-Type: application/json

{
  "line_items": [
    {
      "item": {
        "id": "item_123",
        "title": "Red T-Shirt",
        "price": 2500
      },
      "id": "li_1",
      "quantity": 2
    }
  ]
}

Response:

{
  "ucp": {
    "version": "2026-01-11",
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11"
      }
    ]
  },
  "id": "chk_1234567890",
  "status": "incomplete",
  "messages": [
    {
      "type": "error",
      "code": "missing",
      "path": "$.buyer.email",
      "content": "Buyer email is required",
      "severity": "recoverable"
    }
  ],
  "currency": "USD",
  "line_items": [...],
  "totals": [
    { "type": "subtotal", "amount": 5000 },
    { "type": "tax", "amount": 400 },
    { "type": "total", "amount": 5400 }
  ]
}

2. Session Updates (PUT replaces entire session)

PUT /checkout-sessions/{id} HTTP/1.1
UCP-Agent: profile="https://platform.example/profile"
Content-Type: application/json

{
  "id": "chk_123456789",
  "buyer": {
    "email": "[email protected]",
    "first_name": "Jane",
    "last_name": "Doe"
  },
  "line_items": [...],
  "fulfillment": {
    "methods": [
      {
        "type": "shipping",
        "destinations": [
          {
            "street_address": "123 Main St",
            "address_locality": "Springfield",
            "address_region": "IL",
            "postal_code": "62701",
            "address_country": "US"
          }
        ]
      }
    ]
  }
}

3. Session Completion

POST /checkout-sessions/{id}/complete HTTP/1.1
Content-Type: application/json

{
  "payment_data": {
    "id": "pm_1234567890abc",
    "handler_id": "8c9202bd-63cc-4241-8d24-d57ce69ea31c",
    "type": "card",
    "brand": "visa",
    "last_digits": "4242",
    "billing_address": {...},
    "credential": {
      "type": "PAYMENT_GATEWAY",
      "token": "{\"signature\":\"...\",\"protocolVersion\":\"ECv2\"...}"
    }
  },
  "risk_signals": { ... }
}

OAuth 2.0 Identity Linking

For account-linked checkout, merchants must host OAuth metadata:

GET https://merchant.example.com/.well-known/oauth-authorization-server

{
  "issuer": "https://merchant.example.com",
  "authorization_endpoint": "https://merchant.example.com/oauth2/authorize",
  "token_endpoint": "https://merchant.example.com/oauth2/token",
  "scopes_supported": ["ucp:scopes:checkout_session"],
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"]
}

Embedded Checkout (iframe-based)

For complex flows, UCP supports embedded checkout via iframe with JSON-RPC 2.0:

// Platform loads merchant's continue_url with query parameters
// Communication via postMessage
communicationChannel.postMessage(JSON.stringify({
  "jsonrpc": "2.0",
  "id": "req_token_1",
  "method": "ec.payment.credential_request",
  "params": {
    "checkout": { /* current checkout state */ }
  }
}));

Threat Model Clarification

Before diving into attack scenarios, let’s be precise about what we’re claiming and what we’re not.

What UCP Gets Right

UCP and its ecosystem include legitimate security features:

• OAuth 2.0 identity linking - Agents can authenticate on behalf of users
• AP2 tokenized payments - Payment credentials are cryptographically secured with provable consent (“Every authorization is backed by cryptographic proof of user consent” - Google Developers Blog)
• Trusted Agent Protocol (TAP) - Visa and Akamai announced (October 2025) a cryptographic framework for merchants to distinguish legitimate agents from malicious bots using edge-based behavioral intelligence
• requires_escalation state - UCP’s Embedded Checkout Protocol forces handoff to merchant-controlled UI when transactions require human verification. Critically, this is the default behavior when trust cannot be established - if a merchant’s backend receives a UCP request it cannot verify (no valid TAP credential or identity token), the protocol instructs returning status: "requires_escalation", forcing the agent to hand off via continue_url. The protocol defaults to human-in-the-loop, not open access
• Merchant of Record retention - Merchants control the transaction relationship
• SKU-level opt-in - Merchants can exclude products via native_commerce attribute

These aren’t cosmetic. Google’s implementation (Merchant Center, waitlist, approval) adds real gatekeeping on top of the protocol. TAP integration with Akamai’s edge intelligence provides behavioral analysis. The requires_escalation mechanism ensures merchants retain control for high-stakes transactions.

The Protocol vs. Implementation Gap

Here’s the distinction that matters:

Google’s UCP implementation is gated. You need a Merchant Center account, you go through an approval process, and Google’s agents (Gemini) are verified entities.

UCP as an open protocol is implementable by anyone. The spec is public. The API schemas are published. The standard is explicitly “vendor agnostic, capable of powering agentic commerce on any surface or platform.”

A malicious actor can:

1. Read the UCP specification
2. Implement a protocol-compliant agent
3. Call merchant UCP endpoints directly
4. Self-report any UCP-Agent profile URI they want

The UCP-Agent header is self-asserted. There’s no cryptographic proof that profile="https://google.com/agent" actually came from Google unless the merchant implements additional verification - which most won’t.

What We’re Actually Claiming

We’re not claiming UCP is inherently insecure. The protocol has reasonable security provisions.

We’re claiming:

1. Merchants who implement UCP without API-layer security are exposed. Most will expose /.well-known/ucp, implement the three checkout endpoints, and call it done.

2. Existing fraud tools aren’t tuned for UCP patterns. Sift, Signifyd, Forter were built for browser-based flows with rich client-side signals. API-only sessions are a blind spot.

3. The security features are opt-in, not enforced. Agent verification, behavioral analysis, velocity limits - merchants have to build these. The protocol doesn’t mandate them.

4. AP2 secures payments, not access patterns. Tokenized credentials prevent payment fraud at completion. They don’t prevent reconnaissance, inventory manipulation, or card testing that happens before completion.

The honest framing: UCP works as intended when fully and correctly implemented. The threat is what happens when it’s not - which will be most implementations.

Identity ≠ Intent: The Core Distinction

TAP verifies who. It doesn’t analyze what or why.

This is the most important takeaway for merchants. TAP is a “passport” for the agent - it proves the agent is who it claims to be. But it doesn’t monitor for malicious patterns like catalog enumeration or “low and slow” scraping.

The nuance: TAP allows an agent to “declare” its intent (e.g., “I am here to browse” vs. “I am here to buy”). But it relies on the agent to be honest. A malicious actor using a verified agent ID could declare “buying intent” while actually harvesting pricing data for competitive intelligence.

A verified, legitimate agent can still:

• Enumerate your catalog - Create sessions for every SKU to extract pricing
• Hold your inventory - 500 verified Gemini sessions during a limited drop = effective DoS
• Test stolen cards - Identity verification doesn’t prevent payment fraud attempts
• Harvest decline codes - Structured error responses enable card classification
• Query shipping rates at scale - 41,000 zip codes × 50,000 SKUs = 2 billion data points

The inventory manipulation risk is particularly acute. During limited-edition “hype” drops, if thousands of verified agents simultaneously “add to cart” and hold inventory, they can effectively DoS the inventory without ever completing a purchase. The requires_escalation state helps here - it forces suspicious high-volume agent traffic back to a human-in-the-loop UI - but only if merchants configure their thresholds correctly.

Provable consent secures the payment, not the session. The Signed Mandate in AP2 tells the merchant “I (the human) gave this agent permission to spend up to $X at this store.” It’s cryptographic proof of user authorization. But reconnaissance and inventory manipulation happen before the payment step. Provable consent doesn’t prevent the 10,000 sessions that never reach checkout completion.

The Threat Model

What Makes UCP Access Unique

The core problem: A malicious actor using UCP endpoints correctly is protocol-identical to a legitimate AI shopping agent. There’s no packet you can inspect that distinguishes “Gemini helping a user buy shoes” from “competitor scraping your entire catalog.”

Attack Scenario 1: Price and Inventory Reconnaissance

Legitimate use: Gemini creates a checkout session to show accurate pricing and shipping options.

Malicious use: Competitor discovers /.well-known/ucp, then:

# Enumerate entire catalog via checkout sessions
for product_id in product_catalog:
    session = create_checkout_session({
        "line_items": [{"item": {"id": product_id}, "quantity": 1}]
    })

    # Extract real-time pricing
    pricing_data[product_id] = {
        "price": session["line_items"][0]["item"]["price"],
        "tax": next(t for t in session["totals"] if t["type"] == "tax"),
        "available": session["status"] != "unavailable"
    }

    # Test shipping rates across regions
    for zipcode in target_zipcodes:
        updated = update_checkout_session(session["id"], {
            "fulfillment": {
                "methods": [{
                    "type": "shipping",
                    "destinations": [{"postal_code": zipcode, "address_country": "US"}]
                }]
            }
        })
        shipping_rates[product_id][zipcode] = extract_shipping_cost(updated)

    # Never complete - just harvest data

Detection challenge: This is valid UCP usage. The API is designed to return pricing, tax, and shipping before completion. The only signal is behavioral: sessions that never complete.

Scale of exposure: A mid-size retailer with 50,000 SKUs and shipping to 41,000 US zip codes now has 2 billion potential pricing data points accessible via API. Previously, scraping this required rendering 50,000 pages and was easily rate-limited. Now it’s three API calls per SKU.

Attack Scenario 2: Inventory Manipulation

Legitimate use: User adds items to cart while deciding; checkout session holds tentative inventory.

Malicious use: Create hundreds of sessions to lock inventory during a limited drop:

# Hold inventory across your entire limited-edition release
sessions = []
for _ in range(500):
    session = create_checkout_session({
        "line_items": [
            {"item": {"id": "limited_sneaker_001"}, "quantity": 1}
        ]
    })
    sessions.append(session["id"])

# Sessions may hold inventory for minutes to hours
# Legitimate customers see "out of stock"
# Attacker releases sessions selectively or lets them expire

Detection challenge: Each session looks like a normal checkout attempt. The attack is only visible in aggregate - and by then the drop is over.

Historical parallel: This is the same attack pattern that plagues concert ticket sales, but now with a standardized, documented API that merchants are required to expose.

Attack Scenario 3: Vision-Based AI Agents

OpenAI’s Operator, Anthropic’s Computer Use, and open-source frameworks like browser-use represent a parallel threat: they render real browsers and interact visually.

How they work:

1. Launch headless or headed Chrome
2. Navigate to product pages normally
3. AI “sees” the rendered page via screenshot
4. Generates mouse movements, clicks, form fills
5. Can solve CAPTCHAs (or delegate to human solving services)
6. Completes checkout via UCP embedded flow or traditional forms

What your detection sees:

The agent may be running on the user’s actual device. Your fingerprinting sees a legitimate Chrome instance because it is a legitimate Chrome instance.

Attack Scenario 4: Agent Impersonation

UCP agents self-identify via header:

UCP-Agent: profile="https://platform.example/profile"

A malicious actor could:

1. Host a fake agent profile mimicking Google’s Gemini
2. Use that profile to interact with merchant APIs
3. Claim legitimacy based on profile structure

The protocol doesn’t enforce origin validation. Verifying that a profile URI belongs to the claimed platform requires out-of-band verification that most implementations won’t do.

The Counter-Arguments (And Why They’re Insufficient)

“But there’s OAuth 2.0”

OAuth authenticates that an agent has user permission to act. It doesn’t authenticate that the agent is who it claims to be, and it doesn’t prevent an authenticated agent from behaving maliciously.

A user could unknowingly authorize a malicious agent. Or a legitimate agent’s credentials could be compromised. OAuth solves identity, not intent.

”Rate limiting will handle it”

UCP is designed for AI agents that legitimately need to make rapid API calls - checking shipping options, applying discount codes, comparing variants. Aggressive rate limiting breaks the legitimate use case.

Distributed attacks trivially bypass IP-based limits. And the whole point of UCP is to enable automated checkout at scale. You can’t rate-limit your way out of this.

”We’ll just allowlist known agents”

This assumes:

• You can exhaustively enumerate all legitimate agents (you can’t - anyone can build one)
• Agent credentials can’t be stolen or spoofed
• The allowlist is maintained perfectly (it won’t be)
• Google/OpenAI/Anthropic will cooperate on verification (unclear)

Allowlisting also creates a two-tier system where established players get access and newcomers are locked out - the exact opposite of the “open commerce” goal.

”Behavioral detection will catch them”

Behavioral detection is the right direction, but it requires fundamentally new signals. Your current behavioral models are trained on browser-based patterns. API-only sessions have no scroll patterns, no mouse movements, no viewport events.

Vision agents do generate behavioral signals - but they’re AI-generated behaviors trained to look human. The detector vs. generator dynamic is adversarial ML, and attackers iterate faster.

What Detection Must Evolve Toward

The old question: “Is this a bot?” The new question: “What is this session trying to accomplish?“

1. Intent Classification at Session Level

Signals for malicious intent:

• Session creation without completion (high abandonment)
• Sequential product enumeration patterns
• Shipping rate queries across implausible geographic spread
• Fulfillment exploration without corresponding buyer information
• Session creation velocity inconsistent with natural shopping

Implementation approach:

Session Intent Score = f(
    completion_rate,
    time_to_buyer_info,
    geographic_consistency,
    product_access_pattern,
    fulfillment_exploration_breadth,
    discount_code_testing_frequency
)

2. Agent Reputation and Verification

Build verification on top of UCP profiles:

Verified agents:

• Validate via DNS TXT records
• Certificate transparency logs
• Published profile registries from Google/Shopify

Suspicious indicators:

• Profiles on free hosting
• Newly created with no history
• Similar URIs to known platforms (typosquatting)

3. API-Layer Honeypots

Traditional honeypots catch scrapers visiting hidden links. UCP needs API honeypots:

Honeypot products:

• Valid IDs that don’t exist in your real catalog
• Discoverable only through API enumeration
• Any checkout session containing them indicates reconnaissance

Honeypot pricing:

• Slightly incorrect prices on specific SKUs
• Only visible to API consumers who don’t validate against displayed prices

Honeypot endpoints:

• Undocumented paths following UCP naming conventions
• Any access indicates automated fuzzing

4. Server-Side Fingerprinting

When client-side signals are unavailable, server-side becomes critical:

JA4+ Fingerprinting:

# Legitimate Chrome TLS fingerprint
t13d1516h2_8daaf6152771_e5627efa2ab1

# Python requests library
t13d1715h2_5b57614c22b0_3d5424a68c6d

# Go net/http
t13d1715h2_f87e51e62c45_8daaf6152771

An agent claiming to be browser-based but presenting a Python TLS fingerprint is lying.

5. Cross-Session Behavioral Analysis

Individual requests look legitimate; patterns reveal intent:

agent_behavior = {
    "profile_uri": "https://agent.example/profile",
    "sessions_24h": 847,
    "completion_rate": 0.02,  # 2% = suspicious
    "unique_products_accessed": 12453,
    "shipping_zipcodes_queried": 1847,
    "avg_session_duration": 3.2,  # seconds = too fast
    "product_access_entropy": 0.12  # low = sequential
}

6. Completion Funnel Analysis

Legitimate shopping agents complete purchases. Reconnaissance doesn’t.

Track per-agent:

• Session creation -> buyer info -> fulfillment -> payment -> completion
• Drop-off points and timing
• Consistency of patterns (too-perfect = automation)

Implementation Architecture

                    +-------------------+
                    |   UCP Request     |
                    +---------+---------+
                              |
                    +---------v---------+
                    |  JA4+ Extract     |
                    |  + Header Parse   |
                    +---------+---------+
                              |
              +---------------+---------------+
              |               |               |
     +--------v--------+ +----v----+ +--------v--------+
     | Agent Profile   | |Honeypot | |  Session        |
     | Verification    | | Check   | |  Correlation    |
     +--------+--------+ +----+----+ +--------+--------+
              |               |               |
              +---------------+---------------+
                              |
                    +---------v---------+
                    | Behavioral Score  |
                    |  (Real-time)      |
                    +---------+---------+
                              |
                    +---------v---------+
                    | Decision Engine   |
                    | Allow/Challenge   |
                    |   /Block/Log      |
                    +-------------------+

Data Model

CREATE TABLE agent_profiles (
    profile_uri TEXT PRIMARY KEY,
    first_seen TIMESTAMP,
    verified BOOLEAN,
    verification_method TEXT,
    reputation_score FLOAT,
    total_sessions BIGINT,
    completion_rate FLOAT
);

CREATE TABLE checkout_sessions (
    session_id TEXT PRIMARY KEY,
    agent_profile_uri TEXT,
    created_at TIMESTAMP,
    completed_at TIMESTAMP,
    status TEXT,
    products JSONB,
    fulfillment_queries INTEGER,
    ja4_fingerprint TEXT,
    ip_address INET,
    risk_score FLOAT
);

CREATE TABLE honeypot_events (
    id SERIAL PRIMARY KEY,
    timestamp TIMESTAMP,
    agent_profile_uri TEXT,
    honeypot_type TEXT,  -- 'product', 'pricing', 'endpoint'
    honeypot_id TEXT,
    request_details JSONB
);

Detection Rules

Catalog Enumeration

name: catalog_enumeration
conditions:
  - session_count_1h > 100
  - completion_rate_1h < 0.05
  - product_access_entropy < 0.2
  - unique_products_1h / total_products > 0.1
action: block_and_alert

Inventory Manipulation

name: inventory_holding
conditions:
  - product.inventory_type == "limited"
  - concurrent_sessions_same_product > 10
  - sessions_from_same_agent_profile > 50
  - completion_rate_1h < 0.1
action: expire_sessions_and_alert

TLS/Profile Mismatch

name: fingerprint_inconsistency
conditions:
  - agent_profile.claimed_platform in ["google", "openai", "shopify"]
  - ja4_fingerprint NOT IN known_fingerprints[claimed_platform]
action: block_and_investigate

The Payment Fraud Dimension

The reconnaissance and inventory attacks get attention, but UCP’s payment flow creates equally serious fraud vectors. This section covers what the spec doesn’t.

Processor Response Code Exploitation

Carders classify stolen cards by testing them against checkout flows. UCP standardizes the response format, making card classification easier:

{
  "status": "failed",
  "messages": [
    {
      "type": "error",
      "code": "payment_declined",
      "content": "Card declined",
      "metadata": {
        "decline_code": "insufficient_funds",
        "processor_code": "05"
      }
    }
  ]
}

The decline_code field maps to processor-specific responses:

The problem: UCP’s standardized error responses make it trivial to build automated card classifiers. A carder can run 1000 cards through your checkout API and get structured, machine-readable decline reasons without ever completing a transaction.

Mitigation: Merchants should genericize decline responses to agents. Return payment_failed without specific decline codes. Reserve detailed codes for your internal logging.

3D Secure and SCA Gaps

UCP’s embedded checkout supports 3DS step-up challenges via iframe delegation:

// Platform delegates 3DS to merchant iframe
{
  "method": "ec.payment.credential_request",
  "params": {
    "requires_authentication": true,
    "authentication_type": "3ds2"
  }
}

But there are gaps:

1. API-only flows bypass 3DS entirely. If the agent completes checkout via REST without using embedded checkout, there’s no browser to render the 3DS challenge. Merchants must either force embedded checkout for card payments or implement out-of-band authentication.

2. SCA exemptions are merchant-controlled. UCP allows merchants to apply Transaction Risk Analysis (TRA) exemptions. Agents can’t request exemptions directly, but they can target merchants known to apply them liberally.

3. 3DS challenge completion timing. Vision-based agents can complete 3DS challenges if they render the iframe. The latency is higher (screenshot loop), but it’s not a blocking factor.

Mitigation: Require embedded checkout for card transactions over your TRA threshold. Don’t apply SCA exemptions for first-time agent transactions.

Token Binding and Replay Attacks

UCP payment credentials use tokenized formats:

{
  "credential": {
    "type": "PAYMENT_GATEWAY",
    "token": "{\"signature\":\"MEUCIQDx...\",\"protocolVersion\":\"ECv2\",\"signedMessage\":\"{...}\"}"
  }
}

The token is a Google Pay or similar payment token. Key questions:

Token lifetime: Google Pay tokens are single-use by design, but the UCP spec doesn’t enforce this at the protocol level. If a merchant’s payment integration doesn’t validate token uniqueness, replay is possible.

Token scope: Tokens are scoped to a specific merchant ID. An attacker can’t take a token generated for Merchant A and use it at Merchant B. But token scope doesn’t prevent replay within the same merchant.

Interception vectors: The agent-to-merchant flow uses HTTPS, but if an agent’s runtime is compromised, tokens can be captured before transmission.

Mitigation: Log token signatures and reject duplicates. Implement token expiry (5-10 minutes from issuance). Validate the merchantId in the signed message matches your account.

The risk_signals Object

UCP includes a risk_signals field in the completion payload:

{
  "payment_data": {...},
  "risk_signals": {
    "platform_risk_score": 0.12,
    "device_signals": {...},
    "behavioral_signals": {...}
  }
}

What’s actually in it: The spec is deliberately vague. Platform providers (Google, Shopify) can populate:

• Device fingerprint hash
• Account age and history
• Session behavioral score
• Geographic consistency
• Known fraud indicators

Can merchants add signals? Not directly. The risk_signals object is platform-controlled. Merchants can only consume it.

Can it be spoofed? A legitimate platform’s risk signals are signed. But a malicious agent hosting its own profile could populate risk_signals with fake data. Merchants must verify the agent profile URI belongs to a trusted platform before relying on risk signals.

Mitigation: Only trust risk_signals from verified platform profiles. Build your own session-level risk scoring as a secondary layer.

Chargeback Liability in Agent Commerce

When an AI agent makes a fraudulent purchase, who eats the chargeback?

Current state: Merchants remain Merchant of Record (MoR). UCP explicitly states this. The merchant bears chargeback liability regardless of who initiated the transaction.

The friction: If Google’s Gemini uses Google’s risk assessment to approve a transaction that turns out to be fraud, the merchant still pays. The agent platform has no liability under the current framework.

Card network rules: Visa and Mastercard haven’t issued specific guidance on agent-initiated transactions. Their existing rules hold the MoR liable. This creates asymmetric risk - platforms benefit from transaction volume, merchants bear the fraud cost.

Mitigation: Track agent-initiated chargebacks separately. If a specific agent profile has elevated chargeback rates, block or challenge that profile. Build contractual protections with platform providers if volume justifies negotiation.

Rate Limit Evasion

Sophisticated carders will evade rate limits through:

Residential proxy rotation:

# Rotate exit nodes per request
proxies = residential_proxy_pool.get_rotating()
session = create_checkout_session(proxies=proxies)

Agent profile rotation:

# Create disposable agent profiles
for card in stolen_cards:
    profile = create_agent_profile(f"https://{uuid4()}.agent-hosting.com/profile")
    test_card(card, agent_profile=profile)

Distributed infrastructure: Cloud functions, serverless workers, and residential botnets provide unlimited IP diversity.

Countermeasures:

• Rate limit by payment method fingerprint (card BIN + last 4), not just IP or profile
• Implement velocity checks across sessions: >N cards from the same device fingerprint = block
• Use payment processor-level velocity (Stripe Radar, Adyen risk engine) as a backstop
• Flag agents that rotate profiles rapidly

Test Environment Exploitation

Google Pay handler supports TEST and PRODUCTION environments:

{
  "environment": "TEST",
  "merchantInfo": {
    "merchantId": "01234567890123456789"
  }
}

The risk: Test environments accept test card numbers (4111…) and return success without hitting real processors. Carders can:

1. Validate card format and checksum
2. Test integration logic
3. Identify merchants with misconfigured production checks

Mitigation: Never expose test environment to agent-facing endpoints. Validate environment: PRODUCTION is enforced before processing. Log and alert on any TEST environment requests in production.

High-Risk Product Categories

Gift cards, digital goods, and instant-delivery items are fraud magnets. Specific mitigations:

Gift cards:

• Delay digital delivery by 24-48 hours for first-time buyers
• Limit gift card purchases to 2 per day, $200 total per agent profile
• Require identity verification (photo ID match) above $100

Digital downloads:

• Implement download velocity limits (no more than 10 downloads per hour from same fingerprint)
• Watermark digital goods with purchaser metadata
• Delay download availability for 1 hour after purchase

Instant services (API keys, subscriptions):

• Require email verification before activation
• Implement trial/pending period before full access
• Monitor usage patterns and suspend anomalies

General rules:

name: high_risk_product_controls
conditions:
  - product.category in ["gift_card", "digital", "instant_delivery"]
  - agent_profile.first_purchase == true
  - order_total > 50
actions:
  - hold_for_review: 24h
  - require_identity_verification: true
  - limit_quantity: 2

Fraud Platform Integration

Most merchants use third-party fraud tools. UCP signals need to flow into these platforms:

Sift integration:

# Pass UCP signals to Sift
sift_event = {
    "$type": "$create_order",
    "$user_id": checkout_session.buyer.email,
    "$session_id": checkout_session.id,
    "ucp_agent_profile": checkout_session.agent_profile_uri,
    "ucp_risk_signals": checkout_session.risk_signals,
    "ja4_fingerprint": request.ja4_hash,
    # Standard Sift fields...
}
sift_client.track(sift_event)

Signifyd / Riskified / Forter: These platforms need custom field mappings for UCP data. Key fields to pass:

• Agent profile URI (new identity dimension)
• Platform-provided risk score (compare against your assessment)
• Session behavioral score (if available)
• TLS fingerprint (JA4)

The gap: None of these platforms have native UCP support yet. You’ll need to map UCP signals to custom fields and build rules around them manually.

Mitigation: Build an abstraction layer that normalizes UCP signals into your fraud platform’s format. Track agent-specific metrics in your fraud dashboard.

The Security Stack: Best Practices for Merchants

UCP isn’t a standalone security solution. It’s one layer of a three-part stack:

All three layers work together. Here’s how to implement them:

Layer 1: UCP Configuration (Baseline)

Required:

• Implement /.well-known/ucp discovery endpoint
• Support the three checkout endpoints (create, update, complete)
• Configure SKU-level native_commerce opt-in
• Implement requires_escalation for high-risk transactions

Recommendations:

# UCP configuration best practices
sku_controls:
  limited_edition: native_commerce: false  # Force web checkout
  gift_cards: native_commerce: false       # High fraud risk
  digital_goods: requires_escalation: true # Human verification

session_limits:
  max_duration: 30m          # Expire abandoned sessions
  max_per_agent_per_hour: 50 # Prevent enumeration
  inventory_hold_duration: 5m # Limit inventory locking

Layer 2: TAP Integration (Identity)

If you have Akamai:

• Enable TAP integration in your Akamai configuration
• Configure agent profile verification
• Set up edge-based behavioral intelligence

If you don’t have Akamai:

• Implement DNS TXT record verification for agent profiles
• Check certificate transparency logs for profile domains
• Build an allowlist of verified platform agent URIs (Google, OpenAI, Shopify)
• Default to requires_escalation for unknown agents

Verification logic:

def verify_agent(ucp_agent_header):
    profile_uri = parse_profile_uri(ucp_agent_header)

    # Check against known platforms
    if is_known_platform(profile_uri):
        # Verify via DNS TXT or CT logs
        if not verify_domain_ownership(profile_uri):
            return "requires_escalation"
        return "verified"

    # Unknown agent - escalate
    return "requires_escalation"

Layer 3: Behavioral Analysis (Intent)

This is the layer TAP doesn’t provide. Implement:

Session-level intent scoring:

def calculate_intent_score(agent_profile, session):
    signals = {
        "completion_rate": get_completion_rate(agent_profile, hours=24),
        "product_entropy": calculate_product_access_entropy(session),
        "geographic_spread": count_unique_zipcodes(session),
        "time_to_buyer_info": session.buyer_info_timestamp - session.created_at,
        "fulfillment_queries": count_fulfillment_updates(session),
    }

    # Red flags
    if signals["completion_rate"] < 0.05:
        return "suspicious"  # 95% abandonment
    if signals["product_entropy"] < 0.2:
        return "suspicious"  # Sequential access pattern
    if signals["geographic_spread"] > 100:
        return "suspicious"  # Shipping rate harvesting

    return "normal"

Cross-session pattern detection:

• Track agent profiles over time (not just per-request)
• Build reputation scores based on historical behavior
• Flag agents that suddenly change patterns

Honeypot deployment:

• Insert fake product IDs in API responses
• Monitor for checkout sessions containing honeypot products
• Any hit = reconnaissance in progress

Putting It Together: Decision Matrix

                    ┌─────────────────────────────────────────┐
                    │           Incoming UCP Request          │
                    └─────────────────┬───────────────────────┘
                                      │
                    ┌─────────────────▼───────────────────────┐
                    │         TAP Verification                │
                    │   Is agent identity verified?           │
                    └─────────────────┬───────────────────────┘
                                      │
                    ┌────────Yes──────┴──────No───────┐
                    │                                  │
          ┌─────────▼─────────┐              ┌────────▼────────┐
          │ Behavioral Check  │              │ requires_       │
          │ Is intent normal? │              │ escalation      │
          └─────────┬─────────┘              └─────────────────┘
                    │
          ┌───Yes───┴───No────┐
          │                   │
   ┌──────▼──────┐    ┌───────▼───────┐
   │   Allow     │    │   Challenge   │
   │   (API)     │    │   or Block    │
   └─────────────┘    └───────────────┘

Implementation Checklist

Week 1: Foundation

• Audit current checkout flow for UCP compatibility
• Identify high-risk SKUs (limited editions, gift cards, digital goods)
• Configure native_commerce and requires_escalation per SKU

Week 2: Identity Layer

• If Akamai customer: Enable TAP integration
• If not: Build agent profile verification (DNS/CT logs)
• Implement fallback to requires_escalation for unknown agents

Week 3: Behavioral Layer

• Deploy session-level intent scoring
• Set up cross-session tracking per agent profile
• Configure velocity limits and completion rate monitoring

Week 4: Honeypots and Monitoring

• Insert honeypot products in catalog
• Set up alerting for honeypot hits
• Build dashboard for agent-level metrics (completion rate, session velocity)

Ongoing:

• Tune thresholds based on false positive rates
• Update verified agent allowlist as new platforms emerge
• Review agent reputation scores weekly

The Transition Window

Here’s what I keep coming back to: UCP probably represents a net positive for consumers.

Agentic shopping means never overpaying because you didn’t check three other sites. It means accessibility for users who struggle with complex checkout flows. It means your AI assistant can actually complete a purchase instead of just showing you a link.

The security problems are real, but so are the countermeasures. TAP provides cryptographic agent verification. The requires_escalation state maintains human-in-the-loop for high-risk transactions. AP2’s provable consent secures payment authorization.

The issue isn’t that these solutions don’t exist - it’s that adoption takes time.

TAP was announced in October 2025. Most merchants haven’t integrated it yet. The NRF 2026 announcements (Walmart, Target, Shopify moving to UCP natively) will accelerate adoption, but there’s still a gap between “protocol supports security feature” and “merchant has implemented security feature.”

This isn’t a permanent flaw in UCP. It’s a transition period. Traditional bot detection (mouse tracking, CAPTCHAs) is becoming irrelevant not because agents “broke” it, but because the industry is moving to identity-based authentication. The destination is more secure. The journey has risks.

The question is whether merchants will implement UCP with its full security stack, or whether they’ll expose endpoints without TAP integration, without behavioral analysis, without velocity limits - and learn the hard way why those features exist.

Unlike previous transitions, this one is happening in public. The spec is open. The threat model is documentable. The security features are designed in, not bolted on. We can start building defenses now rather than reverse-engineering attacks later.

Open Questions

I don’t have answers to these. If you do, I’d like to hear them:

1. Agent identity verification at scale. How do you verify that a UCP-Agent header claiming to be Gemini is actually from Google? DNS TXT records? Certificate pinning? A central registry? All have trade-offs.

2. The inventory holding problem. Session timeouts are configurable, but too short breaks legitimate shopping and too long enables manipulation. Is there a middle ground, or does this require inventory reservation redesign?

3. Behavioral ML against generative AI. When the attacker can fine-tune a model to mimic human behavior, behavioral detection becomes adversarial ML. How do you stay ahead when iteration is cheap?

4. Industry coordination. Should there be a shared reputation database for agent profiles? Who operates it? Who decides what’s malicious?

5. The regulatory angle. GDPR, CCPA, and the DSA all have provisions about automated access. Does UCP change the legal landscape for scraped data?

References

UCP Core Documentation

• Google UCP Developer Guide
• UCP Specification
• UCP GitHub Repository
• Google Developers Blog: Under the Hood UCP
• Shopify Engineering: Building the Universal Commerce Protocol

Security & Trust Layer

• Akamai and Visa: Trusted Agent Protocol
• Visa: Trusted Agent Protocol Announcement
• Shopify: Checkout for Agents (requires_escalation)

Detection & Fingerprinting

• JA4+ Fingerprinting

Share this post

Like this post? Share it with your friends!

• Share on Facebook, opens in a new tab
• Share on Twitter, opens in a new tab
• Share on LinkedIn, opens in a new tab