Security, privacy & compliance

Outbound connector/workflow requests are blocked against loopback, link-local, cloud-metadata (169.254.169.254), and private ranges — after DNS resolution and with 3xx-redirect rejection to defeat bypasses.

Office/ZIP uploads are bounded by streaming entry-count, per-entry, and whole-archive size limits enforced during inflation, defeating decompression bombs.

A fixed-window limiter with spoof-resistant client-IP derivation returns 429 with Retry-After. It is per-instance (the deployment pins a single replica); a shared store is required before horizontal scale-out.

Every response carries CSP, HSTS preload, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy, and Permissions-Policy. The CSP still allows inline script/style; nonce-based hardening is a follow-up.

Mutating requests are checked with an Origin-vs-Host comparison at the edge; machine endpoints use their own key/token auth.

Connector OAuth uses single-use, TTL-bounded, workspace-bound state with a double-submit cookie layer, so authorization callbacks can't be replayed or cross-bound.

Every change runs lint, strict type-checking, and a security-focused test suite (hundreds of cases, including hostile-input tests) before merge.

CI runs Semgrep SAST, Trivy dependency/misconfig scanning (gating on fixable critical dependency vulnerabilities), an SBOM (CycloneDX/SPDX), and Gitleaks secret scanning.

A boot/preflight policy refuses to start a production-like deployment when a mandatory control (session secret, encryption key, single-tenant invariant) is missing or unsafe.

Pull requests receive an automated independent review pass in addition to human review.

The application container runs as a non-root user.

An independent third-party penetration test has not yet been performed; it is on the roadmap.

Password accounts use per-user salted scrypt with constant-time verification; login is timing-equalised against user enumeration.

HMAC-SHA-256 signed httpOnly session cookies with expiry and a per-user epoch, so sign-out-everywhere and password changes invalidate sessions platform-wide.

Email one-time-passcode verification is supported alongside password sign-in.

SAML uses signed assertions (SHA-256), audience restriction, clock-skew bounds, single-use assertion replay caching, and HMAC-signed RelayState for CSRF.

OIDC uses authorization-code + PKCE (S256), RS256 id_token verification against JWKS, and issuer/audience/expiry/nonce checks.

SCIM 2.0 user/group provisioning is supported for identity-lifecycle automation; the customer configures it against their IdP.

First-party TOTP (RFC 6238) with authenticator-app enrollment, one-time recovery codes, and single-use anti-replay. A second factor is challenged on password and email-code sign-in via a short-lived, purpose-separated token; workspaces can prompt members to enrol it (org-wide request-time enforcement is planned). SSO sign-ins keep MFA at the identity provider.

A namespaced capability registry grants area.action permissions to admins, everyone, or groups; unknown capabilities fail closed as not-granted.

Every chunk, fact, and skill carries audiences; retrieval filters to the requesting user's individual clearance before ranking, so restricted content never reaches the model.

Workspace admin is a management capability, not see-all; browsing all tenant content is not granted by default.

Requests run inside an AsyncLocalStorage workspace context; the per-tenant secret store is keyed by that context so cross-tenant access is impossible by construction.

Workspace membership is re-verified on every request, so deprovisioning or offboarding takes effect immediately.

Tenant-scoped credentials — AI provider API keys and Slack/Notion/Jira/GitHub/Voyage tokens — resolve per workspace through an encrypted per-workspace secret store keyed by the request's workspace context, with no fallback to a shared global value (an unset secret reads as absent — fail-closed). Provider/model/endpoint config is per-workspace, and Microsoft/Google connected accounts are bound to their owning workspace. GET/POST /api/settings only ever touch the caller's workspace; deployment-level platform credentials (the OAuth app registration and domain-wide-delegation service account) are platform-managed and never exposed through a tenant route.

Settings, credentials, tenant secrets, audit log, and lifecycle ledgers are sealed with AES-256-GCM (random IV + auth tag). In production, writing plaintext at rest with no key configured is refused.

Traffic is served over TLS (terminated at the platform ingress) with HSTS preload; outbound server requests require HTTPS.

Ciphertext carries the key id it was sealed under (enc:v2:<keyId>:…), so keys can rotate without re-reading every field up front.

Multiple data-encryption keys with an active-key id are supported; new writes seal under the active key while older ids still decrypt, with a re-encrypt sweep to retire them.

Boot/preflight refuses to start production with a weak or default encryption key (minimum length and character-diversity checks).

Envelope key management is implemented behind the key-provider seam: per-file data keys are wrapped by a KMS-held key, and an Azure Key Vault adapter (REST wrapKey/unwrapKey) ships. Enable with KMS_PROVIDER. Marked in progress pending verification against a live vault; AWS KMS is a later adapter on the same interface.

Envelope encryption is in place: data-encryption keys are wrapped by a key-encryption key (KEK) and only the wrapped form is stored, so revoking the KEK makes stored data unrecoverable at the next process start — the data keys are unwrapped once at boot and held in memory, so a still-running process keeps decrypting until teardown; revocation takes effect on restart, not live. The on-prem/local-KEK reference path is implemented and verified end-to-end (production boot with no DATA_ENCRYPTION_KEY — the KEK wraps the data keys instead — plus encrypt/decrypt, restart-survival, and fail-closed on a wrong/revoked key at boot), and the Azure Key Vault adapter ships behind the same seam (validation against a live vault still pending). Both are deployment-level today: a single KEK protects the whole deployment. Rotation requires provisioning a fresh DEK (scripts/provision-cmk.mjs --rotate) and running the re-seal sweep. For Azure, creating a new Key Vault key version does not by itself migrate existing DEKs: their wrapped entries remain bound to the original key version, which must remain enabled for startup. Retiring an old Azure or local KEK version is not supported until a KEK rewrap-and-removal workflow exists. A per-tenant, customer-held KEK — where each workspace holds and revokes its own key independently — is the remaining work and depends on tenant-scoped keys.

Every LLM, embedding, and OCR call passes a single egress boundary that evaluates deployment + tenant policy and audits the decision (capability/provider/classification only — never prompt content) before the provider is invoked. Policy-load failures fail closed.

The gateway takes the strictest of the request class and the tenant's declared sensitivity, so e.g. PHI-classified data can be forced to a permitted provider.

Retrieved and imported content is fenced with distinctive untrusted-content markers and provenance labels, and imported skills are quarantined from automatic execution.

Agent output is screened for leaked secret patterns (API keys, private keys) before egress; enforcement is advisory unless strict mode is enabled.

Answers are grounded only in the workspace's own content with inline citations; when the answer isn't present, the system says so rather than inventing one.

Configurable no-training / zero-retention profiles for AI, embedding, and OCR subprocessors are being built.

Security-relevant events are appended to a keyed hash chain: each record is HMAC(prevHash + record) under an audit key derived from the data key, so altering or reordering any record is detectable.

A verifier detects hash mismatches, record injection, and tail truncation (via an off-volume head anchor); it reports whether the chain is keyed (tamper-evident) or unkeyed (corruption-only).

User- and workspace-scoped legal holds with a required basis are consulted before any destructive lifecycle step, which records a retained-with-basis outcome. Reads fail closed.

Erasures are recorded as encrypted, fail-closed tombstones (users and tenants), deliberately excluded from snapshots so a restore can't resurrect an erased subject.

Deletion, tenant-deletion, and export receipts are HMAC-SHA-256 signed with a purpose-separated key; in production the system throws rather than emit an unsigned receipt.

A retention scheduler and lifecycle orchestrator exist; customer-configurable per-tenant retention windows are still maturing.

The tamper-evident audit trail can be streamed to a SIEM (Splunk HEC, Microsoft Sentinel, or a generic HTTPS webhook), where it becomes the immutable long-retention copy. Only a redacted subset leaves the process — no email, IP, or free-form detail, and email-shaped identifiers are pseudonymized — carrying each record's seq and its opaque chain-hash anchor, plus a persisted cursor that makes delivery at-least-once and gap-detecting. The SIEM can therefore detect a missing record (seq gap) and pin an exported record to its chain position, but it cannot itself recompute the HMAC — the redacted payload and the audit key never leave the process — so full tamper-evidence (that no record was altered) is proven by the source's own keyed chain verifier, not reconstructed at the SIEM. Today the export is DEPLOYMENT-WIDE and operator-configured (the whole deployment's audit trail streams to one operator-owned endpoint via env) — suited to a single-tenant / self-host deployment. Per-tenant SIEM routing (tenant-scoped export credentials and records, so a workspace streams only its own events) is the remaining work; on a shared deployment this stays operator-only, never a per-tenant feature. Verified end-to-end against an HTTPS sink.

Rolling snapshots of the data files (including the encrypted stores and audit log) are taken on a throttled schedule and rotated to the last 24.

A restore-verification job decrypts every envelope in the restored data under the escrowed key (a wrong key fails the GCM tag) with a vacuity guard, so a 'successful' restore is proven decryptable, not just present.

Backup and restore-drill workflows run in CI so the recovery path is exercised, not just documented.

Restores re-apply erasure and tenant tombstones (fail-closed), so recovering a snapshot can never revive an erased subject.

A disaster-recovery plan, restore-test procedure, and RPO/RTO register are maintained in the compliance program.

Backups live on the same platform volume today; cross-region redundancy and guaranteed data residency are roadmap items.

The application runs as a single instance today; moving to a multi-instance, higher-availability architecture is underway.

Content ingested into a workspace belongs to that workspace; the product embeds no third-party analytics or tracking SDKs.

User prompts/questions are not persisted after processing.

Documents are fully removed on delete (cascading to derived facts/chunks); account and tenant erasure are recorded in the erasure ledger with signed receipts.

Sensitive-data classification gates which providers may process a request; automated PII detection/redaction across all ingested content is maturing.

A lifecycle retention engine exists; customer-configurable retention windows per data category are still being finished.

Guaranteed data residency and region pinning are not currently supported.

Data-processing terms, breach-notification windows, and audit rights are established under a signed agreement.