Built to be trusted by founders running real companies.

FounderOS holds the operating brain of real businesses. Anything less than a serious security posture would be a breach of the trust that lets the product exist. We design around five principles:

• Least privilege everywhere. No process, engineer, integration, or AI tool gets more access than it needs to do its job.
• Encrypt by default. In transit, at rest, and in transit again between internal services.
• Auditable by default. Every state-changing action is logged with actor, source, before, after, timestamp, correlation ID, and approval ID.
• AI cannot exceed its contract. Donna can only call functions defined as typed contracts. There is no "do anything" superpower, by construction.
• You can take your data and leave. Export and erasure are first-class features, not support tickets.

Hosting

FounderOS runs on a hardened cloud footprint with managed MongoDB Atlas as the primary system of record, regional isolation for EU and UK customers, and Cloudflare at the edge for DDoS protection and WAF rules.

Network

• All traffic terminates over TLS 1.2+ with modern cipher suites; HSTS is preloaded on the root domain and the app domain.
• Internal service-to-service calls travel inside private networks with mutual authentication.
• Public endpoints sit behind rate limiting, bot detection, and abuse protection. Suspicious traffic is challenged or blocked.

Encryption

• At rest: AES-256 on the database, on object storage, and on backups.
• In transit: TLS 1.2+ everywhere, including internal mesh traffic.
• Application-level: sensitive integration tokens and OAuth refresh tokens are encrypted in the application before they are written to MongoDB. Refresh tokens are kept in a dedicated secrets manager — they never live in plaintext in the database.

FounderOS is multi-tenant. Workspaces are logically isolated at every layer of the stack:

• Every database query is scoped to a workspace ID. Cross- workspace queries are prohibited at the data-access layer and verified by static analysis.
• Object storage paths and signed URLs include the workspace ID, with short expirations and IP / user binding where possible.
• Background jobs, AI tool calls, and webhook handlers all carry the workspace context as a typed argument, audited at the boundary.
• Customers in regulated industries can request additional isolation (region pinning, dedicated database cluster) on our higher plans.

Sign-in

• Email + password (Argon2id-hashed at the application layer), Google SSO, and Apple SSO at launch.
• SAML SSO and SCIM provisioning for paid team plans.
• Multi-factor authentication available for all users; required for Owners on paid plans.
• Session tokens are rotated, bound to device fingerprints, and revocable from Settings → Security → Sessions.

Internal access

Engineer access to production is gated by:

• hardware-backed MFA (FIDO2 / WebAuthn);
• time-bound elevated roles — privileged actions expire automatically;
• a logged justification for every elevation, reviewed asynchronously;
• full keystroke and command audit on production sessions, retained for security forensics.

We do not look at your workspace content unless you have asked us to (e.g. troubleshooting), or where required by law. When we do, the access is logged, scoped, and visible to you on request.

AI is the riskiest surface in any product that has one. Donna is built to be useful without being unsafe.

Strict tool contracts

Donna operates through a fixed registry of typed tools (for example, os.update_venture_status, comms.draft_email, delivery.create_jira_issue). Each tool has a schema, a permission scope, and a risk class. Calls outside this registry are impossible by construction — there is no "shell" tool, no "arbitrary HTTP" tool, and no escape hatch.

Approval gating

• Low-risk actions (notes, reminders, task creation) execute directly and are logged.
• Approval-required actions (status changes, outbound messages, connector writes) appear as structured action requests with a field-level diff, the rationale, the risk level, and an Approve / Reject button. Nothing happens until you tap.

Model providers and zero retention

The primary model provider is OpenAI, accessed via the OpenAI Responses API under a zero-retention agreement. Your prompts and completions are not retained beyond the request and are not used to train OpenAI's models. We never use your private workspace content to train shared models, full stop.

Prompt-injection defenses

• We separate trusted instructions (system prompts) from untrusted content (emails, calendar invites, integration payloads) at the protocol boundary.
• Tools that take consequential action require approval, even when an upstream document instructs Donna to act.
• Outbound integration writes are logged with the precise content sent, so injection attempts that slip through can be detected after the fact.

Integrations multiply the surface area. We treat them as a first-class subsystem with strict controls.

• OAuth scopes: we request the minimum scopes needed for the features you turn on, and we display the scope list before the consent screen.
• Token vaulting: access tokens are encrypted in the application before write; refresh tokens live in a dedicated secrets manager.
• Disconnect cleanly: when you disconnect, we revoke at the provider and delete the corresponding tokens from our vault.
• Webhook verification: every inbound webhook is verified (HMAC, signed JWT, or provider-specific signature) before processing.
• Read-only by default: writes back to a connected service require an explicit user approval.

Every state-changing action — by a human, by an integration, or by Donna — writes an entry to a tamper-evident audit log containing:

• actor (user ID, integration ID, or Donna session ID);
• source (web, mobile, API, webhook, AI);
• action (typed event name and version);
• before / after snapshot of the affected fields;
• timestamp and time-zone;
• correlation ID linking the event to the originating request chain;
• approval ID (where the action required your approval).

Customers on team plans can stream the audit log to their own SIEM. We retain hot audit data for 13 months and cold archives for up to 7 years for forensics and compliance.

• Code review: every change to production requires review by another engineer.
• Branch protection: direct pushes to main are blocked; merge requires passing checks.
• Static analysis & linting: typed code, workspace-scope checks, and SAST run on every pull request.
• Dependency scanning: automated scanning with timely upgrades for high-severity findings.
• Secret scanning: repository scanning blocks commits that leak credentials.
• Test isolation: CI runs against ephemeral, isolated databases. Production data is never used in development or testing.
• Penetration testing: independent third- party tests at least annually and after material changes.

When something goes wrong, we want it diagnosed quickly, contained, and communicated honestly.

• Detection: 24×7 alerting on availability, error rates, anomalous access patterns, and integration health.
• On-call: a dedicated rotation with escalation paths and pre-written runbooks for known categories of incident.
• Containment & eradication: we isolate the impacted system, revoke compromised credentials, and verify clean state before restoration.
• Notification: if an incident affects your data, we notify you without undue delay and within the timelines required by applicable law (typically 72 hours under GDPR).
• Post-mortem: blameless post-mortems with customer-shareable summaries for material incidents.

• Encrypted, point-in-time backups of the primary database, with rotation up to 35 days.
• Geo-redundant object storage for files and uploads.
• Documented disaster recovery plan with target RPO of 1 hour and RTO of 4 hours, exercised at least annually.
• Status page with public incident history at status.founderos.com.

We design FounderOS to be operationally aligned with the frameworks our customers need. Specifically:

• SOC 2 Type II — observation period underway. Letters available under NDA on request.
• GDPR / UK GDPR — Standard Contractual Clauses available; DPA on request.
• CCPA / CPRA — consumer rights honored globally regardless of jurisdiction.
• PCI DSS — card data is handled by Stripe and Paystack; FounderOS is out of scope for PCI on cardholder data and never sees full PANs.
• ISO/IEC 27001 — control mapping in progress.

A current security pack (architecture summary, subprocessor list, DPA, recent pentest letter) is available to enterprise prospects under NDA — write to security@founderos.com.

We engage a small set of subprocessors to operate the Service. Each has a written agreement requiring security and privacy practices at least as protective as ours.

We notify customers in advance of material changes to this list.

We take security reports seriously and we want to make it easy to do the right thing.

• Report vulnerabilities to security@founderos.com with a clear description and reproduction steps. PGP key available on request.
• Please give us a reasonable window to remediate before any public disclosure. We will keep you updated on triage and fix progress.
• We do not currently run a public bug bounty, but we recognize meaningful research with credit on our security page and (where appropriate) financial reward.
• Out of scope: denial-of-service attacks against production, social engineering of our team or customers, physical attacks, and reports based solely on missing best-practice headers without exploitable impact.

Security is not just what we do — it's what you can do from inside the product. Today you can:

• require MFA for every workspace member;
• see and revoke active sessions across web and mobile;
• switch Donna to Advise or Propose mode so no AI action ever executes without your tap;
• review every action in the audit log, filter by actor, source, and venture, and export it as JSON;
• disconnect any integration in one click, with clean revocation at the provider;
• export everything, delete everything, and walk away — Settings → Data.

• Security reports: security@founderos.com
• Compliance & vendor questionnaires: security@founderos.com
• Status page: status.founderos.com