Agent Authentication & Identity Verification in Agentic Commerce: Preventing Fraud at the AI Layer

Agentic commerce introduces a new vulnerability class: fraudulent or compromised AI agents posing as legitimate commerce actors. Unlike traditional e-commerce, where merchants authenticate humans via passwords and payment methods, autonomous systems must authenticate other autonomous systems in real time, with cryptographic proof and behavioral validation. This article defines the authentication problem in agentic commerce, maps the threat surface, and outlines practical identity verification architectures merchants and platforms must deploy.

The Agent Authentication Problem

In traditional commerce, trust flows through payment processors and known merchant domains. A customer recognizes Amazon.com by HTTPS and brand reputation. A merchant trusts PayPal because of legal contracts and settlement guarantees.

Agentic commerce disrupts this model. An agent acting on behalf of a consumer may:

• Execute transactions across multiple merchant APIs simultaneously
• Negotiate pricing without human approval
• Access inventory, pricing, and fulfillment data in real time
• Represent unknown or new consumers with no prior transaction history

Without cryptographic identity verification, merchants cannot distinguish between:

• A legitimate agent authorized by the consumer
• A hijacked agent with stolen credentials
• A fraudulent agent impersonating a real commerce platform
• A competitor agent scraping pricing or inventory data

JPMorgan and Mirakl’s recent AI agent checkout partnership (announced March 2026) requires baseline identity proofs—but neither has published the authentication mechanism. This gap leaves merchants exposed.

Three Layers of Agent Authentication

Layer 1: Cryptographic Agent Identity

Every agent must present a verifiable identity credential at runtime. This is not a bearer token—it’s a cryptographic proof of origin and authorization.

Public Key Infrastructure (PKI) for Agents:

• Each agent receives a unique Ed25519 or RSA-4096 keypair at creation
• The agent’s public key is registered with the authorizing platform (e.g., OpenAI, Anthropic, or a merchant’s internal agent factory)
• On every merchant API call, the agent signs the request payload with its private key
• The merchant verifies the signature and confirms the public key is registered with a trusted issuer

This prevents impersonation. A stolen API key alone is insufficient; an attacker must also possess the agent’s private key to sign requests authentically.

Example Implementation:

When Shopify’s ChatGPT-integrated agent (launched March 2026) submits a cart, it includes:

• Agent ID: agent_7f2k9x
• Timestamp: 1710345600
• Request Body: {cart_items: [...], shipping_address: {...}}
• Signature: HMAC-SHA256(private_key, request_body + timestamp)

Shopify’s API verifies the signature matches the public key on file for agent_7f2k9x. If verification fails, the request is rejected as fraudulent.

Layer 2: Agent Authorization & Delegation Proof

A valid cryptographic identity is necessary but not sufficient. A merchant must verify that the agent is actually authorized to act on behalf of the consumer.

Delegation Tokens:

A consumer must explicitly authorize an agent to act on their behalf. This authorization is encoded in a signed delegation token, which the agent presents alongside every request.

Token Structure:

• Issuer: Consumer’s identity provider (e.g., Google, Auth0, or consumer’s bank)
• Subject: Consumer’s unique ID
• Agent Claim: Agent ID + scopes (e.g., “can_purchase_up_to_500_usd”, “can_access_order_history”)
• Expiration: Token valid for 24 hours, then requires refresh
• Signature: Issuer’s private key signs the token

A merchant receives a request from agent A on behalf of consumer B. The agent provides:

• Agent identity proof (Layer 1)
• Consumer delegation token (Layer 2)

Merchant validates both. If either fails, the transaction is rejected.

Layer 3: Behavioral & Risk Validation

Cryptographic proofs can be compromised if the issuing system is breached. A behavioral layer detects anomalies that suggest a hijacked or fraudulent agent:

• Deviation from agent profile: If an agent typically purchases fashion items but suddenly orders industrial equipment, flag it
• Unusual velocity: If an agent submits 100 orders in 10 seconds (possible bot attack), throttle requests
• Geolocation mismatch: If an agent’s last request was from London 1 second ago and the next from Tokyo, verify with the consumer
• Merchant reputation check: Confirm the agent is authorized to transact with this specific merchant (not all agents can buy from all sellers)

Azoma’s AMP (announced March 2026) includes brand control features—this is the behavioral layer. Brands can whitelist authorized agents and reject suspicious ones in real time.

Threat Model: What Are Merchants Protecting Against?

Agent Impersonation Attacks

An attacker creates a fake agent claiming to represent OpenAI or Shopify. Without cryptographic verification, merchants cannot tell the difference.

Mitigation: Merchant maintains a whitelist of authorized agent issuers (e.g., only agents signed by OpenAI’s root key are trusted). Every agent’s public key is traced back to the issuer’s certificate chain.

Credential Theft & API Key Leaks

An agent’s API key is exposed in a GitHub commit. An attacker uses the key to make unauthorized purchases.

Mitigation: API keys are decoupled from agent identity. The agent also signs requests with its private key. A stolen key alone cannot create valid signatures.

Consumer Session Hijacking

A consumer’s delegation token is intercepted or stolen. An attacker uses it to authorize fraudulent purchases.

Mitigation: Delegation tokens are short-lived (24 hours max) and bound to the agent’s identity. A stolen token cannot be used by a different agent. Refresh tokens require re-authentication from the consumer.

Man-in-the-Middle (MITM) Attacks

An attacker intercepts agent-to-merchant communication and modifies the request (e.g., changing the price or quantity).

Mitigation: All agent-to-merchant communication is encrypted (TLS 1.3) and signed. The merchant verifies the signature; modified requests fail verification.

Practical Implementation Path for Merchants

Step 1: Establish an Agent Registry

Maintain a database of authorized agents and their public keys:

• Agent ID (e.g., gpt-4-shopper-001)
• Issuer (e.g., openai.com)
• Public key (Ed25519 format)
• Authorized scopes (e.g., max transaction size, product categories)
• Created/revoked timestamps

Step 2: Implement Request Signing Verification

On every API call from an agent:

• Extract the agent ID and signature from the request header
• Look up the agent’s public key in the registry
• Verify the signature against the request body
• Check scopes (e.g., is the transaction amount within the agent’s limit?)
• Reject if verification fails

Step 3: Require Delegation Tokens for Consumer Actions

Any agent action on behalf of a consumer must include:

• A valid JWT or SAML token signed by a trusted identity provider
• The token includes the consumer ID and agent ID
• The merchant verifies the signature and checks expiration

Step 4: Deploy Behavioral Monitoring

Log all agent transactions and monitor for anomalies:

• Agent velocity (requests per minute)
• Purchase patterns (typical price range, product types, geographic origin)
• Deviations trigger a risk flag; high-risk transactions require consumer confirmation

Standards & Emerging Frameworks

The UCP (Universal Commerce Protocol) does not yet define a mandatory authentication standard. However, several frameworks are emerging:

OAuth 2.0 with Agent Assertion: Extends OAuth to allow agents to request delegation on behalf of consumers using signed assertions (similar to JWT Bearer flows in API gateway security).

OIDC (OpenID Connect) for Agents: Allows agents to prove identity via an identity provider without exposing the consumer’s password.

W3C Verifiable Credentials: A decentralized alternative where agents hold cryptographic proofs of identity issued by trusted authorities.

Shopify and JPMorgan will likely converge on OAuth 2.0 with custom agent extensions, as it’s the existing standard for third-party app authorization.

FAQ: Agent Authentication in Agentic Commerce

Q: Why not just use API keys like traditional integrations?

API keys are static and reusable. If leaked, they grant full access. Agent authentication uses short-lived tokens, scoped permissions, and cryptographic signing—much more resistant to compromise.

Q: Who issues the agent’s public key and identity certificate?

The agent’s creator (e.g., OpenAI, Anthropic, or a merchant’s internal AI system) issues the keypair. The public key is registered with each merchant the agent will transact with, or with a trusted intermediary (like a payment processor).

Q: How does a consumer revoke an agent’s authorization?

The consumer logs into their account and revokes the delegation token. The agent can no longer present a valid token, and all requests are rejected. This is similar to revoking OAuth app access.

Q: Can agents transact with each other without human involvement?

Yes. Agent-to-agent transactions (e.g., a buyer agent and a seller agent negotiating a deal) both authenticate with cryptographic proofs. No consumer delegation token is needed if both agents are explicitly authorized by their respective principals (buyer/seller).

Q: What happens if an agent’s private key is compromised?

The issuer (e.g., OpenAI) revokes the agent’s public key from all merchant registries. The agent is deactivated and cannot authenticate. The merchant immediately flags any transactions from that agent as fraudulent.

Q: How do small merchants implement this without extensive infrastructure?

Use a commerce platform (Shopify, Mirakl) or payment processor (JPMorgan) that handles agent authentication centrally. The merchant receives a pre-verified request and does not need to manage keys directly.

Q: What is the performance impact of cryptographic signing on every request?

Negligible. Ed25519 signing is sub-millisecond on modern hardware. Verification is similarly fast. The bottleneck is network latency, not cryptography.

Conclusion: Agent Identity is Foundational

Agentic commerce cannot scale without trustworthy agent authentication. Merchants must verify not just that a request is cryptographically valid, but that the agent is authorized to act on behalf of the consumer, and that the transaction aligns with the agent’s behavioral profile.

The architectures outlined here—cryptographic identity, delegation tokens, and behavioral monitoring—are the baseline. Platforms like Shopify, JPMorgan, and Mirakl will abstract these into managed services. But merchants must understand the threat model and audit their integrations to ensure agents are properly authenticated before they execute high-value transactions.

Without this layer, agentic commerce is a fraud vector, not an innovation.