Mako proposes. You approve. Then it re-reads the platform to prove what changed.

Section 02 · the three gates

Three gates stand between the agent and your money.

A proposal left sitting is refused after 24 hours, because the numbers on the card describe a moment that has passed. Ask again and the account is read afresh before anything is proposed.

Section 03 · everything it can change

Fourteen changes. That is the whole list.

Where this stands today. Google Ads, GA4, Merchant Center and Search Console are the ordinary controlled-beta connections. Google Ads money-affecting changes remain supervised and require approval of the exact action. Meta remains reviewer-only during app review. Merchant Center publishing is restricted to supervised validation, and neither write path is a general-availability promise.

Section 04 · blocked in code

Some things it is not allowed to propose at all.

Section 05 · per-platform permissions

Exactly what each connection is allowed to see.

We ask for the narrowest permission each platform offers for the job. Where a platform publishes no read-only option, we say so instead of implying one.

1. Meta. Where the connection runs through Facebook Login for Business, the permission set is decided by a configuration in our Meta app rather than by our code, and Meta shows you that set on the consent screen. The three permissions above are what we ask for. The consent screen is the authority on what you actually granted, and we will not tell you otherwise.
2. Google. Google can carry forward scopes granted to the same OAuth client in an earlier consent. We store what Google reports back rather than only what we asked for, so our record never understates what a stored credential can do. Each Google connect flow requests only its own scope: Ads, Merchant Center, Analytics and Search Console are four separate consents.
3. Shopify. We deliberately do not request read_all_orders, the protected permission that would let us read orders older than 60 days, because the reporting gain does not justify the access. A store's effective permissions are also bounded by the app configuration Shopify shows you at install, and some stores granted a wider set there than the four above. What bounds the reads is the code: no Shopify customer, line item or fulfilment endpoint is called anywhere in it.
4. TikTok. These are the names TikTok uses in its own developer portal, where an app's permission set is fixed when TikTok approves the app. Our authorize request sends no scope parameter at all, so unlike every other row in this table there is no permission string in our code to hold them against, and we have written them plainly rather than dressing them as code. TikTok reports the granted set back as numeric ids and we store what it reports. Its own consent screen shows you what you are granting before you approve, and that screen is the authority. The three read rows were the whole set until 2026-08-18, when TikTok approved the second application we made on 2026-08-17 and the six management rows were added. We asked for a narrower set than TikTok offers and the exclusions are deliberate: no TikTok Shop, no GMV Max, and no Automated Rules, because nothing here writes without your approval and a permission for unattended changes would contradict that. Every management row is granted and called by nothing, apart from campaign creation, which is switched off. The reporting permission was widened in the same approval and the code still calls only the consolidated report named above. One more thing worth saying plainly: TikTok publishes no map from those numeric ids to these names, so we cannot check the grant against this table in code the way we can on every other platform, and the permission check in front of every TikTok write refuses for exactly that reason.

What customers can use today. Google Ads, GA4, Merchant Center and Search Console are the ordinary controlled beta connections today, each with production evidence pending. Meta Ads remains reviewer-only during app review. TikTok Ads is not an ordinary beta connection; it remains limited to supervised validation. Shopify accepts existing installs only while its distribution review continues. Merchant Center publishing stays under supervised validation behind the write switch. Code described elsewhere on this page does not widen those customer-access limits.

Section 06 · the audit trail

Every change leaves a record you can read back.

Every change is one row in our database, written as the change moves through its states. This is what the row holds.

The states a change can be in

The record holds who approved it. It stores when a change was approved and which signed-in person pressed the button, not only which account. The column was added before seats existed, on purpose: adding it afterwards would have left every change approved before that day with no answer, and a gap in the record cannot be backfilled honestly. It also survives the person. Removing somebody from a workspace does not touch what they approved, because the record has to outlive the membership. A proposal that expires because a newer one replaced it carries no approver, because nobody approved it.

There is no undo button. For a budget move across two entities, a failed second leg puts the first back automatically and re-reads to confirm it landed. For a single budget or status change that already succeeded, reversing it means proposing the opposite change and approving that too. There is no rollback route in the product, and no automatic retry. We would rather say that than ship a button that sometimes cannot deliver.

Section 07 · where your data lives

Where your data sits, and the six companies that touch it.

The application runs on Vercel. The database is Neon Postgres, hosted on AWS in US East. Traffic travels over TLS. Sable Mako is operated by Champ X Digital FZ LLC, a company registered in the United Arab Emirates, and our own staff access is from there.

Section 08 · AI and your data

We do not train models on your data.

Section 09 · how credentials are stored

Your platform tokens, and what protects them.

Section 10 · what we never collect

Things we deliberately never pull.

• No customer records from your store. Shopify reads are order counts, order totals and daily sales aggregates. No Shopify customer, line item or fulfilment endpoint is called anywhere in our code.
• No card numbers. Stripe holds those, and payment runs through Stripe's own hosted checkout.
• No visitor IP addresses. We do not store them, and nothing in our code reads one: rate limits are keyed on your brand and your user, never on an address. Our host processes them transiently in its request logs, the way every host does.
• No Meta pixel access, no Conversions API access, no page or post access, no audience or targeting reads. None of those permissions is requested, so none of them is available to us.
• Creatives you upload are kept for you. Landing page screenshots are scored and discarded. A creative you attach in chat is stored so you can reuse it, in your brand’s own library. It sits in private storage with no public address, and reaches a browser only through a request that checks your login and that the creative is yours, so a leaked link shows a stranger nothing. Deleting a creative removes the file; deleting your account removes every file it held. Landing page screenshots are still sent to the model, scored, and discarded, with only the scores and the written critique kept.
• Raw platform responses are not written into your chat history. A stored message keeps the tool name, a one-line summary, whether it succeeded and when it ran.

Section 11 · application security

The boring layer. Written down anyway.

Section 12 · what we have not done yet

No SOC 2. No ISO 27001. Here is what we do have.

A security page that lists only strengths is a brochure. Here is the current state.

• No SOC 2 report. No ISO 27001 certificate. No third-party penetration test. We are a small company and each of those is a real commitment of money and time. We will publish a report when there is a report, and no status badge before then.
• Our content security policy runs in report-only mode. An enforcing version took production sign-in down once, because the policy was written from what we believed browsers needed rather than from what they actually requested. It now evaluates the same rules, blocks nothing, and logs every would-be violation, and it goes back to enforcing when that log is empty. Every other security header in section 11 is enforced today.
• Our script policy still allows inline scripts. Removing that, with a per-response nonce, is the next change after the policy goes enforcing.
• Encryption keys live in the deployment environment, not a managed key service. See section 9.
• Self-service account deletion has deliberate limits. A solo workspace owner can review and confirm closure in Settings. We refuse the automated path for shared workspaces, incomplete previews, cross-workspace memberships and platform writes still in flight; support handles those cases. Subscription cancellation, file deletion, database deletion and sign-in deletion run as recorded, retry-safe stages, with follow-up completed within 30 days.
• We do not delete your data automatically when a subscription ends. There is no age-based purge for customer workspace content. Scheduled work stops when the service entitlement ends, but saved content stays until an owner closes the account or asks support. Short-lived rate-limit counters and the minimal closure progress record have bounded cleanup; they are not a workspace-content retention policy.
• Seats carry two roles and no more. Owner and member. The owner handles billing, connects and disconnects ad accounts, sets write access, manages who is in the workspace and chooses which brands each member may see. Members do everything else inside those brands, approving changes included, and the record names whoever pressed the button. There is no approval threshold and no ownership transfer: an owner leaves by deleting the account.
• We do not claim universal two-factor enforcement. Customer sign-in and its factors run through Clerk; our customer-access code neither requires a second factor nor reports one to a workspace. The internal God View refuses sessions without completed MFA, and sensitive changes add a ten-minute freshness check.
• Number-grounding covers a fixed list of metrics. It blocks change proposals, and it holds back an untraceable figure in the reply itself, in prose and in a table. What it does not cover: frequency, reach, sessions, average order value, conversion rate, customer counts and add-to-carts, which we read but do not record; a table column headed something we cannot map to a metric; a cell holding a sentence instead of a value, which it skips rather than guesses at; and a figure whose metric word is separated from it by a numeric window, which is logged as unread. See section 8.
• There is no undo button and no automatic retry. See section 6.

If any of the above is a blocker for you, say so at support@sablemako.com and we will tell you honestly where it sits.

Section 13 · revoke, disconnect, delete

Three ways out, all of them yours.

Section 14 · report a problem

Found something? Tell us.

Section 15 · questions

The questions people actually ask.