Shopify Sidekick Prompt Injection: You Hold Zero of the Six Controls

No public advisory describes a prompt injection vulnerability in Shopify Sidekick. No CVE, no disclosed bounty report, nothing in the record as of publication.

That answer is accurate and close to useless. A better question is who would find out, and how.

Sidekick is a write-capable assistant that calls functions against Shopify’s admin APIs, reads store data, and reads content written by people outside the merchant’s organisation. Everything about that shape says the interesting failure is a coerced action rather than a broken boundary. And the party holding every control that would catch a coerced action is Shopify.

So this piece scores Shopify’s own published principles against the attack they exist to stop, and hands you the same scoring pass for the agents you built yourself.

No One Has Disclosed a Sidekick Flaw, and That Tells You Nothing

Shopify runs one of the better-funded bug bounty programmes in commerce, with a stated maximum award of $200,000 and thousands of resolved reports. The absence of a published Sidekick injection finding is not the absence of scrutiny.

It is also not evidence of anything useful, because of what the finding would have to look like.

A classic vulnerability leaves an artifact a researcher can hold up: a request that should have been rejected, a token that reached a scope it was not issued for, a page that rendered attacker markup. Prompt injection against a write-capable agent produces none. The agent authenticates correctly, calls a function it is registered to call, and writes a value inside the range it is allowed to write. What makes it an attack is that the instruction came from a supplier document rather than the merchant, and that fact lives nowhere in the call.

The UK’s National Cyber Security Centre states the property plainly, arguing a language model is best read as an inherently confusable deputy with no parameterised-query equivalent waiting to be found. Confusable deputies produce authorised actions with the wrong reason behind them, which puts this in the class of attacks whose evidence is a sequence.

Detecting it requires comparing what the agent did against what that agent normally does. For Sidekick, one organisation is positioned to make that comparison, and it is the same organisation that would be issuing the advisory.

Shopify has been unusually direct about what good looks like here.

Shopify’s Six Principles Read as a Custody Map

On 19 August 2026 Shopify published six foundational principles for agentic AI security: enforce least privilege access, create thresholds for human oversight, secure the action layer, monitor agent behavior continuously, establish zero trust between agents, and validate agent inputs and outputs.

The guidance is sound and specific. It is also worth reading for something other than its advice, because each principle carries two properties the text does not name: the moment it binds, and the party that holds it.

Sort them by moment and they separate cleanly. Least privilege and action-layer hardening bind at configuration time. Zero trust binds when one agent receives a request from another. Input and output validation binds at ingress and egress. Human approval binds when an action is proposed. Only continuous behavioral monitoring binds during execution, against a record of how the agent has behaved before.

Sort them by holder and they do not separate at all. For Sidekick, Shopify sets the permission scope, hardens the action layer, defines the approval thresholds, operates the screening, and runs whatever behavioral monitoring exists. The merchant clicks approve.

One line in the sixth principle deserves attention on its own. Shopify names the untrusted inputs explicitly: every customer message, product listing, supplier document, and third-party data source an agent receives is a potential risk. That is the platform stating, in its own copy, that the content flowing through a commerce agent is attacker-reachable, which is the precondition every one of the documented indirect injection incidents needed before anything else could happen.

Score Them Against a Coerced Agent and Only One Moves

Coercion is the case where trusted content redirects an agent’s authorized capability. The agent reads a supplier document, follows an instruction buried inside it, and calls a tool it is permitted to call with an argument nobody sanctioned. No credential is stolen. No permission boundary is crossed. Every step passes every check, and the sequence is the attack. How the instruction arrived stops mattering at that point, since the direct and indirect distinction expires at the context window and what follows looks identical either way.

Run the six against that:

Shopify principle	When it binds	Who holds it for Sidekick	Survives a coerced action?
Enforce least privilege access	Configuration	Shopify	Yes. The action uses permissions already granted.
Create thresholds for human oversight	Action proposed	Shopify sets, merchant approves	Yes. The proposed change resembles what was asked for.
Secure the action layer	Configuration	Shopify	Yes. One in-scope write clears rate limits and token scoping.
Monitor agent behavior continuously	Execution	Shopify	No. Deviation from the agent’s own baseline is the signal that changes.
Establish zero trust between agents	Request received	Shopify	Yes. Single-agent flows never trigger it.
Validate agent inputs and outputs	Ingress and egress	Shopify	Mostly. Screening is probabilistic and a coerced output falls in bounds.

Five of six stay green.

They stay green because five of the six are asking whether the agent is permitted to do the thing, and in a coercion the answer is always yes. Permission was settled at configuration time. The attack happens at execution time, using the settlement.

The sixth row earns its qualifier. Input screening is a scored judgment with a threshold behind it, and whether a given classifier is worth trusting comes down to three measurements most teams never take. A merchant cannot take them for Sidekick at all.

The one row that moves is the fourth, and Shopify’s own phrasing for it is precise: compare agent activity against established behavior baselines and alert when agents deviate from expected patterns. That comparison is the only one of the six that consults a record of the past rather than a rule about the present. It is also the only one a merchant can neither configure, inspect, nor evidence. The row that moves is the row you do not hold.

For agents you do run, the telemetry that makes this comparison possible is worth understanding in its own right, and we have previously worked through what a coerced agent leaves behind at runtime, stage by stage.

The Approval Screen Confirms the Action and Says Nothing About the Reason

The strongest objection to all of this is sitting in Shopify’s own documentation, which states that Sidekick presents changes for the merchant’s review before applying them. A human sees the proposed write. Principle two is satisfied by a person, and people are harder to inject than models.

Take that seriously, because for a large class of mistakes it works. An agent that hallucinates a nonsense price gets caught by the person clicking approve.

Coercion is a different shape. The instruction inside the poisoned document is written to produce a plausible action, and the approver has no reference behavior to compare it against. They see a discount code being created, a shipping rule being edited, a metafield being updated. They do not see that this agent has never touched shipping rules in four months of operation, because that history is not on the screen and was never offered to them. Approval confirms the action. The reason behind the action stays invisible, and the reason is the entire attack.

That failure has already been measured in a neighbouring setting. In the published tool-poisoning benchmark work, the approval prompt fired on a tool the user’s own request invoked while a separate, already-approved tool completed the damaging call.

There is an honest concession here, and it cuts toward Shopify. For a hosted assistant, the vendor is genuinely better placed to run behavioral monitoring than any individual merchant could be. Shopify sees Sidekick’s behavior across millions of stores, which is a far richer baseline than one merchant would ever build. The problem is not competence. The problem is that the merchant cannot verify the control exists, cannot tune it, and cannot produce evidence about it when an auditor asks. Custody and competence are separate questions, and only one of them shows up in a risk register.

You Are Not the Merchant in This Story

If you are reading this as a security or platform engineer, the constraint that makes Sidekick opaque does not apply to you. You are not buying the Sidekick-class agent. You are building it.

That class is easy to recognise once you look for the shape rather than the vendor. It has write scope on a system of record. It calls functions rather than returning text. And it reads content authored by people outside your organisation: support tickets, vendor invoices, scraped pages, inbound email, pull request descriptions. Shopify’s sixth principle lists almost exactly this set, which suggests the shape generalises past commerce. What the agent does next with a legitimate capability is the whole exposure, and an authorized tool turned against its own purpose leaves a permission layer with nothing to object to.

The good news is that every one of the six principles becomes reachable when you own the infrastructure the agent runs on. Five of them were always reachable, since they are configuration decisions. The fourth becomes reachable too, and it becomes reachable in a way it never is for a hosted agent: from below the agent, at the kernel, where what the process actually did is visible regardless of what the agent believed it was doing.

That distinction matters because a coerced agent reports its own activity faithfully. It is not lying. It genuinely thinks the instruction was legitimate, which is why a log line written by the agent’s own process is a claim the agent is making about itself rather than evidence about it. Any monitoring that trusts that account inherits the coercion, which is why per-agent behavioral policy has to be derived from observed runtime activity rather than written by hand.

The design-level answer stops short for the same reason. The published patterns for constraining agents are worth adopting and they leave a documented residue in almost every case study their own authors work through. Design narrows the opening. Something still has to watch inside it.

Score Your Own Agents on Set, Observe, Notice

Take the six principles and give each one three columns.

Set. Did you configure this control deliberately for this agent, or did it inherit a namespace default? Most teams pass on principles one, three, and six and discover that principle five was never considered because the multi-agent topology arrived after the security review.

Observe. Can you watch this control fire? Not whether it is enabled: whether you have a record of it acting. Least privilege that has never denied anything is indistinguishable from least privilege that is scoped too wide.

Notice. Would you know if it stopped working? A screening classifier that silently starts passing everything looks exactly like a screening classifier with nothing to catch.

The failure signature is an empty Observe column on principle four. An agent in that state is being trusted rather than secured, which is the state a merchant is in with Sidekick, reached by a different route. NCSC’s agentic guidance lands in the same place from the regulator’s side, treating safeguards, sandboxing and active oversight as a set that runs together rather than alternatives you choose between.

Filling that column requires a behavioral record per agent rather than per workload type. ARMO builds one from kernel-level observation, which it maintains as the Application Profile DNA (APD™) for each agent: the processes it runs, the files it touches, the destinations it reaches, the identities it uses. Deviation from that record is what surfaces a coerced action, since the action itself is authorised and will not trip anything else. This is the layer that has to hold when everything placed upstream of the decision has already been passed.

Arming it without breaking production is the part teams get wrong. Blocking on a baseline you do not trust yet takes down the agent, so enforcement runs in two stages: Audit first, where deviations are recorded and nothing is stopped, then Enforce once the policy has proven safe against real traffic. The progressive enforcement path covers how that promotion decision gets made, the kernel-level mechanics cover what the sensor sees on its own, and every agent ships with an interval before its baseline is settled enough to enforce against. Regulated teams have a narrower path for agents where that interval is itself a finding.

One control deserves accurate scoping. Credential isolation, where the agent holds placeholder keys and the real secrets are swapped in outside the agent’s reach, narrows what a coerced action can carry away. It does not prevent the coercion, and it does not help when the damaging action is a write to a system the agent is supposed to write to. Score it under principle one, where it belongs, and keep expecting principle four to do the catching.

Custody Decides What You Can Prove After the Incident

The vulnerability question sits downstream of the custody question. For any agent, establish first which controls you hold, which of them bind before the agent runs, and whether anything is watching during execution. Once that map exists, the presence or absence of a published advisory stops carrying weight it was never able to carry.

Shopify’s six principles are a good list. Score them honestly against your own agents and most teams find five configured and one unstaffed.

ARMO’s runtime behavioral layer for AI workloads exists to staff that row. Watch a demo to see what a write-capable agent looks like when it stops behaving like itself.

FAQ

Is Shopify Sidekick vulnerable to prompt injection? No public advisory or CVE describes a prompt injection vulnerability in Sidekick as of publication. That said, Sidekick reads content that people outside the merchant’s organisation can author, which is the precondition for indirect injection, and Shopify’s own security guidance names product listings and customer messages as untrusted inputs. The accurate position is that the risk class applies and the specific record is empty.

Can I monitor what Sidekick does inside my store? Not at the level that would catch a coerced action. Shopify Admin surfaces the changes Sidekick proposes and applies, which is an action log. It is not a behavioral baseline, so you cannot tell whether a given action is unusual for that assistant. The instrumentation that would answer that sits inside the runtime, which for a hosted agent belongs to the platform operator.

Does requiring approval for agent actions stop prompt injection? It stops the obvious failures and it is worth keeping. It does not stop coercion, because a coerced agent proposes a plausible action and the approver has no record of the agent’s normal behavior to judge it against. Treat approval as a control against error, and pair it with behavioral monitoring for anything that writes to a system of record.

Which of the six principles should I implement first for my own agents? Least privilege and the action layer, because they are configuration decisions you make before the agent ships and they bound the worst case. Then behavioral monitoring, the only one that fires during execution and the only one that catches an attack using permissions you already granted. Sequence the rest against which techniques your stack can actually detect, and move zero trust between agents up the moment you run more than one agent that can call another.

How do I tell whether a hosted AI agent is safe to connect to production data? Ask three questions: what behavioral monitoring runs on the agent, what evidence of it you can retrieve, and what the agent’s write scope is on your data. Prompt-layer screening is the usual answer to the first, so know what that layer can and cannot resolve on its own before accepting it. If the first two answers are unavailable, you are accepting the agent on trust, which may still be right. Scope the write permissions to match, and keep it away from anything you would need to prove was not altered.