Amara was installing a meta-tag optimizer — a small, single-purpose tool, by its own description. On the install screen, Shopify did what Shopify always does: listed exactly what the app was asking to access. And for once, she actually read it.
View products. Edit products. Fine — that's the job. View inventory. Sure. Then: view orders. View customers. Edit theme code. Manage script tags. View analytics. Eleven permissions, for a tool whose entire pitch was rewriting title tags.
She hovered over the install button and asked the question this file is named after — why does it need all that? — and then did what every merchant does, because there's a store to run and the button is right there.
Here's the uncomfortable truth about that screen: it is the single most honest document in the entire app relationship. Sales pages describe intentions. Support docs describe features. The OAuth consent screen describes capability — the complete, enumerated list of what the app will be able to do to your business, from the moment you click until the day you revoke it. It's also the only contract nobody reads.
This is the last file in the trust block — measurement, fixable, reversible, and now: how much of your business a tool should be allowed to touch at all.
Scopes are capability, not behavior
The mental model that makes everything else obvious: a scope grant is not a description of what an app does. It's a standing authorization of what it can do — every hour of every day it stays installed, regardless of what the marketing said, regardless of feature changes shipped after you installed, regardless of who acquires the vendor next year.
That last clause deserves a beat. Apps get sold. Teams change. A grant you made to a bootstrapped tool in 2024 belongs to whoever owns that OAuth client in 2027. You aren't trusting an app; you're trusting a permission set across every future state of the company holding it. Which is why the only sane policy is judging the grant, not the vendor's vibes.
Scope literacy: what the big ones actually hand over
Shopify's scopes are named politely. Here's what the common ones grant in operational terms:
read_products / write_products — read the catalog; perform surgery on the catalog. Write access to products is the power the rollback file exists for: titles, descriptions, prices-adjacent data, the records machines quote. Legitimate for any tool that fixes catalogs; consequential enough that it should never travel without the rollback standard.
read_inventory — stock truth. What a tool needs to bind availability to reality instead of hardcoding it.
read_orders — your revenue, order by order. Volumes, values, velocity, what sells with what. This is your P&L's raw material, and for most catalog tools it is none of their business.
read_customers — names, emails, addresses. Personal data belonging to your buyers, not to you to hand around. Shopify gates the most sensitive of it as protected customer data for exactly this reason. A scope here means a vendor breach is now your customers' breach.
write_themes — edit the code of your storefront. Not content: code. A tool holding this can alter anything your theme renders, inject whatever it likes into every page, and change surfaces adjacent to checkout. It is among the most powerful grants on the platform, routinely requested by tools whose job is text.
Script tags — inject JavaScript onto your storefront pages. Everything the delivered-layer file warned about, as a permanent third-party privilege — plus tracking capability over every visitor you have.
None of these is illegitimate per se. Each is legitimate exactly when the job requires it — which is the whole doctrine in one sentence.
FIG.02 — What the polite names grant. Operational terms, not marketing terms: none is illegitimate per se, and each is legitimate exactly when the job requires it.
Least privilege: derive the scopes from the job
Security people call it the principle of least privilege: grant the minimum capability the task requires, nothing more. Apply it to catalog legibility work — the entire discipline this series describes — and the derivation is short:
The job is: read the catalog (to audit what exists), write the catalog (to fix what's fixable, under the rollback standard), and read inventory (so availability claims are true). That's the job. Roughly three grants.
Now the other side of Amara's screen. What does catalog work not require? Your order history. Your customers' identities. Your theme's code. Your analytics. Script injection into your storefront. Every one of those grants, on a catalog tool, is capability without a corresponding task — and capability without a task has a name in security thinking: blast radius.
Three blast radii, specifically. Breach exposure: when the vendor is compromised — a when, like being wrong is a when — the attacker inherits the grants, and the difference between "they read some product descriptions" and "they exfiltrated my customer list" was decided the day you clicked install. Data exit: broadly-scoped tools ingest data the job doesn't need because data is valuable — for training, for benchmarking, for resale-adjacent "insights"; your order flow becomes someone else's asset. Incentive drift: a vendor whose business model needs your data hungers for scopes; a vendor whose business model is doing the job asks for the job's scopes. The consent screen is where the business model shows.
So here's the standard, stated the way the previous files stated theirs: a tool's requested scopes should be derivable from its stated job, one by one, with no remainder. Ask for the derivation. A serious vendor can produce it in five lines. An unserious one will explain that broad access "enables future features" — which is precisely the problem, phrased as a benefit.
FIG.03 — Capability without a task is blast radius. When the vendor is breached — a when — the attacker inherits whatever you granted.
The fifteen-minute audit: read what you've already signed
You've probably granted more than you remember. Shopify shows you everything:
STEP 01 / INVENTORY THE GRANTS. Admin → Settings → Apps and sales channels → open each installed app → view its permissions. Write down every scope next to the app's actual job. Fifteen apps takes about ten minutes and is reliably horrifying.
STEP 02 / RUN THE DERIVATION TEST. For each app: can every scope be derived from the job? Products scopes on a catalog tool — derivable. Customers on a review app that emails buyers — derivable. Theme code on a keyword tool — no derivation exists. Mark the remainders.
STEP 03 / PRUNE. Uninstall what you don't use — dormant apps keep their grants, and a dormant grant is pure blast radius with zero benefit. For apps you keep but whose scopes exceed the job, ask the vendor the questions from the rollback file, plus this file's: derive each scope from the job for me. Then check what uninstalling actually removes — and remember Shopify requires apps to purge shop data after uninstall via mandatory webhooks, which is a floor, not a guarantee of grace.
STEP 04 / ADOPT THE POLICY GOING FORWARD. New installs: read the screen, run the derivation, and treat any unexplained remainder as the vendor answering your question in advance.
FIG.04 — Read what you've already signed. Fifteen minutes in admin, and the standard at the bottom: derivable from the stated job, one by one, with no remainder.
We publish this standard for the same reason we published the last three: we intend to be measured by it. Minimal footprint isn't a feature we bolt on — it's the discipline of asking, for every scope, does the job require this? — and declining the ones where the honest answer is "no, but it'd be nice to have." Your customer list is not nice-to-have material. Nothing about catalog legibility requires knowing who your buyers are, and a tool that says otherwise has told you what it's actually for.
One piece of the trust standard remains, and it's the subtlest: a tool with minimal scopes and full rollback still writes words into your records — and what it's allowed to write, versus what it's allowed to invent, is the line the whole AI-tooling industry is currently getting wrong. That's the next file.
Sources & further reading
- Shopify — API access scopes (the full vocabulary): https://shopify.dev/docs/api/usage/access-scopes
- Shopify — Protected customer data requirements: https://shopify.dev/docs/apps/launch/protected-customer-data
- Shopify — Mandatory webhooks and data deletion on uninstall: https://shopify.dev/docs/apps/build/privacy-law-compliance
- IETF RFC 6749 — The OAuth 2.0 Authorization Framework (what a grant is): https://www.rfc-editor.org/rfc/rfc6749
- Rank Sniper Field Notes — FILE 02: /blog/ai-agent-declared-vs-delivered-product-page · FILE 04: /blog/product-attributes-ai-systems-refuse-to-guess · FILE 06: /blog/ai-visibility-score-eligible-implemented-weighted · FILE 07: /blog/fixable-should-mean-fixable-store-audits · FILE 08: /blog/fixed-it-for-you-needs-versioned-rollback
Rank Sniper — Field Notes. Catalog legibility and AI-visibility verification for Shopify. We verify what AI agents actually receive from your store; we don't generate content and hope. Verifier, not generator.
