Is it safe to give AI write access to Shopify?

Giving an AI assistant write access to your Shopify store is a decision about three things: how much the assistant can reach, how much Shopify remembers about what it did, and who stands between a draft and a live page. Most advice stops at the first. This post covers all three, using Shopify's own documentation and the security guidance written for AI applications.

The short version is that read access and write access are different in kind. Read access answers questions. Write access changes what customers see and pay. Shopify gives you good tools to see who did what, and few tools to put things back.

What a write scope lets an app change

Every app that connects to Shopify declares access scopes, and you approve them when you install. Shopify's developer documentation sets out the rule in one sentence: any scope that writes a resource also grants read access to it. So there is no such thing as write access without the ability to read the same data.

The scopes are grouped by resource, and the groups are wider than you might expect. The write_products scope covers Product, ProductVariant, Collection and ResourceFeedback objects, along with related selling plan objects. An assistant that you only want to rewrite descriptions has, under that scope, the technical ability to change variant prices and edit collections too. The scope names do not separate the two. What stops it is whatever rules the app builder wrote on top, and that is a promise by the app, not a limit enforced by Shopify.

The theme row is worth a second look. Shopify's documentation says most apps that integrate with a theme should use theme app extensions rather than ask for write access to the theme itself. If an assistant asks for write_themes to do something an extension could do, that is a reason to ask why.

The documentation also says Shopify grants some access scopes to individual apps rather than to every app that declares them, and that certain restricted scopes need Shopify approval before a developer can declare them. That is a screen on the developer side. It does not tell you how a particular app behaves once installed, so the screen that matters is the permission list you see when you install.

• 60 days

  how far back read_orders and write_orders reach by default

  Shopify developer documentation, access scopes, 2026

• 250

  most events the store activity log will display

  Shopify Help Center, activity logs, 2026

• 3

  causes OWASP gives for excessive agency in AI applications

  OWASP, LLM06 Excessive Agency, 2025

What Shopify keeps, and what it does not

When a change lands, you want two things: a record that says it happened, and a way back. Shopify supplies the first in a limited form and the second for some things only.

The store activity log shows the date and time of recent actions taken by the store owner or a user in your admin, with the name of the person, app or channel that took each action. That last detail is useful, because it separates what you did from what an app did. The limits are in the same help page. The log displays a maximum of 250 results, and the time period that covers depends on how active your store is. A busy store that runs a bulk edit and then a large import will push earlier events out of view. The page also says the log is view only, that you cannot expand or click individual events, and that the information cannot be exported.

A log that you cannot open an event in tells you that something happened. It does not tell you what the old value was. For that you need version history, and for product fields Shopify has none. A reply in a Shopify community thread on reverting a product description puts it directly: Shopify keeps no version history for product fields, so the old description is gone from the admin the moment the new one is stored. Before you save, Ctrl+Z still works in the description editor. After you save, it does not.

Orders are different. The order timeline records the detailed history of each order, and staff can add internal notes and comments to it. Comments can be edited for 5 minutes after posting. That makes orders the best documented object in the admin and products among the worst, which is the wrong way round if the thing an assistant is most likely to edit is a product.

The risk is called excessive agency

OWASP, the open security foundation best known for its web application risk lists, publishes a separate list for applications built on large language models. Entry LLM06 in the 2025 edition is called Excessive Agency. It describes what happens when an AI system is given the ability to call functions or interface with other systems, and then does something damaging because its output was unexpected or manipulated.

OWASP gives three root causes. The first is excessive functionality: the system can reach more capabilities than its purpose needs. The second is excessive permissions: an extension runs with broader rights than required, and OWASP's example is an assistant holding DELETE permission when it only needs to select data. The third is excessive autonomy: the system fails to independently verify and approve high impact actions before they run.

The triggers OWASP lists are ordinary. A hallucination in response to a benign prompt can cause it. So can a direct prompt injection attack, and so can a compromised extension in a setup where several agents work together. For a Shopify merchant the injection case is the one to picture: a product page, a customer message or a supplier file contains text written to look like an instruction, and an assistant with write access treats it as one.

The mitigations OWASP lists map neatly onto the Shopify scope list above. Minimise the extensions and functions an assistant can reach. Give it the narrowest permission that does the job. Require user approval for high impact actions. And implement authorisation in downstream systems rather than relying on the model to decide whether an action is allowed. OWASP's own example scenario is a personal assistant with email access: read only OAuth scopes and mandatory user approval for sends would have prevented the exfiltration.

In Shopify terms, downstream authorisation means the checks that sit in Shopify itself, such as staff permissions and the scopes you granted. An app that promises to behave is less safe than one that cannot misbehave because the token it holds lacks the scope.

People, payments and the accounts around the store

An assistant is one of several things that can change your store. Staff accounts and partner access are the others, and the same questions apply to them.

Shopify's account security guidance says each user accessing the store should have a unique staff account with specific permissions, rather than shared credentials. It says two step authentication helps prevent security breaches that can lead to misdirected payouts and other financial losses, and that it is required to use Shopify Payments.

Shopify marks a small set of staff permissions as sensitive. At store level these are Customers, Request data, which handles GDPR style data requests; Finance, Edit billing payment methods and pay invoices; and Finance, Manage other payment settings. Shopify's page tells you to assign these only to your most trusted users. The same logic applies to anything that acts for you. An assistant has no use for permission to change payment settings, and a connection that offers it should be declined.

Collaborator accounts are the route Shopify Partners use, such as agencies and freelancers. Shopify says collaborators are Partners you have allowed to access your store. They need a request code from you, which you provide, and you then accept the request in your admin. Partners must activate two step authentication to use a collaborator account. When you approve access you can assign permissions for specific apps and channels, and you can create roles for collaborators with the permissions they require. Collaborators cannot access the Shopify POS app or the Point of Sale channel, and you cannot transfer store ownership to one. You can remove a collaborator account permanently, and Shopify warns that you cannot undo that action.

An agency with a collaborator account and a connected assistant sit side by side in the activity log. If both have write access to products, a bad edit has two plausible authors, and the log entry gives a name or an app, nothing more.

A worked example with the numbers above

Take a store with 300 products and an assistant holding write_products. You ask it to tidy the titles. It does the job, and it also, through a misread instruction, trims the first line from every description. Nothing in Shopify stops that, because the scope covers the whole product object.

Now look for the damage. If each product edit appears in the activity log as its own event, which is how the log is described when it lists recent actions by person, app or channel, then 300 edits exceed the 250 results the page can display. The earliest edits in that run have already dropped out of view, along with whatever you did the day before. You cannot click into an event to see the old value, and you cannot export the list to keep it. The old descriptions are not in Shopify at all, because product fields have no version history.

The way out is a CSV export taken before the run, which Shopify's export page says includes titles, descriptions, variants, pricing and inventory. Re importing it overwrites products, so it is a repair of last resort rather than an undo. Shopify's CSV import help says a blank cell in an included column overwrites the matching value with blank, which is why a repair needs the same care as the original change.

Checks to run before you grant write access

Write access is fine to grant, on terms that match what Shopify keeps and forgets.

• Read the scope list at install. If the assistant needs to draft descriptions, check whether it asks for write_orders, write_customers or write_themes too, and say no to scopes it cannot explain.
• Export your products to CSV before any bulk change. Shopify's export page says the file holds titles, descriptions, variants, pricing and inventory, and that images are not included.
• Look at the activity log weekly rather than monthly. It holds at most 250 events, and on an active store the oldest fall away quickly.
• Keep sensitive permissions, payment settings and billing, with people rather than assistants.
• Ask the app builder what happens to a proposed change before you approve it, and what happens to one you never approve.

The last question matters because OWASP's third cause, excessive autonomy, is the one a merchant can test. Install the assistant on a small catalogue first. Ask it to change one description. See whether it writes at once, or shows you the old text and the new text and waits.

Where BYOM fits

Give an assistant read access freely. Give it write access only with a person on every change, a record of it, and undo on product edits. That is how the BYOM Shopify app and BYOM are built. In the BYOM Shopify app, every write is a proposal on a confirm card. You see what will change, then confirm it or skip it.