Is it safe to let AI agents into your store? Free & Pro

Safer than the alternative, which is agents scraping your pages and asking customers for passwords. But "safe" is not a yes-or-no answer; it depends on what could go wrong. This guide takes the worries merchants raise most, says what Agent Adapt actually does about each, and is honest about where the limits are. Every behaviour described here is checked by the plugin’s test suite on each release.

"An agent could spend my customers’ money"

It cannot. Under the Personal Agent Protocol’s current draft an agent does not pay; the draft lists payments as an open topic. At a store running Agent Adapt, the agent builds a cart and hands the customer a single-use link. A person opens it and pays on your checkout with your payment methods. Agent Adapt never sees card details.

With Pro, an agent can ask to cancel a paid order with a refund. That needs the customer’s approval of the exact terms, including the amount, and you can switch it off entirely. Money moves back towards the customer, never away.

"An agent could read customer data"

Only the customer’s own, and only with their approval. Signed out, an agent sees what any visitor sees: the catalogue and your public policy pages. To read orders or addresses, the customer must sign in on your store’s own page and tick what the agent may see. The store re-checks that approval on every request. Another customer’s order and an order that does not exist get the same 404, so an agent cannot probe for order numbers.

Approval lasts 90 days and ends sooner if the customer disconnects the agent, changes their password or email, or you block the agent.

"An agent could get into a staff account"

No. Only customer and subscriber accounts can be connected. Administrator and shop manager accounts, and any account with store-management capabilities, are refused at sign-in and again on every request. If a customer account is later promoted, its connected agents stop working at once. See Which accounts can connect.

"Tokens could be stolen"

They would be useless alone. Every token is bound to a key the agent holds, and every call carries a signed, single-use proof of that key. Your store keeps tokens only as one-way hashes. Tokens are never put in URLs, and the plugin never logs them. See How your store knows which agent is calling.

"An agent could pretend to be another agent"

Not without its private key. An agent’s identity is the HTTPS address of its published document; signatures are checked against the keys published there. A look-alike domain is a different agent with a different address, which is what the Agents screen and the customer’s consent page show.

"A rogue agent could do damage"

A signed-out agent can search, read and build carts, within rate limits. That is what any visitor can do. A signed-in agent can do what the customer approved, for that customer only. If you don’t like an agent, press Block under WooCommerce → Agents and it is refused from its next request, everywhere, including for customers who had approved it. With Pro you can run an allowlist instead and admit only agents you have ticked, cap any agent at view-only, and switch off individual actions.

"Customers could be phished for their passwords"

The protocol is designed so that an agent never needs the customer’s password. Sign-in happens on your store’s own page, in the customer’s own browser, and the agent receives a token, not credentials. An agent that asks a customer for their store password is not using the protocol, and nothing in Agent Adapt would accept credentials from it. Agent Adapt does not offer the draft’s optional credential-submitting sign-in.

"Agents could hammer my server"

Rate limits apply per agent, per customer and per visit: 300 API calls a minute per visit, 120 token requests a minute per address, 3,000 new visits an hour per agent, and tighter limits on agents your store has never seen. Over the limit, the agent gets a 429 with a Retry-After and is expected to wait. Scrapers that ignore the protocol are a separate problem that no protocol solves; your CDN’s bot rules still apply to them, and you can exclude Agent Adapt’s three paths from those rules so well-behaved agents get through.

"My data could end up with the plugin’s makers"

It cannot, because the plugin sends nothing to us. No usage data, no store details, no customer data, and no licence check in the free plugin. The only outside requests it makes are to the agents themselves, to fetch their public documents, and those requests carry nothing about your customers. See What Agent Adapt stores and shares.

"Hidden products could leak"

Products hidden from your catalogue are not served to agents, in search, in browsing or by ID. Asking for one by ID gets the same answer as a product that does not exist. A developer can change that with a filter, and only on purpose.

Where the limits are

Be clear about what no plugin can do.

• An agent the customer trusts can misuse what the customer approved. If a customer grants "make changes" to a careless agent, that agent can cancel the customer’s unpaid orders. The consent page is written to make the grant clear, and the customer can revoke it, but the choice is theirs.
• Customers can approve too much. Each permission is a separate tick box, and the default is to ask for what the agent requested. Some customers will tick everything.
• The protocol is a draft. Security properties that hold today hold under Draft 0.1. We follow changes and record them in the changelog.
• Agents that ignore the protocol are unaffected by it. A proper door does nothing about a scraper that climbs in through the window.

Common questions

Should I block agents until the protocol is finished?

That is a reasonable choice for a store with nothing an assistant could usefully buy. For most stores, the alternative to serving agents properly is being scraped, which is worse on every point above.

Does Agent Adapt add any new way to log in to WordPress?

No. Customers sign in through your normal WordPress login page. The agent gets a token for Agent Adapt’s own API only. That token is refused by the WordPress REST API, the WooCommerce APIs and the dashboard.

What should I do if an agent misbehaves?

Block it. Then, if a customer was affected, look at the order notes and the Agents screen for what it did, and email [email protected] if you think the plugin let it do something it should not have. Security reports go to [email protected].

Who checked this?

The plugin’s own test suite, which plays a real agent against a real WordPress and WooCommerce over real TLS, and tries the wrong thing for every rule above to prove the rule holds. See How we test. No outside audit has been done yet, and we will say so here when one has.