Security overview

Every customer record in Operator is tagged with the business identifier of the owner. We enforce row-level security on the database so that a query made by or on behalf of one business can only return rows that belong to that business.

• RLS is enabled on every customer-facing table, not granted by convention or application-layer checks.
• Agents acting for one business cannot read another business's data, because their database role is scoped to the business they serve.
• Internal admin queries are logged and gated; cross-business reads for support require explicit, time-bound elevation.

Operator publishes aggregate market intelligence through a public Substrate Data API. That surface is built exclusively from public sources: directory data, public reviews, the public web. Private customer brains (the per-business knowledge stores that hold your invoices, customer history, voice profile, and agent actions) are firewalled from that pipeline. They do not feed the API, they are not sold, and they are not used to train shared models.

OAuth tokens, integration credentials, and webhook secrets are stored in Supabase Vault, an at-rest encryption layer that keeps secrets ciphered in the database and decrypts only at the moment of use by an authorized role.

• Secrets are never written to logs or to client-visible responses.
• Access to decrypted material is scoped to the service role that needs it for a specific job.
• Key rotation is supported with a version field so rotations can be rolling rather than big-bang.

Customer data is encrypted in transit (TLS 1.2+) between your browser, Operator services, and integrated providers, and encrypted at rest in the database. Backups inherit the same at-rest protections.

• Customer authentication is Supabase Auth with email-link or OAuth (Google, Microsoft) flows. Sessions are HTTP-only, secure cookies.
• Operator personnel access uses single sign-on with a hardware-key second factor.
• Production database access is role-scoped; the service role used by background jobs is separate from the application role used by request handlers.
• Admin actions are logged to an append-only audit table.

Every action an Operator agent takes on your behalf (a posted reply, a sent message, an invoice reminder, a write to your Google Business Profile) is recorded in your business's audit log with the agent identity, the action, the inputs, and the outcome. You can review, dispute, and roll back actions from your dashboard. Agents cannot act outside the OAuth scopes you authorized at each provider.

Where Operator connects to your financial systems (Stripe for billing, Plaid for read-only bank context), access is scoped to what the relevant agent needs. Stripe handles your payment instruments; card data is not stored by Operator. Plaid-backed connections are read-only; the bookkeeping agent can categorize activity but cannot move money without an explicit, owner-approved action.

Operator runs on a short list of established providers:

• Supabase: primary database (RLS), authentication, file storage, Vault for secrets.
• Vercel: web hosting and serverless functions.
• Stripe: subscription billing and metered usage. Cards never touch Operator.
• Resend: transactional email.
• Twilio: SMS and voice messaging.
• Retell AI: voice agent runtime.
• Anthropic, OpenAI: language-model inference for agent work. Provider zero-retention terms are used where available.

The full list is on the Sub-processors page. Vendor contracts and security documentation are available on request at operator@operator.fyi.

We monitor application errors, rate limits, and abnormal access patterns continuously. Suspected incidents are triaged on an on-call rotation, contained, and documented in a post-mortem.

If your data is affected by a security incident, we will notify you without undue delay and provide the information you need to satisfy your own notification obligations, consistent with the commitments in our Data Processing Addendum.

Security researchers: report vulnerabilities to operator@operator.fyi before public disclosure. We will not pursue good-faith research conducted in accordance with the Acceptable Use Policy.

Operator is built to meet the obligations described in our DPA, including processor commitments under the GDPR/UK GDPR and Service Provider commitments under the CCPA/CPRA. Where customers in regulated verticals need additional controls (for example, healthcare deployments under the Healthcare plan), we operate the corresponding compliance program for those customers under separate agreement.

Security and compliance contact: operator@operator.fyi. Operator AI LLC, Wyoming, USA.