You're trusting us with access to your cloud. Here's exactly how we treat it.

Credentials you connect never live in environment variables, code, or logs. Each one is sealed with AES-256-GCM under its own single-use data key, and that key is wrapped by Google Cloud KMS— the wrapping key never leaves Google's key-management service. Stealing our database yields ciphertext that cannot be opened without also compromising the KMS.

Each ciphertext is additionally bound to your workspace, provider, and secret name: a sealed value copied to any other row — even by someone with direct database write access — fails authentication and will not decrypt. In production the app refuses to touch the vault at all if the KMS configuration is missing, rather than falling back to anything weaker.

Decryption happens only inside an authenticated request scoped to your workspace, in memory, and each decryption is written to your audit log by secret name — values are never logged, returned to the browser, or shown to us.

Your workspace id travels only inside a signed session token — it is never accepted from a URL or form field. Every query that touches your workspace's data runs under PostgreSQL row-level security, on a restricted database role the app verifies at boot cannot bypass it (a separate privileged connection exists only for login bootstrap and billing webhooks — never for tenant reads). The API surface is default-deny: routes are closed unless explicitly made public.

When Alfred reads your app's own database, it connects with the read-only connection string you provide; once connected, all reads run in READ ONLY transactions with statement timeouts as a second belt, and every use validates that the target is a real public host — connection strings and webhook URLs pointing at internal networks are rejected outright.

Authentication is delegated to WorkOS — Alfred never stores or sees your password. Sessions are short-lived signed tokens checked on every request, with a per-member version so access ends when membership does. Signing out ends the session globally, not just in your browser.

Alfred runs on Google Cloud (Cloud Run + Cloud SQL) in me-west1 (Tel Aviv, Israel), serves only over HTTPS, and backs up daily. Roles are enforced server-side: viewers cannot mutate anything, and every credential change is admin-gated and audited.

Who runs this: Alfred is built and operated by a solo founder — that's a trade-off you deserve to know about, and it's also why everything above is designed to fail closed rather than lean on a security team. If Alfred is breached in a way that touches your workspace, you hear it from us within 72 hours, with specifics. Good-faith security research on your own workspace is welcome — we won't lawyer up over a responsible report.