AI Shopping Agent Security: How UCP Handles Trust and Authorization

The Trust Problem in Agent Commerce

When a human shops online, trust flows in multiple directions simultaneously. The consumer trusts the merchant's website. The merchant trusts the payment provider. The payment provider trusts the card network. Everyone trusts the browser's SSL certificate.

Agent commerce inserts a new actor: the AI agent. The agent acts on behalf of the consumer. It makes decisions, initiates transactions, and completes purchases without a human reviewing each step. This creates new questions.

How does a merchant know an agent is authorized to spend on behalf of the consumer? How does the consumer control what an agent can buy? How does an agent verify a merchant is legitimate and not a phishing endpoint? UCP's answer to all three is layered: payment token scoping, identity linking, and endpoint verification.

Payment Token Scoping

The payment token is the core security primitive in UCP. Before an agent can make a purchase, the consumer must pre-authorize a payment token with their agent platform. The token is not a raw card number or bank credential. It is a scoped authorization that defines exactly what the agent can spend.

Token scopes are set by the consumer when they link their payment method. A consumer might authorize a token with the following constraints:

{
  "tokenId": "tok_abc123",
  "maxTransactionAmount": 200,
  "maxDailySpend": 500,
  "allowedCategories": ["electronics", "groceries"],
  "requiresConfirmationAbove": 100,
  "expiresAt": "2026-12-31T00:00:00Z"
}

The agent can present this token at any UCP merchant checkout. The payment handler validates the token against its constraints before authorizing the transaction. A $250 purchase at an electronics merchant hits both the per-transaction limit and the category check simultaneously. The payment handler rejects the transaction, and the agent must request confirmation from the consumer before proceeding.

Scope validation happens at the payment handler, not at the merchant. The merchant never sees the token constraints. This keeps the authorization logic centralized in the payment system rather than distributed across thousands of merchant implementations.

Identity Linking and Consent

UCP Identity Linking ties a consumer's existing merchant account to their agent platform. When an agent initiates checkout, it presents an identity token that proves the session belongs to a specific merchant account. The merchant uses this to apply member pricing, loyalty points, and saved preferences.

The identity token is scoped at the merchant level. A consumer links their Amazon account to their agent separately from their Shopify account. Each link is an explicit consent action: the consumer reviews what the agent can access and approves. Merchants cannot request agent access to account data without explicit consumer consent.

What can an identity token expose? The scope is defined in the UCP Identity Linking specification:

• profile.read -- name, email, default shipping address
• loyalty.read -- points balance, tier, active offers
• loyalty.redeem -- apply points to a checkout session
• orders.read -- order history for replenishment and reorder flows

Agents request only the scopes they need. An agent handling a first-time purchase needs profile.read for shipping. A replenishment agent needs orders.read to know what was purchased last time. A consumer can review and revoke individual scopes at any time through their agent platform settings.

Merchant Endpoint Verification

Agents need to verify that a merchant's UCP endpoint is legitimate. A malicious actor could stand up a fake UCP endpoint that looks like a real merchant but routes payment tokens to an attacker-controlled account. UCP prevents this through manifest signing and a domain validation requirement.

Every UCP manifest must be served from the registered merchant domain at /.well-known/ucp. The manifest is signed with a key registered in the UCP directory. Agents verify the signature before presenting any payment tokens.

// Agent-side verification before checkout
async function verifyMerchantEndpoint(domain: string): Promise<boolean> {
  const manifest = await fetch(`https://${domain}/.well-known/ucp`).then(r => r.json());

  // Verify manifest signature against UCP directory public key
  const isValid = await verifyManifestSignature(manifest, manifest.signature);

  // Check merchant is registered in UCP directory
  const isRegistered = await checkUcpDirectory(manifest.merchantId);

  return isValid && isRegistered;
}

Unverified endpoints return a warning state to the agent. Well-built agents refuse to present payment tokens to unverified endpoints. This matches the pattern of how browsers handle invalid SSL certificates: proceed is possible but requires explicit user confirmation.

The UCPList directory shows verification status for listed merchants. Merchants marked "unverified" have self-reported UCP support but have not passed conformance testing. Agents that check UCPList status before checkout add an extra layer of protection beyond the cryptographic verification.

What Can Go Wrong

No protocol eliminates all risk. The failure modes in UCP agent commerce are worth understanding.

Token theft. If an attacker compromises the consumer's agent platform and extracts a payment token, they can make purchases up to the token's scope limits. Token scoping limits the blast radius: a stolen token with a $200 limit and an electronics-only restriction is a much smaller risk than a stolen credit card number. Consumers should set conservative scopes and review agent purchase history regularly.

Merchant endpoint hijacking. If a merchant's domain is compromised and the attacker modifies the /.well-known/ucp manifest, agents may route payment tokens to a fraudulent checkout endpoint. This is mitigated by manifest signing, but only if the signing key was not also compromised. Merchants should treat their UCP signing key with the same security posture as their SSL private key.

Scope creep in identity tokens. If an agent requests broader identity scopes than it needs, it has access to consumer data it should not have. Consumers should audit the scopes their agent has requested from each merchant, particularly for orders.read and loyalty.redeem which have higher potential for misuse than profile.read.

Replay attacks. A checkout session token that is captured in transit could theoretically be replayed to initiate a duplicate order. UCP checkout tokens are single-use and expire within 30 seconds of issuance. Merchants must reject tokens outside the expiry window.

Secure Agent Development Checklist

If you are building an agent that handles UCP transactions, run through this before shipping to consumers:

1. Verify merchant endpoints before presenting payment tokens
2. Store payment tokens encrypted at rest, never in plaintext logs
3. Request minimum necessary identity scopes from each merchant
4. Implement the 409 conflict handler for checkout failures rather than retrying silently
5. Surface payment confirmation prompts for transactions above the consumer's set threshold
6. Log all agent transactions with timestamp, merchant, amount, and result for consumer review
7. Implement token revocation handling: if a token is revoked mid-session, fail gracefully rather than erroring silently

The security model in UCP is well-designed. The risks are real but bounded. Payment token scoping means the worst-case outcome of a compromise is a capped loss, not unlimited card fraud. Agents that implement the full security model give consumers a safer shopping experience than most current browser-based checkout flows.

Listings in the UCPList directory include conformance status. Merchants that have passed conformance testing have a lower endpoint risk profile for agent developers. Filter by conformance status when deciding which merchants to support in your agent's default integration set.