Security overview

How we keep your work safe.

Version 1.0 · Effective May 15, 2026

Cruma is private-beta software with production data running through it. Security isn't a checklist for marketing — trust is a primitive, baked into the product architecture. This page is the public version of how we approach it. The contractual version is the DPA §6.

Beta caveat. Cruma is in private beta. We do not yet have a SOC 2 or ISO 27001 report. We follow the practices below and will pursue formal certification when the cohort and roadmap warrant it (post-V1.5). Until then, enterprise customers should treat this overview as a current-state description, not a long-running attestation.

1 · Architecture

TLS 1.2+ everywhere in transit. HSTS preloaded; HTTPS-only.
AES-256 at rest for database storage, backups, and object storage.
OAuth tokens are encrypted with envelope encryption. Application code reads tokens through a wrapper that decrypts on demand; raw cipher-text never leaves the database.
Row-level security (RLS) at the database layer on every workspace-scoped table. A query from your workspace literally cannot read another workspace's data — the database refuses.
Workspace isolation. Service-role queries (used by background agents and webhooks) can cross workspace boundaries only for explicit, audited operations.

2 · Access control

Least-privilege service roles. Each background service has the minimum database role it needs; no service runs as a database superuser.
MFA on production-system access by Cruma personnel (cloud console, database console, deployment pipeline).
No personal-device production access. Production credentials are scoped to specific hardware and revoked on departure.
Audit logging on cross-workspace operations and break-glass reads.

3 · AI provider security

Named AI providers are listed at /legal/subprocessors.
No training on your data. Provider terms used in Cruma's deployment do not authorize training on inputs/outputs. We do not opt in to "consent to train" programs on your behalf.
Minimum-content principle. Skills pass the minimum context required to do their job; we do not push full workspace state into every prompt.
Prompt-injection mitigation. Untrusted content (incoming emails, scraped pages) is processed in skills designed to recognize and contain instruction-injection attempts. Skills with high-risk side effects (sending mail, calendar holds) require approval-rail review.

4 · The approval rail

Cruma is built around a glass-box approval model: high-risk actions (sending mail, booking meetings, writing externally-visible content) propose-and-wait for your review. The approval rail is not a feature; it is the OS-level permission layer of the product, enforced at the skill-runtime boundary. Bypassing it is a contractual violation under the AUP §4.

5 · Vendor & sub-processor review

Every new third-party dependency is reviewed for license, supply-chain risk, and data-handling practices before adoption.
Sub-processor categories are published at /legal/subprocessors.
For B2B customers under the DPA, we give 30 days' notice before adding or replacing a sub-processor that processes Customer Personal Data.

6 · Vulnerability disclosure

If you discover a security vulnerability in Cruma, please report it to security@cruma.ai. We follow RFC 9116 (security.txt); machine-readable contact info is at /.well-known/security.txt.

Acknowledgment within 72 hours.
Triage within 7 days for high/critical issues.
Safe-harbor. Good-faith security research conducted under this policy is welcomed and will not result in legal action, provided you do not access, modify, or destroy data that isn't yours; do not violate other users' privacy; do not perform DoS; and give us a reasonable window to fix before publication.

7 · Incident response

Personal Data Breach notification within 72 hours of becoming aware, per DPA §8.
Notices include: nature of the breach, affected categories of data and Data Subjects, likely consequences, and measures taken.
Status page (post-launch) will publish ongoing incidents and remediation.

8 · Dependency & supply-chain hygiene

License audit on every new dependency (MIT / Apache-2.0 / BSD / ISC only for embedded code — no AGPL / GPL).
Dependency-scanning on every pull request (vulnerability + license).
Lockfile-pinned versions; no transitive auto-bumps without review.

9 · Data retention & deletion

Specific retention windows are published in the Privacy Policy §7. Hard-delete on workspace deletion; backups age out on a 30-day cycle.

10 · Roadmap

SOC 2 Type I targeted within ~12 months of paid-tier launch.
SAML SSO for workspace admin access at the enterprise tier.
Audit-logged break-glass for any support read of workspace-scoped data, with customer notification on read.
Bring-Your-Own-Key (BYOK) for enterprise customers wanting encryption-key control.

11 · Contact

Vulnerability disclosure: security@cruma.ai
Privacy / data requests: privacy@cruma.ai
Legal: legal@cruma.ai