Trust & Security

Your data stays on your infrastructure

AI OS is distributed as open-core, self-hosted software. In the default deployment, you run it on your own VPS or server and you are the custodian of your own data — conversations, CRM records, generated sites, and API keys live in files on your host, not on a vendor cloud. The vendor does not receive your operational data.

There is one exception, stated plainly: the optional Managed / hosted offering, where AI OS operates the instance on your behalf. In that model we operate the environment, and it is the scope we would put through a formal security audit (see Compliance status).

The trade-off of self-hosting is honest too: because you run the environment, a meaningful share of security is your responsibility — see Shared responsibility.

Security controls built into the platform

These are controls that exist and are enforced in code today. We describe them without embellishment.

Access control & authentication

• Default-deny RBAC. Admin and client roles are gated by middleware; a client-surface allowlist denies anything not explicitly permitted, and multi-tenant features scope every record to its owner.
• Password hashing. Passwords are hashed with bcrypt (cost factor 12). Sessions use random tokens with a fixed expiry and httpOnly, SameSite cookies (Secure in production).
• Fail-closed admin seeding. In production the first admin must be provisioned from environment secrets — there is no hardcoded default account.

Human-in-the-loop approval gate

Irreversible or outward-facing actions (publishing a site, pushing to an external repo, an agent calling a connected tool) pass through a server-enforced approval gate. Under the default “supervised” mode these actions queue for a human to approve rather than running automatically, and secrets are stripped before an approval is stored. You choose the automation posture; it is not automatic by default.

Application security

• SSRF-pinned outbound fetching that blocks requests to private/loopback addresses on untrusted input.
• Prompt-injection fencing — untrusted content is wrapped and treated as data, not instructions.
• Output escaping against XSS, argv-based command execution (no shell string interpolation), and request-body validation on sensitive endpoints.
• Secret hygiene — API keys are masked in API responses; GitHub tokens are never persisted; the install script restricts permissions on the secrets file.

Integrity & verification

• Content provenance. Generated sites can be signed with Ed25519 and verified. This is aligned with C2PA vocabulary but is not certified C2PA.
• Stripe webhook HMAC verification and offline HMAC license validation.
• Opt-in, report-only security scanner. An AI-assisted self-scan (STRIDE-style review plus dependency audit) can flag issues. It is opt-in, report-only, and not a guarantee — it does not replace a professional security audit.

Transport & hardened deployment

The project ships hardened templates and runbooks you apply on your host: an nginx config with TLS 1.2/1.3, HSTS and security headers; an install script that creates an unprivileged service user, scoped sudoers, restrictive file permissions, automatic security updates, a firewall/fail2ban, and Let’s Encrypt certificates; and a backup script. These are provided as defaults for you to run — they are your controls once deployed.

Shared responsibility (self-hosted)

Because you operate the environment, security is shared. Here is an honest split.

Subprocessors

AI OS itself does not send your data anywhere. But the AI model and tool providers you choose to enable receive the specific data you send to them, under their own terms. Only the providers you configure are used. The common ones:

A formal, versioned subprocessor register and signed Data Processing Agreements are on our roadmap; today this list is provided for transparency and is not yet a contractual register.

Compliance status — stated honestly

What is true today:

• We have conducted an internal SOC 2 readiness self-assessment — an honest control mapping against the AICPA Trust Services Criteria with a prioritized gap list. It is a self-assessment, not an audit.
• The realistic path to a formal report runs through the Managed / hosted offering, the one scope where AI OS operates the environment end to end. That is where we would pursue a Type 1 examination.
• Our Terms and Privacy Policy are being finalized with counsel; treat the current versions as drafts.

We would rather tell you exactly where we stand than imply a certification we do not hold.

Reporting a security issue

If you believe you have found a security vulnerability, please tell us through our contact page. We support responsible disclosure: give us a reasonable window to investigate and remediate before any public disclosure, and we will acknowledge legitimate reports.

Frequently asked questions