Security

You're connecting a live Meta ad account — the thing that spends real money. Here's exactly how ZuckerBot protects that access, in specifics rather than promises.

Your Meta token, encrypted at rest

Every Meta access token is stored encrypted with AES-256-GCM (authenticated encryption — each value carries its own integrity tag, so tampering is detectable). Tokens are decrypted server-side only, at the exact moment a Meta API call needs them, and are re-encrypted at every write. There is no code path that returns a decrypted token to the browser.

Decrypt at point of use

The plaintext token exists only in server memory for the duration of the Meta API call it's needed for — never persisted in the clear, never sent to the client.

Per-tenant isolation

Each customer's tokens and data are scoped to their own account. One customer's connection is never visible to another.

Key held outside the database

The encryption key lives in the platform's secret store (environment/secret manager), not in the database — so a database dump alone cannot decrypt any token.

Encrypted everywhere it's stored

The same encryption applies across every place a token can live; existing records were migrated so no plaintext token remains at rest.

Your ad spend can't run away

Campaigns and ads are created paused. Nothing runs — and nothing spends — until it's explicitly activated by you or, on your instruction, your agent.
Preview before build. Campaign builds go through a preview/approve step so the full plan, budget included, is visible before anything is created.
ZuckerBot never charges your ad spend. Advertising is billed by Meta directly to your Ads Manager payment method. We take no platform fee and no percentage of spend.
Hard caps, no overage. Each tier has a fixed monthly call limit and a per-minute rate limit. At the cap, requests are declined until the next cycle — never an overage bill.

Access & transport

All traffic is served over HTTPS.
Sign-in uses one-time email codes — there's no password to leak, and no password stored.
API keys are shown once at creation and stored only as needed to authenticate your requests and enforce your tier's limits.
Database access is restricted by role-based controls; the token-reading paths run under a server role, never the browser.

What we don't claim

We're a new product built by a solo developer. We don't claim a SOC 2 report, a third-party penetration test, or any certification we haven't done — because we haven't done them yet. What's on this page is what's actually implemented today. If that changes, this page will say so.

Found something?

If you believe you've found a security issue, email support@zuckerbot.ai with the details and we'll respond quickly. Please don't publicly disclose until we've had a chance to fix it.