Connector-Worker's Foundation: A New Credential Vault, Built and Locked Down From Day One
The new connector-worker service ships with its own encrypted credential store and a redacted action log, built before a single third-party action was added.
Before connector-worker could connect a single Google account or run a single Gmail action, it needed somewhere safe to keep what it connects — and a record of what it does with that access. This release is that foundation: a new worker, scaffolded from the platform's standard worker template, plus two new database tables purpose-built for holding third-party credentials.
Two tables, drawn narrowly on purpose
connector_connections holds one row per customer per connected provider — Google today, with room for others (Slack, Notion, and so on) to be added later as new rows rather than a schema change. Tokens are never stored in plain text: they're encrypted at rest with the same AES-256-GCM helper the platform already uses to protect other stored credentials elsewhere, so a database read alone was never enough to extract a usable token even before any access-control layer is considered.
connector_action_logs records that an action ran and whether it succeeded — deliberately nothing more. No parameters, no tokens, no response bodies land in that table. It exists to answer "did this happen," not to reconstruct what was sent, which is the same boundary already drawn around the platform's AI-completion usage logs.
A worker built to trust exactly one caller
Connector-worker was scaffolded with no public route of its own — reachable only from inside the platform's own services, never directly from a browser or an external customer's code. Its early design had it resolving a caller's identity itself, by calling back into the AI gateway's own identity check. That approach didn't last: it was replaced almost immediately once the full request path was clear, so that today connector-worker trusts a single relationship — the AI gateway, which has already resolved who's calling before connector-worker ever sees the request. (That correction, and why it matters, is its own story — see "The AI Gateway Now Proxies to Connector-Worker.")
Why this groundwork mattered first
Everything connector-worker does today — connecting a Google account, running a Gmail or Sheets action, polling Gmail for a workflow trigger — sits on top of this: an encrypted vault, a redacted audit trail, and a worker that only ever answers to one trusted caller. Getting that right before adding the first integration is what let the integrations that followed ship quickly without re-litigating where credentials live or who's allowed to ask for them.