Security & trust

Trust starts with saying what the product can—and cannot—do.

The current foundation is designed around server authority, workspace isolation, protected credentials, explicit approval, safe diagnostics, and auditable operational actions.

No impersonationNo browser-stored provider secretsServer-gated Stripe billingNo autonomous-send claim

Verified controls

Boundaries built into the foundation.

Access

Server-resolved organizations and roles

Workspace membership and role authority come from the application database, not a browser-selected identifier.

Isolation

Tenant boundaries tested against PostgreSQL

Server authorization and row-level security provide separate layers against cross-workspace access.

Credentials

Secrets stay server-side

Client provider credentials are designed for encrypted workspace-scoped storage and redacted diagnostics.

Approval

Human release remains required

Draft approval, suppression, caps, quiet hours, and provider restrictions are checked before eligible dispatch.

Administration

No content access or impersonation

Service administration is limited to aggregate evidence and audited operational actions without client content or secrets.

Ownership

Protected owner separation

The protected owner workspace remains outside normal client billing, deletion, suspension, and migration paths.

Readiness status

Accounts and billing are live behind server-enforced gates.

Verified visitors can create an isolated workspace and select a plan through authenticated Stripe Checkout. Provider connections and campaign sending remain deliberate, workspace-specific actions: customers supply their own provider credentials, and sending requires setup, review, approval, and the applicable safety checks.

No public statement on this page is a certification, penetration-test report, availability SLA, or guarantee that an incident cannot occur.

Review the exact plan and provider boundaries.

Compare plans