Safety model
The useful question about an agent with access to a business is not what it can do — it is what it cannot do, and how that is guaranteed.
Money is never exposed
There is no refund tool, no mark-as-paid, no payout, no capture, no plan-billing and no payment-provider configuration. Not gated — absent. An agent cannot move money because the capability does not exist in the surface.
This is enforced by test, not by policy. The test suite asserts that no registered tool name matches refund, mark_paid, payout, charge, capture, settle, plan_billing, provider, mfa or domain. Adding one fails the build.
Layered refusal
Each layer is independent, so no single mistake opens the door:
- Gate — a write tool refuses unless its consent switch is on.
- Session — with the gate on, an unauthenticated caller still gets Not logged in.
- Scope — with a session, every query is explicitly scoped to that merchant’s store.
- Database — underneath all of it, row-level security and the platform’s own guards.
Reversibility informs the gating
Order actions sit behind their own gate because they are customer-facing and mostly irreversible — a cancelled booking has already emailed someone. Draft content is ungated because a bad draft costs a click to discard.
What it means for you
You can hand an agent the read surface with very little thought. Enabling commerce or operations is a real decision about a real business, and the docs treat it that way.