How to Fix "UCP signing_keys missing" - Complete Guide (2026)

Your UCP manifest validates as structurally correct. But AI shopping agents still can't trust it. Here's why - and exactly how to fix it.

What are UCP signing_keys?

signing_keys are cryptographic public keys embedded in your UCP manifest at /.well-known/ucp. They let AI agents verify that your manifest hasn't been tampered with and that commerce requests originated from your domain.

Without signing_keys, an AI agent has no way to confirm that a checkout request or cart update actually came from your store. The agent will either refuse to transact or fall back to a degraded experience - which means you're invisible at the moment of purchase.

This is the single most common UCP failure. In our scans, missing signing_keys shows up on the majority of profiles that otherwise pass structural validation.

Why signing_keys are NOT optional

Some validators mark signing_keys as "optional" or "recommended." This is misleading.

The UCP spec requires signing_keys for any profile that supports transactional capabilities (Checkout, Payment, Cart). If your store accepts purchases, your manifest needs signing_keys. Period.

Google AI Mode, ChatGPT, and other AI shopping agents all require cryptographic verification before initiating transactions. A profile without signing_keys may still be "discovered" - but the agent won't complete a purchase.

How signing_keys work (the short version)

1. Your UCP manifest declares one or more public keys under signing_keys
2. When an AI agent wants to interact with your store, it fetches your manifest
3. The agent uses those public keys to verify signed requests from your domain
4. If verification fails or keys are missing, the agent aborts the transaction

Think of it like HTTPS certificates. You wouldn't run an e-commerce site without TLS. You shouldn't run a UCP profile without signing_keys.

How to add signing_keys to your UCP manifest

Step 1: Generate a key pair

Use Ed25519 (recommended by the UCP spec) or ES256:

# Generate Ed25519 key pair
openssl genpkey -algorithm Ed25519 -out ucp_private.pem
openssl pkey -in ucp_private.pem -pubout -out ucp_public.pem

# Extract the public key in JWK format
# You'll need the key ID (kid) and the base64url-encoded x coordinate

Step 2: Add the key to your manifest

Your /.well-known/ucp file should include a signing_keys array. Here's a minimal example:

{
  "namespace": "ucp",
  "version": "1.0",
  "origin": "https://yourstore.com",
  "capabilities": {
    "checkout": {
      "endpoint": "https://yourstore.com/api/ucp/checkout"
    }
  },
  "signing_keys": [
    {
      "kid": "2026-05-primary",
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "your-base64url-encoded-public-key-here",
      "use": "sig"
    }
  ]
}

Step 3: Sign your outgoing requests

When your store responds to AI agent requests, sign the payload with your private key. The agent verifies using the public key from your manifest.

Step 4: Validate the fix

After adding signing_keys, run a full UCP validation that includes network-level testing. A structural check (valid JSON, required fields) won't catch key mismatches. You need:

• Structural validation: is the key field present and well-formed?
• Network validation: can the agent fetch and parse the key?
• SDK/simulation: can the agent actually verify a signed request?

Common signing_keys mistakes

Wrong key format: The spec requires JWK format. Raw PEM or hex-encoded keys will fail.

Missing key ID (kid): Agents use the kid field to identify which key to use. Omit it and verification breaks.

Key rotation without updating the manifest: If you rotate keys, update the manifest immediately. A stale manifest with revoked keys is the same as no keys at all.

Only testing structural validation: This is the big one. Your validator says "PASS" but the key is malformed or the signing implementation is wrong. Always test with an AI agent simulator.

Using the same key across multiple domains: Each origin should have its own signing key. Cross-domain key reuse breaks the origin verification model.

How to verify your fix actually works

Don't rely on structural-only validators. You need a tool that tests all four levels:

1. Structural: is the signing_keys field present?
2. Rules: are the key format and fields correct per spec?
3. Network: can agents fetch and parse the key over HTTPS?
4. SDK/Simulation: can an AI agent actually verify a signed request from your domain?

Run a free validation at ucptools.dev to check all four levels in one scan.

Related failures to check

If you're fixing signing_keys, also verify these common companion failures:

• No payment_handlers: agents can't process payments even with valid signatures
• Namespace/origin mismatch: your manifest URL doesn't match the declared origin
• HTTP instead of HTTPS: all UCP endpoints require HTTPS
• Missing Identity Linking: cross-domain user recognition fails

Last updated: May 2026. UCP spec version 1.2 referenced. signing_keys are required for transactional capabilities per the current spec.