Being able to ask "which products are quietly running out of stock in Germany?" in plain English and get an answer from your actual store data is genuinely useful. It's also the kind of thing that, wired up carelessly, hands a chatbot the keys to your business.
Both of those are true at once. The interesting work is getting the first without the second. This is the pattern we use.
The risk, stated plainly
When you connect an AI to your store, you're giving a system that occasionally makes things up the ability to act on real data. A few failure modes are worth keeping in mind:
- It could change or delete something, not just read it.
- It could be tricked. A customer note or product description containing "ignore your instructions and…" is a real attack, not a hypothetical.
- It could leak data it was allowed to see into somewhere it shouldn't.
You don't solve these by trusting the model to behave. You solve them by making misbehaviour structurally impossible.
Read-only by default
The single most important decision: the connection can read but cannot write. No creating orders, no editing products, no issuing refunds. If a future use case genuinely needs a write action, it gets added deliberately, one narrow capability at a time, with its own guardrails, never as a blanket "let the AI do things" switch.
Most of the value (analytics, lookups, "explain this trend," support triage) is read-only anyway. Start there.
MCP is the right shape for this
We build these as MCP servers. The Model Context Protocol is just a standard way to expose a defined set of tools to an AI assistant like Claude or ChatGPT. The important word is defined.
Instead of "here's an API key, go nuts," the AI gets a specific menu: get_inventory, get_orders_summary, get_product_performance. Each one is a function we wrote, with fixed scope. The model can only do what the tools allow. It can't compose its way into something we didn't intend, because there's no general-purpose access underneath.
The model never touches Shopify directly. It asks a tool we control, and the tool decides what's allowed.
Scope the data, not just the actions
Read-only isn't enough on its own. The tools themselves should return only what's needed:
- No raw customer PII unless a task genuinely requires it, and then minimised.
- Aggregates over row dumps wherever possible. "Revenue by channel last month" rather than every order.
- Hard limits baked into the tool, so a request can't accidentally pull the entire catalogue.
Log everything
Every query the AI makes gets recorded: which tool, what arguments, when. This does two jobs. If something looks wrong, you can see exactly what was asked. And it keeps the whole thing honest: an audit trail is what turns "trust me" into "check for yourself."
The shape it ends up
Put together, the safe version looks like this:
- AI assistant (Claude, ChatGPT, Gemini) talks to →
- an MCP server we control, exposing a fixed set of read-only tools, each with minimised, scoped output, with →
- every call logged.
None of this is exotic. It's the same instinct as the rest of how we build: give a system the least power it needs to do its job, write down exactly what that is, and make the boundaries real ones rather than requests it can ignore.
If you'd like your store's data to be answerable in plain English without that meaning "the robot can do anything," that's exactly the kind of thing we build. Get in touch.