What Is Agentjacking? The AI Attack That Reaches Your Store From Two Sides

Agentjacking is an attack that feeds hidden instructions to an AI agent through content it already trusts, so the agent carries out an attacker's orders while appearing to do its job. For an online store it cuts two ways: the AI agents that build and maintain your site, and the AI agents that shop on it.

This is part of our AI vs. Your Store series on how AI is reshaping the risk to a small merchant's checkout.

What is agentjacking?

Agentjacking is what happens when an AI agent reads something an attacker wrote and treats it as an instruction. The attacker hides commands inside ordinary content the agent is expected to read: a bug report, a product page. The agent cannot tell the difference between information and orders, so it acts.

An AI agent is different from a chatbot. A chatbot answers you. An agent reads, decides, and then does something: runs a command, places an order.

Computing has always kept data and instructions in separate lanes. Agents blur that line by design, because reading text and deciding what to do about it is the entire point of them.

Has agentjacking actually happened, or is this theoretical?

It has happened, and it has a name because researchers proved it. In June 2026 Tenet Security published a working attack it called agentjacking, hijacking AI coding agents through fake bug reports. It worked against Claude Code, Cursor and OpenAI Codex at an 85% success rate, and 2,388 organizations were exposed to it.

The chain is uncomfortably short.

Development teams catch production bugs with an error-reporting service. Sentry is one of the most widely used. It works by putting a key in your website's public code so your site can report its own crashes, and that key is write-only by design, so anyone who finds it can send a report in.

The researchers sent fake bug reports containing hidden text formatted to look like the "here is how to fix this" notes a real report carries. When a developer later asked their AI agent to work through the reported bugs, the agent pulled in the fake one and followed it. In testing, cloud credentials, code-repository tokens and environment secrets walked out (Tenet Security, June 2026).

The affected list included a Fortune 100 company and organizations across more than 30 countries. Among the top one million websites, researchers found 71 keys that could be injected this way (Cloud Security Alliance, June 2026).

Why does an attack on coding agents matter to a store owner?

Because the people who maintain your store increasingly use these agents, and those agents hold your keys. Your developer or agency runs a coding assistant against the same codebase that renders your checkout. A hijacked agent inherits every credential that developer has, including the ones that can change your payment page.

Follow the line. Attacker to fake bug report, to the agency's laptop, to your deployment pipeline, to the code your customers type card numbers into. Nobody phished you. Nobody guessed a password.

This is a supply-chain attack with a new entry point. The risk did not arrive through a plugin you installed. It arrived through a tool your developer adopted, probably without mentioning it, because using an AI assistant is not the kind of thing anyone thinks to tell a client.

That is the honest gap here. Most merchants have no idea whether their agency uses AI coding agents, what those agents are connected to, or whether a human reviews what they ship.

Can the AI agents shopping at my store be hijacked too?

Yes, and this direction sits closer to your revenue. Palo Alto Networks' Unit 42 documented in March 2026 how a poisoned page can rewrite a shopping agent's working memory, so the checkout it eventually submits contains items the customer never chose, such as a $100 digital gift card routed to the attacker.

The setup is mundane. The agent visits a deals or coupon site to hunt for a discount, which is exactly what it was told to do. Hidden text on that page changes what it does next. The customer may not notice until a bank statement arrives (Unit 42, March 2026).

Unit 42 documented a second pattern aimed straight at merchants: instructions hidden in product data telling an agent to skip verification and issue an instant refund against a fake tracking number. Automated at scale, that is thousands of fraudulent refunds an hour.

The two halves of this article do not rest on equal evidence, and you should know which is which. The coding-agent attack was run against real organizations. The shopping-agent version is a documented attack pattern, not a confirmed merchant breach. Same mechanic, so treat it as a question of when, not whether.

This is not a small slice of traffic. Akamai reported in July 2026 that nearly half of all e-commerce traffic across its global network, 48%, is now driven by AI bots (Akamai via Security Boulevard, July 2026).

Here is the part that should bother you most. A hijacked shopping agent produces an order that looks completely legitimate: real customer, real session, real card, real device history. Your fraud tooling sees a normal purchase. The chargeback arrives weeks later and it lands on you.

What does agentjacking have to do with PCI DSS?

PCI DSS does not mention AI agents, and it does not need to. The requirements that already cover your payment page are about what changes on it and who is allowed to change it. A hijacked agent is simply a new way for an unauthorized change to arrive.

If you complete SAQ A-EP or SAQ D, requirements 6.4.3 and 11.6.1 apply to you. Together they ask you to manage and inventory the scripts running on your payment page, and to detect unauthorized changes to it. An agent pushing an unreviewed change to that page is precisely the event those requirements exist to catch. Our guide to payment page script integrity walks through what they ask for.

If you complete SAQ A, those two requirements were removed in the January 2025 revision of the questionnaire (v4.0.1 r1, effective March 31, 2025). They were replaced by an eligibility criterion: you confirm your site is not susceptible to script attacks.

Read that sentence again, because you are the one signing it. If you do not know what code reaches your payment page or who can change it, that confirmation is harder to defend than it looks. This is the whole reason our position is that compliance is your call to make and our job is making sure you are not making it blind.

On scanning, quarterly external vulnerability scanning under requirement 11.3.2 stayed in SAQ A. For SAQ A merchants it applies to the systems hosting the page that redirects to or embeds your processor's payment form, and for SAQ A-EP and SAQ D it has always applied. Check your acquirer's contract too. Processors often require scanning regardless of questionnaire type.

But be clear-eyed about what a quarterly scan does. It examines your externally reachable systems four times a year. It was never designed to catch a script that changed on a Tuesday afternoon. The distance between quarterly scanning and continuous change is exactly the space agentjacking operates in.

What should a store owner do about agentjacking this week?

Four things, none of which need a security team or a budget. Ask your developer which AI agents touch your store, find out whether your error-reporting key is exposed, get a current list of what runs on your payment page, and turn on alerts for when that page changes.

1. Ask your developer or agency three questions. Do you use AI coding agents on our store, and which ones? What outside tools are those agents connected to? Does a human approve before an agent runs a command or ships code?

The third question is the one that matters. Human approval before execution is the top item on the researchers' own mitigation list, and it is the step that breaks the chain.

2. Find out whether you use Sentry, and whether the key is exposed. Error reporting is standard in e-commerce front ends, so the answer is often yes. Your developer can check in a minute. If the agent connection to it is not needed, switch it off. If it is needed, rotate the key and route reports through your own server instead of straight from the browser.

3. Get a current inventory of what runs on your payment page. You cannot notice a change to a list you have never seen. Our free Webpage Security Checker shows the scripts and security headers on your checkout in about a minute, with no signup.

4. Set up change alerts on your checkout. A hijacked agent's change looks legitimate the day it lands, because structurally it is legitimate. What gives it away is that it was not there yesterday. WooCommerce owners can install our free, open-source Checkout Script Monitor plugin to keep a running record of every script on the checkout.

One more, for the medium term. Decide your position on shopping agents before they drive real volume through your store, and ask your processor now what fraud liability looks like on an agent-placed order. That answer is worth having in writing before you need it.

How is CyberShield Studio handling this?

We do not have an agentjacking product, and we are not going to invent one to match a headline. Three things did change.

We added agent access to the Checkout Deep-Dive. When we review a payment page, "who can change this" now explicitly includes AI agents in the deployment path and the outside tools those agents connect to. Almost no merchant can answer it without going back to their developer.

Checkout Script Monitor stays free and open source. It records what runs on your checkout and flags changes, and it does not care whether a human or an agent made the change. The code is public on GitHub, maintained under a named CISSP and PCIP byline, which is the standard we would want applied to anything running on our own checkout.

Continuous payment-page monitoring is the premium tier of our readiness platform. Script monitoring with tamper-evident change records, so a change on your payment page produces an alert and an evidence trail. We monitor and alert. You decide what to do about it. That division is deliberate, because the merchant always owns the risk decision.

The method underneath all of it: AI does the legwork, our experts validate, you make the calls. Thirty-plus years in payment security and a CISSP and PCIP behind the validation step.

And yes, we run AI agents ourselves, under exactly the rule this article recommends. A human approves anything that ships. Writing about an attack on agents while letting agents ship unreviewed code would be a strange way to run a security practice.

If you want a person to look at your actual checkout and tell you who can change it, the Checkout Deep-Dive is a one-time review in plain English. If you would rather start on your own right now, run the free Webpage Security Checker against your checkout URL and see what is actually there.