Security

• Public web and API traffic uses HTTPS. Production database connections require TLS.
• Supabase encrypts database storage and backups at rest with AES-256. Integration credentials receive separate AES-256-GCM application-layer encryption.
• Authenticated company routes enforce identity and company membership. Platform-admin mutations require a TOTP multi-factor-authenticated session.
• The production API sits behind AWS WAF managed rules and a per-IP rate limit.
• Foundable does not train its own foundation models on Customer Content. Anthropic and OpenAI publish no-training commitments for business/API data. Our provider registry.
• Foundable's primary production database has point-in-time recovery enabled. Recovery for app databases is configured per project; app database PITR must be enabled before it can be used.

• Web and DNS: the Next.js UI runs on Vercel, and Vercel is the authoritative DNS provider for Foundable's primary domains.
• API and workers: Hono on Bun runs on AWS ECS Fargate in us-west-1. The public API is behind an AWS Application Load Balancer and WAF. The live WAF uses Amazon IP reputation, anonymous-IP, known-bad-input, common, and SQL-injection managed rule groups plus per-IP rate limiting.
• Database: Foundable's primary database is Supabase Postgres in us-west-1. Databases created for apps built with Foundable are separate Supabase projects with project-specific backup settings; the current app-project provisioning configuration also requests us-west-1.
• Deployments: automatic API production deploys start from CI-verified commits on main, wait for ECS service stability, and run production smoke checks. Staging remains a separate deployment target from production.

• Supabase Auth handles Google and GitHub OAuth plus one-time email links and codes.
• Supabase Auth issues signed JWT access tokens and rotating refresh tokens. Browser auth cookies use SameSite=Lax and are marked Secure in production. The Supabase browser client can access those cookies to maintain the session.
• Server authentication middleware validates protected API calls. Authenticated company routes then validate membership before tenant data is returned or changed.
• Platform-admin mutations require a Supabase AAL2 session produced by a verified TOTP factor. Read-only admin access does not satisfy that mutation gate.

• In transit: public browser and API requests use HTTPS. Production database connection strings are required to use TLS.
• Database at rest: Supabase documents AES-256 encryption for project storage volumes and scheduled backups.
• Integration credentials: OAuth refresh tokens, API keys, and similar high-value secrets are additionally encrypted with AES-256-GCM at the application layer. The active encryption key is supplied from the runtime secrets store rather than the database.
• Key rotation: the encryption service supports a two-key rotation window so stored credentials can be re-encrypted before the previous key is removed. The production procedure is documented and guarded against accidental cross-environment use.

Supabase's current encryption controls are described in its Data Processing Addendum.

• GitHub Actions uses OpenID Connect to assume a scoped AWS deploy role; the production deploy does not require a long-lived AWS access key in GitHub.
• ECS service families use service-specific task roles. Runtime secrets are injected from AWS Secrets Manager through the ECS task execution role.
• Support access does not create implicit membership in a customer company. Cross-company platform-admin triage uses an explicit, read-only view-as mode; admin mutations use dedicated admin routes and the MFA step-up described above.

• Tenant-owned records are scoped directly by company or through a company-owned parent record. Global and internal tables are kept outside ordinary operator data paths.
• Authenticated company routes require a current membership. For routes addressed by a resource ID, handlers resolve the stored resource owner before granting access.
• Platform-admin status does not silently bypass ordinary company membership. Cross-company reads use explicit read-only view-as; privileged writes live under dedicated admin routes.
• A source-level route-guard check runs in CI, backed by regression tests for cross-tenant access boundaries.

• New worker admission is checked against available credits, configured project/company/operator budgets, concurrency limits, company status, and a production global daily cost circuit breaker. Optional project and tenant budgets add more granular controls.
• Agent-run and tool lifecycle events are written to company-scoped activity records. Stored activity details pass through sanitizing and projection rules before operator-facing display.
• 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. The provider registry describes the narrower, feature-specific services that support the product.
• Agent context retrieval is scoped to the current company and thread. The same membership checks protect the underlying company records used to assemble that context.
• The product streams agent and project progress to the operator. Stop or cancel controls are provided for active workflows where the workflow supports interruption.

• Application errors and sampled performance events flow to Sentry with default PII collection disabled. Server-side processing redacts sensitive headers, request bodies, URL credentials, structured PII, and secret-shaped free text before an event leaves the process; diagnostic context is limited to what remains after those controls.
• Sentry browser session replay remains disabled. PostHog replay is limited to explicitly approved routes. Ordinary interface text outside designated private regions and submitted chat with Ted's replies may be recorded as displayed. Input values and unsent drafts are masked, media and designated private regions are blocked, recorded URLs are sanitized, network header and body contents are omitted, and browser PostHog remains disabled under Global Privacy Control or Do Not Track. Replay starts only for signed-in operators in the United States after acceptance of the current Privacy Policy. Replay recordings expire after 30 days.
• Core production AWS service log groups are retained for 30 days. Hosted-app and API WAF log groups use a 14-day retention period. Other provider and data types follow their purpose-specific schedules.
• Company-scoped agent lifecycle records support the in-product activity view. Separate audit records cover selected account and administrative changes.

• Foundable account and product data: our primary production database has Supabase point-in-time recovery enabled.
• Supabase point-in-time recovery replaces the separate daily-backup schedule with continuous recovery points for the primary database.
• Databases for apps built with Foundable: point-in-time recovery is an opt-in project setting and can be enabled for an app project when required.
• Scheduled-backup availability and retention depend on each Supabase project's plan and configuration, so the applicable schedule and retention window are confirmed per app database. See Supabase's database backup documentation.
• Production migration files are append-only. Schema changes follow an additive-first policy; destructive, rename, and type changes require staged migrations.

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 deploy health checks, ECS deployment rollback, manual rollback, and integration-encryption-key rotation.

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.

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 personal information. Operator-authorized Foundable Ads delivery or measurement may constitute "sharing" under the CCPA; the feature is opt-in.
• 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.

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

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