Security Overview
What we do, what we don't, and what's still in motion. This document is written for the person at your company who will sign the security questionnaire.
1. Architecture in one sentence.
Customer messages enter through tenant-scoped webhook endpoints, get routed to Satatam with retrieval over your encrypted tenant knowledge base, and return through the same channel they came in on. Supported sensitive-value patterns are redacted on the paths documented in Section 3, subject to its exceptions; this is not universal removal of all personal information on every path. Conversation turns, model calls and security-relevant events are logged as described in Section 6. Customer conversations do not pass through the marketing website. Inbound email is received through Cloudflare Email Routing (see Subprocessors).
Phone receptionist (in preview): calls are handled by OpenAI's realtime voice model via Twilio. The assistant is set to open each call by saying that it is an AI assistant and that the call is transcribed so the team gets a summary. Call audio is not recorded. After each call the business receives a written summary by email; if nothing usable was captured, the summary says so. Summaries are kept for up to 30 days, and the caller quotes behind them are removed within 24 hours. If a caller asks during the call that the summary not be shared, we withhold it when we detect the request. When we cannot tell, the business gets only a one-line note that the call happened, without its details. If we miss the request, the business receives the normal summary.
2. Encryption.
- In transit: all public endpoints are served over HTTPS, and HSTS is enforced on our marketing site and widget/API endpoints.
- At rest: tenant data lives in a managed Postgres database on Supabase with at-rest encryption provided by the underlying storage layer. Customer data tables are protected by Postgres row-level security keyed to the signed-in tenant on a non-owner connection. Sign-in, billing, provisioning, retention and some channel and handoff bookkeeping run on a separate privileged connection and are scoped to the tenant in application code. Knowledge files use server-owned, tenant-isolated OpenAI vector revisions.
- Secrets: credentials you connect (CRM, helpdesk, telephony and similar) are encrypted at the application layer with Fernet (AES-128-CBC + HMAC) before storage. The keys are deployment secrets on our host, not in the database or in source control.
3. PII redaction pipeline.
Card numbers, SSNs and API-key-style secrets are redacted on receipt, before the message goes to the AI model or the conversation record, on web chat, email, SMS, WhatsApp and the playground. Pattern coverage today:
- US Social Security Numbers written in the usual 3-2-4 grouping, with dashes, spaces or dots
- Payment card numbers (Luhn-validated)
- AWS access keys (
AKIAprefix) - Stripe live and test keys (
sk_live_,sk_test_) - GitHub tokens (
ghp_,gho_,ghs_) - Generic high-entropy strings that fingerprint as secrets
Matched values are replaced with a labeled tag such as [CARD-REDACTED] in the persisted transcript. Exceptions: messages are saved as received while a human operator has taken over a web chat, and for emails held by loop protection. Images are not redacted. Email addresses and phone numbers are not redacted, because they are needed to follow up. Channel providers such as Twilio or your email provider keep their own copy of the original message under their own retention terms. Audit-record details are redacted at write time; the actor field holds the signed-in operator's email.
4. Tenant isolation.
Knowledge base files and conversation history are isolated per tenant. Server-side resolution selects the tenant's active OpenAI vector revision; browser requests cannot supply an authoritative vector-store identifier. Each document carries a tenant hash, document ID, version and full content hash. Activation requires count and hash reconciliation, a known-answer retrieval check, and a tenant-filter canary check.
Satatam's reasoning loop has no path to the file index of any other tenant. Each tenant's knowledge is indexed in its own vector store; there is no shared index across customers.
SMS phone numbers follow the same isolation discipline. A phone number is stored under one partner tenant, used only within conversation threads that originated from that partner's intake, and never reused across tenants. Outbound SMS routes through a per-tenant Twilio Messaging Service so messages carry the partner's brand identity at the carrier level, not ours. Each partner's toll-free number goes through Twilio Toll-Free Verification before SMS is enabled (unverified → pending → verified). Opt-out state (cs_pro_sms_opt_out) is partner-scoped: opting out of one partner's SMS does not opt out of another's.
5. Authentication and access control.
- Customer authentication: email and password, or a magic-link email. Enterprise workspaces sign in through their own identity provider (OIDC); the session is then a Satatam token. This works with Okta, Microsoft Entra, Google Workspace, or any conformant provider, with PKCE, a verified
id_token, an optional email-domain allowlist, and optional just-in-time seat provisioning. SAML 2.0 and SCIM directory sync are on request rather than self-serve — talk to us if you need either. - API authentication: sessions are signed tokens (30-day lifetime) with tenant and role claims, and permissions are checked per endpoint. We store only a revocation list of signed-out token IDs and a password-change timestamp, never the tokens. We do not currently issue long-lived API keys or offer per-key IP allowlisting; if you need either, ask before you sign.
- Webhook signing: inbound webhooks from Stripe, HubSpot, Twilio (SMS, WhatsApp and voice), Zendesk, Calendly and OpenAI are signature-verified, and unsigned or invalid requests are rejected. Stripe and HubSpot use SHA-256, Twilio uses SHA-1 per their respective specifications. Inbound email uses a shared-secret signature from our Cloudflare email worker.
- Internal access: today, the operator (Michael Neubauer) is the only person with production data access. Actions through our admin API are audit-logged; direct database maintenance access is not individually logged today.
6. Logging, monitoring, and incident response.
Every conversation turn is recorded with tenant ID and timestamp, and every AI-gateway model call with the model used, latency and token counts. Phone calls are metered separately. Security-relevant events are written to a hash-chained audit stream. Audit records have restricted access and are kept for at least your plan's audit window: 12 months on Starter, 2 years on Growth, 7 years on Scale and Enterprise. They are written append-only by the application and hash-chained per stream; on-demand verification (Scale plan) detects edits and mid-chain deletions. Details in audit records are redacted at write time.
We watch service health through automated uptime checks and platform crash alerts, and review latency metrics. We do not yet run automated anomaly alerting on error rates or authentication patterns. For a confirmed incident, we aim to notify affected customers within 24 hours of confirmation and to share a written postmortem within 7 business days.
7. Vulnerability management.
- We run dependency vulnerability scans (
pip-audit) as part of our release process. - Secret scanning through GitHub push protection, plus a
detect-secretspass over the tree. Our hosted CI pipeline defines both as automatic gates, but that pipeline is not currently running — see the honesty note below — so today these are run deliberately rather than on every commit. - Container images are rebuilt from the base image on every release, which is how base-image security updates reach production. We do not currently rebuild on a fixed weekly schedule.
- No external penetration test has been performed yet. We will not describe one as routine before the first one has happened; it is on our roadmap.
8. Backup and recovery.
Our primary database runs on Supabase; ask us for the backup retention window and recovery options in force on the day you sign, and we will show you the plan we are on rather than a tier we are not. Knowledge bytes and immutable vector revisions are versioned by full content hash, so a prior knowledge-index revision can be re-pointed to for a tenant; this is a manual engineering operation. A manual encrypted backup procedure is documented (public-schema only; it supplements our database provider's own recovery); ask us for the date it was last exercised.
9. Certifications and data location.
We do not hold a third-party security certification. HIPAA is not supported: do not send protected health information through Satatam. We do not currently offer a Data Processing Agreement. Data location: our application servers (Fly.io, Ashburn, VA) and primary database (Supabase, AWS us-east-1) are in the United States. Some subprocessors, such as Cloudflare's edge network and our AI model providers, may process data in other locations under their own terms. We do not offer EU data residency or any other region pinning on any plan, and we will not sell it until a second region is actually running.
10. Subprocessors.
We use a small set of infrastructure providers, each used under the data-processing terms in its own standard customer agreement. We have not executed separate negotiated Data Processing Agreements with these providers. If that is a procurement condition for you, tell us before you sign. Current list, with the reason each is necessary:
- Anthropic — model inference and prompt caching. Conversation content is sent here to generate responses.
- OpenAI — vector stores for knowledge-base retrieval. Your knowledge-base content is indexed here, and a search query derived from each customer message (after PII redaction) is sent here to retrieve passages. Chat replies are generated by Anthropic. Phone receptionist (in preview): calls are handled by OpenAI's realtime voice model via Twilio and are transcribed; call audio is not recorded.
- Cloudflare — marketing site, edge caching, DDoS protection, Web Analytics on the marketing site, and inbound email routing. Inbound support emails sent to your Satatam address are received and parsed by a Cloudflare Email Worker before reaching our backend.
- Fly.io — tenant runtime compute. Tenants share one application; isolation is logical, enforced in the data layer rather than by separate processes.
- Supabase: managed Postgres for tenant data. Tenants share one database; customer data tables are isolated by row-level security on a non-owner connection, and some system work (sign-in, billing, provisioning, retention) runs on a privileged connection that is scoped to the tenant in application code.
- Upstash (Redis) — rate-limit counters, session locks, and delivery idempotency keys. Holds rate-limit counters, session locks and idempotency keys. Keys can contain IP addresses, email addresses and session identifiers. It holds no conversation content.
- Sentry — application error monitoring. Integrated in our code but not currently enabled in production, so no data is sent to it today. We will update this list before turning it on.
- Resend — transactional email (sign-in links, contact form, billing notices) and, for tenants who haven't connected their own Gmail, the AI's email-channel replies to your customers.
- Stripe — billing for your Satatam subscription.
- Twilio — Satatam's own SMS and phone numbers, and managed receptionist numbers.
- Zoho Mail: our own business mailbox (contact form messages and rights requests).
- HubSpot — our own CRM for website visitors and leads.
- Your connected accounts — when you connect your own Twilio, Stripe, HubSpot, Slack, Gmail, Google Sheets, Calendly, or Zendesk accounts, they are invoked only with the credentials you authorize, only on your behalf. This also covers any additional helpdesk/CRM integration you connect through the operator dashboard (Front, Gorgias, Salesforce, Kustomer, Jira Service Management, ServiceNow, Help Scout, Intercom, Freshdesk, Zoho, Pipedrive) — each is invoked only with the credentials you provide for that connection.
Full subprocessor list with addresses and processing categories: available on signed NDA. We give 30 days' notice before adding a new subprocessor.
11. Responsible disclosure.
If you find a security issue, send a responsible disclosure. We acknowledge within 1 business day, triage within 5, and credit researchers publicly if you'd like.
12. Contact.
Security questionnaires and custom architecture questions: contact us.