2026-07-23 · security · development to watch

Trusted AI agent or bot? Agent identity for WooCommerce

User-agent strings are labels, not proof. Safer agentic commerce needs verifiable identity, scoped intent and merchant authorization.

TL;DR — A request that looks like an AI agent may be a useful shopper, an ordinary crawler, a misconfigured client or an attacker. A user-agent string cannot prove which one it is. Emerging systems such as Visa Trusted Agent Protocol use signed messages to carry stronger evidence, but WooCommerce merchants still need bounded public surfaces, rate limits and explicit authorization boundaries today.

“AI traffic” is not one security category

A merchant may see four very different callers arrive through the same web stack: a crawler indexing public pages, a browser agent acting for a user, a configured API or MCP client, and an automated attacker. They may share cloud networks, headless browsers and similar request patterns. Blocking or allowing them solely by appearance is unreliable.

A blocked request proves that a defensive rule fired. It does not prove that the caller was malicious. In our own bounded telemetry, some targeted lookups from German and UK hosting paths were rejected before catalog access. That observation does not identify the caller; it shows why network location alone is weak evidence.

A label is not an identity

User-Agent, custom headers and a tool name are self-declared. An attacker can copy them. IP allowlists can help in tightly controlled integrations, but large agent services use changing infrastructure and shared networks. API keys identify possession of a secret, not necessarily the end user or the exact intent of a transaction.

Useful identity needs evidence that is difficult to forge and precise enough for the decision being made. Reading a public product price and cancelling a paid order should never require the same level of trust.

What Visa Trusted Agent Protocol changes

Visa’s Trusted Agent Protocol specifications define signed request containers for agent, consumer and payment context. The design uses RFC 9421 HTTP Message Signatures, allowing a merchant or its infrastructure to verify protected message components instead of trusting a copied label.

The protocol is designed to help merchants distinguish approved commerce agents from ordinary bots across web, API and agent-protocol traffic. It is currently a development and deployment program, not a universal identity layer already present on every store. KaliCart Bridge does not claim Visa certification or TAP verification.

Identity, intent and authority are separate questions

QuestionExample evidenceWhat it does not prove
Who operates the client?Verified signature and registered keyThat the user approved this action
What is the client trying to do?Signed intent and request scopeThat the merchant permits it
Which shopper authorized it?Short-lived user-bound grantThat every order belongs to that shopper
May this operation run?Merchant policy and capability checkThat the input is safe or correct

A valid signature can authenticate a message and still carry a request the merchant must deny. Verification belongs before authorization, not in place of it.

What a WooCommerce merchant can do now

Where KaliCart Bridge draws the line

KaliCart Bridge publishes a deliberately read-only catalog surface for discovery and product verification. It uses bounded requests, rate limiting and merchant-controlled catalog data. It does not grant public callers access to WooCommerce administration, customer records or order mutation.

That reduces the consequence of misidentifying a caller: an unknown client may ask only for intentionally public product facts. It does not make bot management disappear, authenticate a shopper or let the plugin bypass a host’s security layer.

The practical rule

Make low-risk facts safely public; demand cryptographic identity and explicit authority as the consequence of an action rises.

← All posts