Security

• All traffic is TLS 1.3.
• Customer Content encrypted at rest by the database provider; OAuth tokens additionally encrypted with AES-256-GCM at the application layer.
• Cross-tenant isolation enforced by middleware on every API request.
• Production access limited to a small number of named engineers via SSO + audit logs.
• We do not use Customer Content to train AI models. Anthropic, our LLM provider, contractually agrees not to either.
• Per-quest cost cap and 3-tier guard prevents runaway agent spend or accidental DoS-by-prompt.

• API and workers — Hono on Bun, hosted on Fly.io. Bluegreen deploys with health-check gating; auto-rollback on smoke failure.
• Database — Supabase Postgres (us-east-1). Daily backups retained 30 days, 7-day point-in-time recovery.
• Web (UI) — Next.js on Vercel. Cross-origin to the API; CORS enforced at the server.
• Edge / DNS — Cloudflare. DDoS protection, bot challenge.
• Three live environments — dev, staging, production. Staging gates production (production deploys only after staging's smoke tests pass). Same commit hash ships to both.

• Sign-in via Google OAuth or email magic link, both handled by Supabase Auth.
• Sessions are signed JWTs with short access-token expiry; refresh tokens are HTTP-only and secure.
• Every authenticated API request validates the user's session and the requested company is one they belong to (server/src/middleware/auth.ts).
• SSO / SAML — on the roadmap for Enterprise customers; available on request.

• In transit — TLS 1.3 between client and edge; TLS between every pair of services we operate.
• At rest (DB) — Supabase encrypts the entire database at rest with AES-256.
• At rest (Integration credentials) — OAuth refresh tokens, API keys, and similar high-value secrets are additionally encrypted at the application layer with AES-256-GCM, using a key managed in our secrets store and never stored in the database.
• Key rotation — integration encryption keys are rotated on a defined schedule and immediately upon any suspected exposure.

• Production access is limited to a small number of named engineers.
• Access is via short-lived credentials and audited at the cloud-provider level (Fly.io, Supabase, Vercel).
• We enforce least-privilege; engineers do not have standing read access to Customer Content. Access for debugging customer-reported issues is logged and time-limited.
• Engineer workstations are required to have full-disk encryption enabled and a screen-lock policy. As a small team we do not yet operate fleet-managed company-issued hardware; we plan to introduce MDM enrollment as we grow.

• Every record carries a companyId foreign key.
• Every API route validates that the caller's company matches the resource being accessed.
• Cross-tenant queries are not possible from the application layer; the validation runs before any database read.
• We periodically audit for cross-tenant access bugs and ship fixes for any that surface as P0 incidents.

• Per-quest USD cost cap, with a 3-tier guard (warn, slow, halt) that prevents runaway agent loops from consuming arbitrary budget.
• Worker actions that mutate state in third-party Integrations are logged to activity_log with the rationale and the originating message.
• Anthropic does not train on Customer Content (per their commercial terms).
• Customer Content is not shared between companies in any prompt; agent context is scoped per company.
• Every Ted-initiated action is visible to the operator in real time; quests can be cancelled mid-run.

• Application errors flow to Sentry. Authorization/cookie headers and a defined list of sensitive body keys (passwords, tokens, secrets, API keys) are redacted server-side before events leave our process; stack-trace context can still incidentally include other Customer Content.
• Server logs flow to our hosting providers' log stores. Logs are retained 30-90 days depending on the store and tier.
• Every Ted-initiated state change is recorded in activity_log; account admins can review the audit trail in-product.

• Database backups: daily, retained 30 days.
• Point-in-time recovery: 7 days (Supabase Pro).
• We have a process for periodic restore testing and document outcomes when performed.
• Schema migrations are forward-compatible by design and are reviewed for backwards-compatibility before shipping.

If we detect a security incident affecting Customer Content:

1. We notify affected account admins within 72 hours of confirmation, by email.
2. We provide the details we have at the time: what happened, what data was affected, what we're doing about it.
3. We cooperate with regulators where required and provide updates as our investigation progresses.
4. Where lessons are public-safe, we publish a postmortem on our status page when one is available.

Our incident response and rollback playbook lives in DEPLOY.md in our codebase and includes runbooks for: deploy rollback, database restore, OAuth-token rotation, and integration-provider outages.

If you've found a security issue, please report it per our Responsible Disclosure Policy. Email security@autono.sh with details. We acknowledge within 3 business days, and we won't pursue legal action against good-faith researchers who follow the policy.

We are honest about what we have and don't have. As of the date at the top of this page:

• GDPR — DPA and SCCs for EU→US transfers available on request; subprocessor disclosures published.
• CCPA— rights- request flow available; we don't sell or share personal information.
• SOC 2 Type I — preparation in progress.
• SOC 2 Type II — planned after Type I.
• ISO 27001 — not yet.
• HIPAA / BAA — not available; do not submit Protected Health Information to System2.
• PCI DSS— we don't store cardholder data; payment is handled by our payment processor.

See our Subprocessors page for the full list of providers we depend on, what data each one sees, and where they're located.

For security questions, vulnerability reports, or to request our security questionnaire response, contact security@autono.sh.