Security

Your data stays with you.

OurStack is built so the apps you create never copy your business data onto our infrastructure — on Pro, Team, and Enterprise alike. Below is the concrete list of controls behind that promise — no marketing adjectives, just what actually runs in the codebase today.

Data model

How data flows when your apps run.

01

Your users, your apps

Your employees open apps at yourteam.ourstack.ai or your custom domain. The app's UI is served from OurStack's managed runtime (or from your AWS, on Enterprise).

02

Your integrations

When the app needs data, it calls your connected integrations directly — Gmail, Chargebee, Postgres, whatever you configured. Credentials are read from your Secrets Manager at request time.

03

Your database

Application state lives in the database you chose — your Postgres, Supabase, Airtable, or Sheets. OurStack's database never receives, caches, or replicates this data.

What OurStack does store on our side: the spec for each app you build, version history, build logs, and audit events (sign-ins, role changes, admin actions, AI telemetry). This is operational metadata about the apps themselves — not the data your apps process.

Controls

What we protect, how we protect it.

  • Data isolation

    Your application data never lives on our infrastructure.

    The apps you build on OurStack read and write business data directly between your users and the databases, APIs, and services you already control. OurStack stores only the design of the app — the spec, build history, and audit log.

    • Application payloads (customer records, invoices, emails, whatever your apps touch) live in your database, not ours.
    • Integration credentials live in your AWS Secrets Manager — OurStack stores pointers, never secret values.
    • Per-workspace row-level security on every table in our database. A member of workspace A cannot read any row belonging to workspace B, even through a compromised API route.
    • Admin-only RLS on sensitive rows (capability config, audit events, beta requests) — member roles cannot read them by design.
  • Authentication & access

    Workspace membership gates every route.

    Sign-in runs through our managed authentication provider with Google OAuth today; SAML / OIDC SSO with SCIM provisioning is available on Enterprise. Every authenticated route verifies workspace membership before returning data.

    • Google OAuth with session refresh middleware.
    • Enterprise: SAML or OIDC against your IdP (Okta, Entra ID, Google Workspace, JumpCloud), SCIM auto-provisioning, enforced SSO with no personal-account sidecar.
    • Builder / member / admin roles with separate permissions; admin-only API routes verify the role explicitly.
    • Private beta gate controls who can create an account today.
    • Enterprise: IP allow-list for the admin console.
  • Encryption

    In transit and at rest, end to end.

    TLS on every hop, AES-256 at rest in every storage layer, and HMAC signing on webhook callbacks so customers can verify calls came from OurStack.

    • HTTPS / TLS 1.2+ for every client-to-server and server-to-server call.
    • AES-256 at rest across our managed data stores, our runtime deployments, and anything written to your AWS Secrets Manager.
    • HMAC-SHA256 signing on every outbound webhook so customer endpoints can verify calls came from OurStack.
    • Platform-vs-customer credential split: OurStack's own Anthropic key powers the builder; your `/admin/models` connections are never read by OurStack's code paths.
  • PII handling

    Default redaction runs inside your apps. Your own redactor overrides.

    OurStack ships a lightweight PII redactor in every generated app by default — no configuration required, raw text never leaves your data path. Customers who need enterprise-grade accuracy connect their own redactor via webhook, and the default stands aside.

    • Default redactor runs in the generated app's runtime (Vercel or Lambda). Raw text, redacted text, and token maps never transit OurStack's backend.
    • Bring your own redactor by pointing `pii.redact` at any HTTPS webhook — OneTrust, BigID, Privacera, Skyflow, Piiano, Google DLP, Azure, Microsoft Presidio, AWS Comprehend, or an in-house service.
    • Webhook bodies signed with HMAC-SHA256; receivers verify via `X-Ourstack-Signature` before processing.
    • Fail-closed when `pii.redact` is declared required in an app spec: if the configured redactor is unreachable, the app's AI step refuses to run rather than leak raw text downstream.
  • Logging & audit

    Every mutation writes an audit row.

    One `audit_events` table captures user actions, system errors, and AI telemetry, typed by a documented event enum. Admins can review and filter activity in `/admin/audit`; Enterprise customers can export the stream to their SIEM.

    • `withAudit` wraps every API route mutation — no mutation escapes the audit trail.
    • `withAiTelemetry` captures token usage and latency on every Anthropic call. Tier-1 errors land in the same table for a single observability surface.
    • Structured logger (`src/lib/log.ts`) normalises errors into JSON-safe shapes. Bare `catch {}` is ESLint-blocked across the codebase.
    • Audit retention: 30 days on Pro, 90 on Team, unlimited with CSV / JSON export on Enterprise.
  • Operational security

    Least privilege by default, fail-closed on ambiguity.

    The CloudFormation templates that deploy into customer AWS accounts grant only the minimum permissions needed for the app to run. Input sanitisation runs before data hits any sensitive sink. When something breaks, we fail loudly rather than degrade silently.

    • CloudFormation template grants scoped IAM — ECR, Lambda, Secrets Manager permissions are narrowed to `ourstack/*` resource patterns.
    • `AuthType: AWS_IAM` on Function URLs for customer-AWS deploys; no anonymous public exposure by default.
    • Admin-submitted CSS for workspace branding is sanitised against injection before landing in `:root` overrides.
    • Platform AI failures surface a loud error rather than silently falling through to a customer-owned credential.
    • Secrets Manager fallback alert: if a production workspace ever falls back to plaintext secret storage, OurStack writes an error-level audit row and notifies admins.
  • Data residency

    EU-region by default.

    OurStack's operational metadata (workspace records, audit events, integration pointers) is stored in the EU (`eu-west-1`). Your deployed apps run in whichever region you choose — Pro / Team use our managed runtime's nearest edge, Enterprise picks the AWS region when provisioning the customer-AWS stack.

    • Workspace + audit metadata defaults to Frankfurt. US region on request.
    • Generated apps on OurStack-managed infra run on Vercel's regional edge.
    • Enterprise (customer-AWS) tier deploys into whatever region your CloudFormation stack sits in.
    • No cross-region replication of customer data without an explicit DPA amendment.
  • Supply chain

    Dependencies pinned, providers adapter-wrapped.

    Third-party code is locked by version and reviewed when upgraded. LLM and cloud providers sit behind adapter interfaces so swapping one in a security incident doesn't require an emergency rewrite.

    • All npm dependencies pinned to exact versions in `package-lock.json`.
    • AI providers wrapped behind `src/lib/ai/providers/` — a compromised vendor SDK is replaceable at the adapter seam.
    • Cloud deploy adapters likewise isolated (`src/lib/deploy/*`) so a cloud-level security pivot doesn't cascade across the codebase.
  • Runtime isolation

    Two deploy tiers, two trust postures.

    Customers pick how much they want us involved. The default is managed; regulated or air-gapped workloads run entirely in the customer's own AWS account.

    • OurStack-managed (Pro / Team): apps run on Vercel under OurStack's team. Credentials are injected as encrypted Vercel env vars at deploy time.
    • Customer-AWS (Enterprise): apps deploy into your AWS account via CloudFormation. OAuth refresh runs in-Lambda and writes back to your Secrets Manager — tokens never transit OurStack's servers.
    • Identical product surface across both tiers; only the trust and compliance posture differ.
Compliance

Where we stand, honestly.

GDPR
By design. Customer application data lives in customer infrastructure; OurStack processes only operational metadata. EU-region default for workspace data. Data Processing Agreement available on request for paying customers.
SOC 2 Type II
We've built OurStack against SOC 2 Type II controls from day one: access logging on every mutation, least-privilege IAM, encryption in transit and at rest, incident response procedures, pinned dependencies, structured audit trail.

We haven't started a formal audit yet — at our stage that money is still better spent on product. We expect to begin the observation window once we reach our first enterprise commitments. If you need attestation to sign, we'll tell you honestly where we are, walk your security team through our controls on a call, and fill out a security questionnaire (CAIQ, SIG Lite, or custom) in the meantime.
ISO 27001
Same posture as SOC 2 Type II. Controls implemented; formal certification on the roadmap.
HIPAA
Not certified. Apps that process PHI should deploy on the customer-AWS tier, where PHI never transits OurStack infrastructure. Contact us before signing — we'll be straight with you about whether your use case fits today.
DPA, MSA, questionnaires
Available on request for paying customers. Enterprise contracts include a signed Data Processing Agreement and custom MSA as standard.
Responsible disclosure

Found something? Tell us.

Report security issues to security@ourstack.ai. We respond within one business day and won't take legal action against researchers acting in good faith. Please give us a reasonable window to fix before publishing.

Security review

Need a questionnaire or a call?

We'll walk your security team through the controls above, share a completed questionnaire, and answer anything you need to sign. No NDA required for the intro call.

Talk to a founder