Security at Otto

Otto is a small, early product run by a small team. It does not yet hold a SOC 2 report, an ISO 27001 certificate, or any other third-party attestation — and we won't imply otherwise anywhere. What it does have is a set of real, tested technical controls, listed below exactly as they exist, and a formal SOC 2 readiness program working toward an independent audit.

All traffic is encrypted in transit with TLS; the app sends HSTS with preload, so browsers refuse to speak plain HTTP to it. OAuth tokens, connected-account API keys, and stored site credentials are encrypted at rest with AES-256-GCM, and the decryption path fails closed: a value that isn't a valid ciphertext is refused, never used. Passwords are never stored — only bcrypt hashes. Password-reset and email-verification tokens are stored only as SHA-256 hashes, expire quickly, and are single-use. The encryption key supports staged rotation without downtime.

Sessions live in an httpOnly, SameSite cookie and expire after 7 days. Changing or resetting your password invalidates every outstanding session immediately, and "sign out everywhere" does the same on demand — including paired browser-extension devices. Sign-in is protected by layered rate limits, a per-account lockout that only wrong passwords consume, and timing-equalized responses that don't reveal whether an email has an account. Each sign-in triggers a notification email with the IP and device.

Every outbound action Otto prepares — an email, a calendar invite, anything that leaves your account — waits for your explicit approval. That gate is enforced server-side at a single chokepoint and fails closed. Requests are additionally checked for cross-site forgery at every authenticated gate, and every account's data is tenant-scoped: queries are structurally pinned to the signed-in user, and automated tests fail the build if a route forgets.

A dedicated, append-only security log records sign-ins and failed sign-ins, password changes, session revocations, data exports, account deletions, and administrative actions — with IP and browser info, retained for 400 days. Nothing in the codebase can edit a security-log row; an automated structural test enforces that only the retention sweep may remove them.

The database is backed up automatically every night with rotation, and the restore procedure is scripted and verifiable — restore drills rebuild a scratch database and check row counts and primary keys, not just "the file exists." A health endpoint continuously reports database, scheduler, and backup freshness, and deployments fail closed: a migration error aborts the deploy and the previous version keeps serving. If our AI provider has an outage, Otto degrades honestly — a clearly-disclosed backup model with no ability to take real-world actions — rather than pretending nothing happened.

The test suite is in the hundreds of files and includes structural security guards: tests that read the source and fail if an API route lacks an auth gate, if a raw SQL call appears outside the audited list, if a secret-shaped string could reach logs, or if the account-deletion path misses a table that holds user data. Dependency vulnerabilities are gated: any high or critical finding must be fixed or carry a written, owner-signed risk acceptance with an expiry date — silent snoozing isn't possible. Secrets never live in the repository, and log output is scrubbed against secret-shaped strings as a backstop.

The complete list of sub-processors — every company that touches your data and what each one does — is published in the Privacy Policy (§5.7), along with what happens to your content when it's sent to an AI model and the routing restriction that keeps OpenRouter requests away from model providers that collect user data.

• No SOC 2 report or other third-party attestation yet — a readiness program is under way; the audit itself comes when the operating company is formalized.
• No multi-factor authentication for user accounts yet — it is on the roadmap; sign-ins are meanwhile protected by the lockout, notification, and revocation controls above.
• No bug bounty program — good-faith reports are still genuinely welcome.
• No signed data processing agreement with Recall.ai yet — the company that holds a meeting recording between Otto's notetaker joining a call and the transcript being saved (Privacy §5.7). That is the same open status as our other vendors, but a recording of people's voices is the most sensitive thing any vendor briefly holds for us, so it deserves its own line here. Until a DPA is signed, what protects that recording is Recall's published commitments, the deletion Otto performs the moment your transcript is saved, and a timed backstop that deletes it regardless.

If you believe you've found a security issue, email team.ottohq@gmail.com with what you found and how. Reports go directly to the people who build Otto. Please give us a reasonable window to fix the issue before public disclosure; we'll tell you plainly what we found and what we did.