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 secretsNo Stripe controls activeNo 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

Some controls are proven locally; production activation remains gated.

Production signup, client provider connections, external transactional email, live campaign sending, and billing are not presented as active. They require their own credentials, provider checks, legal review, security validation, and owner-controlled activation.

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