Security

At a glance

• Public web and API traffic uses HTTPS. Every connection to the production database uses TLS.
• Amazon Aurora and Amazon S3 encrypt Foundable's production database, object storage, and backups at rest.
• Authenticated company routes enforce identity and recheck your ownership of the foundable on every request, and every company record is protected by row-level security in the database.
• The production API rate-limits requests per client address.
• Foundable does not train its own foundation models on Customer Content. OpenAI and Anthropic publish no-training commitments for business and API data. Our provider registry lists every provider.
• Foundable's production database keeps automated backups with point-in-time recovery for 14 days. Recovery for a website's own backend follows that project's settings.
• Websites are built, compiled and run in isolated sandboxes that reach only the hosts each job needs.

Architecture

• Web and edge: the Foundable workbench is a static application the API serves from its own origin, behind an Amazon CloudFront front door. Published websites are served by Cloudflare at foundable.app from releases stored in Cloudflare R2; a website's server code runs in its own Cloudflare Worker.
• API and workers: Node.js services run on AWS ECS Fargate in us-west-1: the API, the Ted Worker that runs turns and Build runs, the billing webhook and recovery processes, the mail and social services and their workers, the waitlist worker, and the publication authority. Each service carries only the configuration and secrets its role needs.
• Database and storage: Foundable's primary database is Amazon Aurora PostgreSQL in us-west-1, with two instances in production and encrypted storage. Saved files, uploads and workspace checkpoints live in Amazon S3 buckets in the same region. Durable workflows run on Temporal Cloud. Sandboxes for building, compiling and rendering run on Modal. A website that needs a backend gets its own Supabase project in us-west-1.
• Deployments: a release is built from a commit on the main branch, pinned by image digest, and rolled out by ECS with readiness checks that count a task as healthy only once it serves. Production takes only a commit that has already run on staging; an operator runs each deployment, and a release can be rolled back to an earlier deployed commit. Staging remains a separate deployment target from production.

Authentication

• Foundable supports Google, Apple, and email-code login through WorkOS.
• WorkOS issues short-lived, signed access tokens, which the API verifies against the exact configured issuer and client with cached signing keys. The session that renews them is kept in WorkOS's HttpOnly cookie on login.foundable.com; browser scripts cannot read it, and the product's own storage holds no long-lived credential.
• The API accepts only bearer tokens; cookies never authenticate a request. Every request also carries the browser's current session identifier, compared with the verified session, so a stale tab can never show another account's data.
• Authenticated company routes validate ownership before tenant data is returned or changed.
• Operator tooling for the waitlist (admission and the operator's view of the line) is limited to accounts on an allowlist or with a verified @foundable.com email, checked by the API on every request.

Encryption

• In transit: public browser and API requests use HTTPS. Production database connections use TLS, verified against the AWS RDS certificate bundle.
• At rest: Aurora and Amazon S3 encrypt Foundable's production database, object storage and backups at rest; the database's encryption is verified before each release is activated. A website's own backend is a separate Supabase project with Supabase's controls.
• Secrets: runtime secrets are held in AWS Secrets Manager and injected into each service at start; they are never written to disk, to the browser, or to logs.
• Connected services: the credentials for a linked social account, mailbox or Stripe account are held by the provider that manages the connection; Foundable stores the connection's identifiers, not your passwords or tokens for those services.

Operational access

• Deployments and infrastructure changes are made by an operator with their own AWS credentials through a deploy tool that prints every change before it happens; no long-lived deployment key is kept in a hosted CI system.
• Each ECS service runs under its own task role with the secrets its role needs, read from AWS Secrets Manager at start.
• Support access does not create implicit membership in a customer foundable. Operator tooling is limited to the waitlist and to accounts on an allowlist or with a verified @foundable.com email.

Tenant isolation

• Every write runs in a database transaction that names the acting user, and row-level security policies let a user reach only the companies they own; a deleted account's actor is rejected by the database independently of the HTTP check.
• Authenticated company routes require current ownership. For routes addressed by a resource identifier, handlers resolve the stored resource owner before granting access.
• Background work runs under authorizers scoped to the account and foundable it serves; a job never accepts its acting user from a request body, a tool argument or a model.
• Each Build run, workspace and video render gets its own sandbox, and a website's server code runs in its own Worker.

AI-specific safeguards

• Paid work is admitted against the account's credits before it starts: a Ted turn, a Build run, a drafted reply or a rendered video holds credits first and settles what it used.
• Sandboxes reach only the hosts each job needs (the model API and the package registry for a workspace), and a run's files stay in that run's sandbox and checkpoint.
• Foundable does not train its own foundation models on Customer Content. Anthropic states in its Commercial Terms that it may not train models on customer content from its services, and OpenAI states that business and API data is not used for training by default. The provider registry describes the narrower, feature-specific services that support the product.
• Ted's context retrieval is scoped to the current foundable and chat. The same ownership checks protect the underlying company records used to assemble that context.
• The product streams agent and Build progress to the operator, with Stop controls where the workflow supports interruption. Whether a model call's content is captured in agent traces is an explicit, documented setting of each environment.

Logging and monitoring

• Application errors flow to Sentry with default PII collection disabled. Server-side processing removes headers, request bodies, URL credentials, structured personal fields and secret-shaped text before an event leaves the process; the browser sends no performance traces and no session replay.
• Product analytics are explicit, named events sent to PostHog without cookies, person profiles or IP addresses inside the product. There is no autocapture and no session recording.
• Production service log groups in AWS CloudWatch are retained for 30 days; staging's for 14 days.
• A diagnostic journal of Ted and Build activity, readable for 14 days, supports the in-product activity view and operator investigation. Agent traces go to Judgment Labs for quality monitoring, with the foundable and user identified only by stable hashes.

Backup and recovery

• Foundable account and product data: the Aurora production database keeps automated backups for 14 days, with continuous point-in-time recovery inside that window, and deletion protection is on.
• Website backends: each website's backend is its own Supabase project, and its backup and recovery settings follow that project's plan and configuration.
• Workspaces: a foundable's workspace is checkpointed to a dedicated S3 bucket, so interrupted work resumes from the last checkpoint.
• Production migration files are append-only and numbered; the migrator applies them in order and never re-applies one it has already run.

Incident response

If we become aware of a security incident affecting Customer Personal Data, we investigate and contain it, notify affected customers without undue delay, and provide the scope, impact, and remediation details known at the time with updates as the investigation progresses. For customers with an effective, countersigned Foundable DPA, the executed incident-notice terms control.

Public service-availability incidents and updates are published on our status page when applicable. Production operations documentation covers deployment health checks, rollback to an earlier release, and the deployment desk that coordinates releases.

Reporting a vulnerability

If you've found a security issue, please report it per our Responsible Disclosure Policy. Email security@foundable.com with details. We aim to acknowledge reports within 3 business days. Our scoped safe-harbor terms are stated in the policy.

Compliance and procurement

Current customer and procurement resources include:

• GDPR: a public DPA review template and subprocessor list are available. Contact us to execute account-specific processor and transfer terms.
• CCPA / CPRA: the Privacy Policy describes rights requests. Foundable does not sell or share personal information for cross-context behavioral advertising.
• Regulated health data: Foundable is designed for general business operations. Do not submit Protected Health Information as Customer Content.
• Payments: subscription checkout is handled by Stripe, and full payment-card numbers are not stored by Foundable. Do not submit full card numbers or CVV values as Customer Content.

Vendor security

See our Subprocessors page for the current list of providers we depend on, what data each one sees, and where it is processed.

Questions

For security questions, vulnerability reports, or to request our security questionnaire response, contact security@foundable.com.