Skip to content
Aura 4

Security & trust

Plain answers, not security theatre.

What we do today, what we don't, and how to verify either claim. If your procurement team can't answer their questionnaire from this page, email security@aura4.example and we'll fix the page.

Last updated · 2026-05-28

01 · Access control

Permissions are checked at the resource, not just the route.

Every read and write in Aura 4 goes through a per-resource permission check. Role-based middleware narrows the surface; ownership checks then confirm that the authenticated user actually owns (or shares membership with) the record being touched.

Roles are scoped to a workspace and team: a Lead’s privileges never reach beyond the team they lead. Service accounts and API tokens carry the same role checks as human sessions.

  • Argon2 password hashing.
  • Short-lived JWT access tokens with refresh rotation on use.
  • HttpOnly, Secure, SameSite=Lax session cookies for browser sessions.
  • Optional multi-factor authentication on every account.

02 · Tenant isolation

Workspaces are isolated at the database row level.

Every row in the operational store carries a workspace identifier. Every query is scoped through a single tenancy guard at the data-access layer; ad-hoc queries cannot bypass it. Cross-workspace joins are not possible from application code.

We use one logical schema with workspace-scoped data, not one schema per customer. We chose this consciously: it lets us upgrade the schema in one place and reduces a class of cross-schema configuration drift that creates its own incidents. The trade-off is that the tenancy guard is load-bearing — it is covered by integration tests and a policy lint that fails the build if a query lands without scoping.

03 · Encryption

In transit, at rest, and on the device.

Traffic between every client and our edge terminates on TLS 1.3 with HSTS pinned for two years (production only). Internal service-to-service calls use mutually authenticated TLS.

Data at rest is encrypted by the managed Postgres provider with AES-256. Backups are encrypted with the same key class and stored in the same region as the primary.

Local-first writes — the buffered work each Builder makes in Focus Mode — are stored in IndexedDB on the device. We do not persist the user's password or session token to IndexedDB; sessions live in HttpOnly cookies.

04 · Audit logging

Every state change is recorded.

Sensitive actions — role changes, exports, plan changes, deletions — are recorded in an append-only audit log per workspace. Each entry carries actor, action, target, source IP, and timestamp.

Audit log retention is 12 months on every plan. A self-serve export — NDJSON for ingestion into your SIEM — is on the roadmap; it is not available yet, and we would rather say so than imply a button that does not exist.

05 · Data residency

Your data lives in one region — the US.

Customer data is stored in our US region (Northern Virginia). We do not currently offer a choice of region, and we do not move customer data elsewhere. If EU data residency is a hard requirement for your team, tell us — it is on the roadmap, and we would rather say “not yet” than overstate it.

Data at rest is encrypted with AES-256, and backups are stored in the same region as the primary.

06 · Subprocessors

A short, named list — not a vague paragraph.

The companies that process customer data on our behalf:

  • Vercel — application hosting and edge network.
  • AWS (US-East-1) — managed Postgres, object storage, secrets management.
  • Resend — transactional and magic-link email delivery.
  • Sentry — error tracking. PII is scrubbed at the SDK boundary.
  • PostHog (US cloud) — product analytics. Cookieless on the marketing site; in-app sessions are tied to the authenticated user.

We notify workspace owners 30 days before adding or replacing a subprocessor. The current list is mirrored in the Data Processing Addendum (DPA) for Sovereign Enterprise customers.

07 · Vulnerability disclosure

security@aura4 — please, before you tweet.

Found a vulnerability? Email security@aura4.example with a description and reproduction steps. We acknowledge within 24 hours and aim to ship a fix within 7 days for critical issues.

We do not yet run a paid bounty programme; we offer a public hall-of-fame credit and a handwritten thank-you for valid reports. Out-of-scope: third-party services (report to them directly), social engineering, and physical attacks.

08 · Compliance

What we have, what we don't, and when.

We are not SOC 2 certified yet. We are running our own controls — least-privilege access, vendor reviews, change management, incident response — and we will be ready for SOC 2 Type 1 in the next 12 months.

Until then, we will not claim certifications we do not hold. If your procurement team needs SOC 2 today, you should choose another tool today and revisit us in twelve months — that's a fair trade.

We do honour GDPR data subject requests for EU customers and CCPA requests for California residents — see /legal/privacy.

Need the security questionnaire pack?

We maintain pre-filled answers to the SIG Lite, CAIQ Lite, and the common SaaS vendor questionnaires. Sovereign Enterprise customers get them on signing the DPA.