StartOS Trust Center
StartOS holds private financial and people data: salaries, cap tables, bank balances, tax IDs. We treat that data with the controls a CFO and a CISO would expect. This page is the public version of our internal security tracker; everything listed here is shipped, in progress, or explicitly on the roadmap with a target date.
Last updated: June 4, 2026
StartOS is a pre-launch, pre-revenue B2B SaaS platform. We have not yet completed a SOC 2 Type II audit. That's on the roadmap for the post-funding milestone (see below). What we DO have is a foundation of concrete, code-level controls that map to the SOC 2 trust service criteria. Every claim below points at the actual implementation.
Honest summary:the gap between what we claim and what we deliver is zero, and the roadmap is public. We'd rather under-claim and demonstrate, than over-claim and lose your trust on the first audit response.
Identity provider
Supabase Auth handles all account login. Email/password or magic link. Session cookies are secure-flagged, HTTP-only, SameSite=Lax.
Password requirements
Minimum 8 characters with complexity enforced by Supabase. Hashing via bcrypt. Account lockout after repeated failed logins.
Two-Factor Authentication (TOTP)
Optional second factor for sign-in. Users enroll via Settings → Profile, scanning a QR code with any standard authenticator app (1Password, Authy, Google Authenticator). Sign-in enforces the second factor for every enrolled user via Supabase's AAL2 contract.
SSO / SAML for enterprise
SAML federation via Supabase SAML provider. Trigger: first enterprise prospect requires it.
Target: On request
Row-Level Security (RLS)
Postgres RLS policies enforce tenant boundaries at the database layer. Even if application code had a bug, the database refuses cross-tenant queries.
Per-request org-membership resolution
Every API route resolves the caller's organization via a single audited helper (`getOrgMembership`). A CI guard fails the build if any new route bypasses this helper.
Segregation of duties on financial actions
Bill approval requires two distinct gates (recognition + payment). Optional strict-mode enforces different users for each gate. Permissions are decoupled from system role so 'CFO who can approve payments but cannot edit settings' is configurable.
Period close locks
Once an accounting period is closed, retroactive postings are refused at the engine level. Same enforcement on year-end close + AP/AR subledger locks.
Encryption in transit
TLS 1.2+ on every connection. HTTPS-only via Vercel's automatic certificate provisioning. HSTS headers.
Encryption at rest (database)
Supabase Postgres is encrypted at rest by the provider.
Application-layer encryption for sensitive fields
Integration credentials (API keys to Stripe, Plaid, HubSpot, etc.) and tax identifiers (SSN/EIN) are encrypted with AES-256-GCM using envelope encryption. Each row has its own 256-bit data encryption key wrapped by a customer-managed master key in AWS KMS (eu-west-3). The master key never leaves AWS; every decrypt call is recorded in CloudTrail. The data is unintelligible to an attacker who exfiltrates the database without also compromising the IAM role.
KMS-grade key custody (production)
Envelope-encryption is active in production. The platform's previous single-key fallback (SECRETS_KEK) has been retired from production environment variables; key material lives entirely in AWS KMS. Annual automatic key rotation is enabled. KMS resolves the correct historical version when decrypting stored DEKs, so rotation is zero-downtime.
Audit log for high-sensitivity actions
Every invoice approval, bill approval/payment, period close, year-end close, vendor credit issuance, and similar action writes an audit-log row with actor, timestamp, IP, and structured metadata. Queryable from /accounting/audit-log.
Per-call audit log for AI tool execution
Every Iskra tool invocation (in-app, via Slack, or via the MCP server) is logged with input, output, duration, and error state. Used for both security audit and tool-quality monitoring.
Off-platform log aggregation
Structured JSON log lines from every Vercel runtime (server actions, API routes, scheduled functions) are forwarded by Vercel Log Drains to Axiom. Every audit-log event written to the in-DB AuditLogEntry table is simultaneously emitted as a structured log line tagged audit:true, so a SOC 2 auditor has two independent paths to verify any single event happened. PII (emails, names, tax IDs) is redacted at the logger boundary before any line reaches the off-platform stream; the in-DB table keeps the full PII for the customer-facing audit log UI. Internal admin viewer at /admin/logs queries Axiom directly for triage.
StartOS uses AI agents to read, classify, and (with your authorization) write to your books. The controls below exist so the AI can't make claims it can't back, can't take an irreversible action without your hand on the wheel, and can't cost you anything you can't see.
Numeric fidelity: deterministic answers, no hallucinated math
Every Iskra answer about your data is backed by a typed, Prisma-backed tool call against your GL. The AI does not do arithmetic; the database does. A NUMERIC FIDELITY system-prompt rule enforces that any number in an answer must appear verbatim in a tool response. A nightly + weekly eval harness (`scripts/iskra-eval/`) regression-tests 202 corpus items and fails the build on accuracy drops.
Preview → Apply → Undo on every state-changing AI agent
No AI agent posts a journal entry, sends an email, or applies a payment without an explicit two-step pattern: Preview returns what WOULD happen, Apply commits with an audit trail tagging the originating workflow run, Undo reverses cleanly. Email-sending agents add dedup windows (24h investor email, 7d AR reminders, 24h CFO digest) so you can't double-fire. Bank auto-match returns proposals; you Apply per-match or in batch. Full pattern documented in our internal Agent Design Rubric. Every state-changing agent in production complies.
Per-call AI cost + token logging
Every LLM call (Iskra tools, Iskra chat, IskraFlow interpret, AI bill reader, flux narrative, etc.) writes a structured `AiUsageRecord` with model, provider, token counts (input/output/cache-create/cache-read), USD cost, calling-feature attribution, and tenant scope. You can audit AI spend per-agent + per-period; we can detect cost regressions before you see them on a bill.
Refusal classifier on every Iskra answer
A secondary Haiku classifier runs post-response on every Iskra answer, flagging paraphrased refusals (`I don't have access to that data`, `outside my scope`) that escape exact-string match. Catches scope-violation attempts + tracks Iskra's refusal discipline as a quality metric.
Tenant scope enforced inside tool executors
Every Iskra tool validates the target organization against the caller's allowed-orgs set inside the executor, not the prompt, not the LLM. A model that hallucinates an `orgId` will be refused at the tool boundary with an error message the LLM can self-correct from. Portfolio (VC/PE) tools enforce firm-membership the same way.
Rate limiting
Sliding-window rate limits on every API route. Sensitive auth endpoints get stricter caps (5/min, 30/hr). Standard endpoints are 120/min, 2000/hr. Per-user keying on authenticated routes; per-IP otherwise.
Input validation on mutation routes
Zod schemas validate every incoming mutation request before it touches the database. Prisma's parameterized queries prevent SQL injection on every DB call.
Dependency scanning
GitHub Dependabot opens PRs for any new CVE in our dependency tree. `npm audit` fails CI on any high or critical CVE in the dependency tree, blocking the merge. Re-runs every Monday morning to catch CVEs disclosed after a PR has already merged.
Secret scanning
gitleaks scans every PR and every push to main for accidentally-committed API keys, AWS keys, private keys, and similar credentials. Full git history is scanned, not just the diff; secrets leaked in older commits are still leaks today.
Status page
Public status page showing uptime and any active incidents. Hosted by Better Stack with a 3-minute uptime probe against startos.io from multiple regions. Visitors can self-subscribe to incident notifications.
status.startos.io →Incident response runbook
Documented procedure for security incidents: detection, containment, customer notification timelines, post-mortem cadence. 5-phase response (Detect → Contain → Eradicate → Communicate → Review) with severity tiers, containment-action playbook, communication templates, and post-incident review template.
EU hosting
The primary Supabase project hosting customer data is in eu-west-3 (Paris). Customer data does not leave the EU unless you explicitly sync it to a third-party service you control.
GDPR right-to-erasure flow
Self-serve deletion request form (authenticated or anonymous). Hard-deletes auth + memberships + API keys; anonymizes Contact/Employee PII; retains financial records (invoices, bills, transactions) under tax/audit legal hold per GDPR Article 17(3)(b). 30-day response window. Every processed request writes a detailed audit log.
Request deletion →DPA (Data Processing Agreement) template
Lawyer-reviewed Standard Contractual Clauses for EU customers.
Target: Tier 2
SOC 2 Type II
Engagement with Vanta starting in Tier 2 (next 1-2 weeks). Full Type II attestation targeted for 3-6 months post-funding milestone. We'll publish the SOC 2 report under NDA to customers once available.
Target: Q4 2026 / Q1 2027
External penetration test
Focused scope: web app + API + MCP server. Pre-launch milestone. Report will be summarized publicly + available in full under NDA.
Target: Pre-launch
SIG Lite questionnaire
A pre-filled SIG Lite security questionnaire is available on request. Email security@startos.io.
We use the following third-party services to operate StartOS. Some are always-on (database, hosting, email); others are activated only if you explicitly connect them as integrations. We do not send customer data to a third-party service unless you have explicitly authorized that integration.
| Service | Purpose |
|---|---|
| Supabase | Database, authentication, storage |
| Vercel | Application hosting, edge network, and cookieless web/performance analytics |
| AWS | KMS for envelope encryption |
| Resend | Transactional email |
| Stripe | Payment processing |
| Anthropic | LLM for Iskra (Claude) |
| OpenAI | AI Spend + L4 categorization |
| Plaidif connected | Bank connection sync |
| HubSpotif connected | CRM sync |
| Salesforceif connected | CRM sync |
| Gustoif connected | Payroll sync |
| Cartaif connected | Cap table import (one-time) |
| Bill.comif connected | AP sync |
| Anrok / Avalaraif connected | Sales tax calculation |
| Ramp / Brexif connected | Corporate card sync |
| QuickBooks / Xeroif connected | Migration import (one-time) |
| Snowflakeif connected | Cost / SPCS revenue sync |
| GCPif connected | Vertex AI cost sync (BigQuery) |
| Toggl / Harvestif connected | Timesheet sync |
| Slackif connected | Slash commands + DM Iskra |
If you believe you've found a security vulnerability in StartOS, please report it to security@startos.io, or see the structured policy at /.well-known/security.txt.
Our commitment: we will acknowledge receipt within 2 business days, share an initial assessment within 5 business days, and provide regular updates until the issue is resolved. We do not currently run a paid bug bounty program but we will publicly acknowledge contributions (with your permission) on this page once we have anything to acknowledge.
Please don't:attempt to access data that isn't yours, perform denial-of-service testing without prior coordination, or publish details before we've had a chance to remediate.
Security questions, customer security questionnaires, or SIG Lite requests: security@startos.io
Privacy / GDPR / data subject requests: privacy@startos.io