Early access

Security and trust

Security that lives in the database.

Optic holds prospect data, drafts and the keys that send email for more than one product. So the important rules aren't in application code an agent could route around. They're in Postgres, and they hold for every caller.

Isolation

Row-level security per workspace

Every product is a workspace, and every row belongs to one. Postgres row-level security (RLS) decides which rows a request can see.

  1. The API verifies the caller's key.
  2. It opens a transaction and switches to optic_user, a role that can't log in and can't bypass RLS.
  3. It sets optic.user_id and optic.workspace_id for that transaction only. From there, RLS policies decide what the caller sees.
  4. Nothing carries over to the next request on the same connection.

Composite foreign keys add a second wall: a row can't point at another workspace's record, even when the backend writes it. A bug in a tool's filter still can't return another workspace's rows. Built

Access

API keys, hashed and scoped

  • Only a sha256 hash of each key is stored. The key itself is shown once, when it's created. Built
  • A key belongs to a user and can be limited to one workspace. A limit can narrow access but never widen it.
  • One key per person per account, so revoking one doesn't touch anyone else.
  • The MCP server and the REST API use the same keys and the same per-request scoping. Every route except the health check needs one.

Sign-in for the web UI (Firebase Auth) comes with the UI. Planned

Audit

An append-only event log

Every signal, form submission, draft, approval, rejection, email, reply, bounce, meeting and stage change is written as an event. Events can't be updated or deleted. The only exceptions are deleting a whole workspace and an explicit data-erasure flag, for when a person asks to be forgotten. Built

Each event carries typed references to the person, company, deal, signal, play and message, so "who approved this, and what did the draft say before the edit" is a query, not an investigation.

Guardrails

Rules the database enforces

These hold for the API, agents, workers and anyone with a SQL client. They're covered by tests that run against Postgres. Built

  • Tenant isolation

    Row-level security limits each user and API key to its workspaces. Composite foreign keys stop a row from pointing at another workspace's record, even from the backend.

  • A reply stops automation

    When someone replies, their play ends, queued automated drafts are canceled and they're marked engaged. Drafts you wrote by hand stay.

  • Suppressions hold

    A suppressed address or domain can't be approved, scheduled or sent to. A hard bounce adds one. They survive deleting and re-importing the lead.

  • One play per person

    A person can be in one running play at a time, so two plays never email the same lead.

  • Separate sending domains

    A sending domain belongs to one workspace, so one product's campaign can't hurt another product's sender reputation.

  • Append-only events

    Every signal, email, reply, meeting and stage change is an event that can't be edited. Webhook deliveries are queued in the same transaction.

Credentials and hosting

Vendor tokens stay out of the database

  • Vendor tokens (mailbox, sending, contact data) live in Google Secret Manager. Database rows only hold a reference to the secret.
  • Hosting: the service runs on Google Cloud Run and the data in Cloud SQL for Postgres, both in us-central1.
  • Inbound webhooks are verified with each form's secret: the provider's own scheme for Tally, Typeform and Webflow, and HMAC-SHA256 of the raw body for generic forms. Building next
  • Outgoing webhooks are signed: Optic-Signature: t=<unix>,v1=<hmac_sha256(secret, "<t>.<body>")>. Planned

Plainly

What we don't have yet

Optic is a young product that runs our own GTM first. It doesn't have:

  • a SOC 2 report or any other third-party audit
  • SSO or SAML
  • a data processing agreement or a published subprocessor list
  • data residency outside the US

If any of these blocks you, tell us when you ask for early access. It helps us decide what comes first.

Reporting a vulnerability

Email hello@optic.to with "Security" in the subject. Please don't test against other people's workspaces.

Optic runs our own GTM today.

It isn't for sale yet. If you'd run it for your product, tell us what you sell and which signals matter, and we'll talk when drafting and sending are done.

Request early accessRead the MCP docs