A thread on r/PPC asked people running AI tools with real write access to client accounts four questions: what did it get wrong, how do you handle governance, did it actually reduce hours, and what did you turn off after sixty days. The answers converged on something more useful than a tool recommendation — a list of controls.
This is that list, written so you can hold any vendor to it, including us.
The seven controls
1. A fresh read before the recommendation
An agent that plans from data it loaded ten minutes ago will confidently act on a state that no longer exists. The most common failure people report is not a bad decision — it is a confident wrong input: a field the API documents but returns as undefined on the edge the agent happened to query, silently treated as zero. Require that the read justifying a change happens in the same turn as the change.
2. A diff before the write, not a description of it
The agent's narration is not evidence. “I'll lower the bid on the underperformers” is a sentence. bid 1.40 → 0.95 on 3 targets is a diff. Only the second can be reviewed.
3. A blast-radius cap
The failure that costs most is rarely one wrong change. It is one wrong change applied to four hundred objects. Require a hard per-call limit on affected objects, enforced before the call — not by asking the model to be careful.
4. Human confirmation scoped to material changes
Confirming everything trains you to click through everything, and within two months you have an approval dialog that no longer approves anything. The gate has to separate a reversible edit from a money move.
5. Classification owned by the host, not the tool
If an action's risk level comes from the tool's own description, anything that can write a description can lower its own risk level. A tool that calls itself “update a small setting” must not be able to talk its way out of approval. Unknown or custom actions should default to sensitive, not to safe.
6. An audit trail you can hand to a client
The question is not whether events are logged somewhere. It is whether you can produce, on request, an immutable record of who changed what and when. Product telemetry is not that.
7. A rollback path, built before you need it
Every consequential action should carry a key that finds and reverses the batch it belongs to. Deciding how to undo something after it has gone wrong is how a bad hour becomes a bad week.
The failure none of these catch
Every control above governs execution. The diff tells you what changed, the log tells you who and when, the rollback undoes it. None of them separates a correct recommendation from a wrong one — both look identical going in, and the wrong one is often better argued.
There is a widely-read account from a seller running a healthy 3.5–4x ROAS who let a model talk them into restructuring campaigns, and lost money. The most-upvoted reply explains it: the model does not know your inventory position, contract constraints, or account history. As another put it, they don't know how to choose between two goods. Pattern-finding is where these models are genuinely strong. Deciding between two defensible strategies is not.
The second uncaught failure is thrashing: raise a bid on three days of data, cut it two days later, and the target never gets a stable read. Practitioners running this at scale force a five to seven day cool-down per target and report it fixed more than any model change did.
What Orkas covers today
Orkas is a local-first multi-agent desktop app. Its commerce connectors — Shopify, Amazon Seller Central, eBay, Etsy, TikTok Shop, Shopee, WooCommerce, Walmart and others — run through a host-owned policy layer. Eight of these are implemented and four are not. We would rather you find that here than after a bad write.
| Control | Status | What exists |
|---|---|---|
| Four-tier action risk model | ✅ | Every connector action is R / W / H / D — read, write, high-impact, destructive |
| Preview before a write | ✅ | Write actions carry a preview confirmation rather than firing immediately |
| Fresh confirmation on money moves | ✅ | High-impact actions are flagged as an external or financial change and require a fresh confirmation |
| Blast-radius cap | ✅ | A per-call limit on how many objects one action may touch, checked before the call runs |
| Pure read-only connection | ✅ | A connector can be limited to capability listing, action description and reads |
| Host-owned classification | ✅ | Risk comes from a fixed host table keyed on exact action identity; tool-supplied hints cannot widen trust |
| Fail-closed on unknown actions | ✅ | An unclassified action is treated as high-impact; a commerce action with no trusted policy is refused, not run |
| Product-boundary block list | ✅ | A fixed list of actions that are never exposed, regardless of granted scopes |
| Per-verb permissions (create / edit / pause separately) | ❌ | Permissions are graded by risk tier, not split by verb |
| Monetary spend cap or max budget-change percentage | ❌ | The cap is on object count, not on amount |
| Rollback path | ❌ | Not implemented. Reversing a batch is manual |
| Exportable immutable audit log | ❌ | Connector calls are tracked for telemetry; that is not a client-facing audit trail |
If the last four are hard requirements for you — most commonly when you manage ad accounts for clients who can demand an audit — Orkas does not meet them today, and you should keep a human on every write.
The other route: no write access at all
For a large share of the work, write access is not the point; analysis is. Export the report, put the file in a local workspace, and let the agent read it. No developer application, no approval queue, no write-scoped credentials in the loop. It also happens to be the fastest way to find out whether an agent is useful to you before granting it anything irreversible. Two worked examples: reconciling supplier tracking numbers against your orders and the weekly store review use case.
Why this is hard to buy rather than build
The platform APIs are usually free. The gate is the approval, not the price. Amazon's own Ads MCP server requires active Ads API credentials. Shopify requires a merchant-owned app in the same organization as the store. TikTok Shop requires a Custom App that has passed seller developer review. eBay requires a Developers Program production keyset and your own signing key. For a solo seller each of these is a project, not a form — which is why so many run the export route and never connect anything. That is a reasonable choice, and any tool worth using should work well in that mode too.