Security
RIFT is built for teams whose publishing gets audited.
The short version
| Attribute | What it means for you |
|---|---|
| Your cloud or your own infrastructure | RIFT runs as a single-tenant instance on the cloud you choose, or on servers you operate. No shared multi-tenant service holds your content. |
| Identity built to your spec | Multi-factor authentication and single sign-on are implemented to your environment's requirements during implementation, on top of RIFT's role-based access. |
| You choose the AI | Which model endpoint may see your content is an operator setting, not a vendor default. Sensitive workloads can be routed to a self-hosted model, or AI can be off entirely. |
| Encrypted in transit and at rest | Traffic is encrypted, stored data is encrypted by the platform, and the most sensitive values (passwords, API keys, deploy keys) get an extra layer of their own. |
| Audit log for humans and agents | Every save, state change, publish, and API call is recorded with who did it, when, and what changed. AI agents are logged the same way as people. |
| Agents propose, humans approve | An AI agent cannot publish, archive, or administer. Its work lands in a change-set a named person reviews before anything goes live. |
| Your live site never depends on RIFT | RIFT publishes static files to a git repository you own. A CMS outage, upgrade, or breach never takes your public site offline. |
| Nothing is silently deleted | Every version of every page is kept without a depth limit. Pages are retired, not erased, and any version can be restored. |
1. Your cloud or your own infrastructure
RIFT deploys as containers with a PostgreSQL database and Redis. That is the whole footprint, and it runs in three ways:
- RIFT Cloud: a dedicated, single-tenant instance we operate for you on Google Cloud (Cloud Run, Cloud SQL on a private network, Secret Manager). Nothing about your content transits a service shared with other customers.
- Your cloud account: a provisioning tool stands up the same isolated instance inside a cloud project you own, so your team holds the keys and the bills.
- Your own servers: the same containers run on infrastructure you operate, including networks with no outbound internet access.
Whichever you choose, the published website is separate again: static files in your git repository, served by the host you already trust. See Publishing & Git.
2. Sign-in, MFA, and roles built to your spec
Out of the box, RIFT signs users in with email and password. Passwords are stored only as salted bcrypt hashes, never in clear text or in logs. Failed logins return a generic message so account names cannot be guessed, and repeated failures are throttled per account and per source address. Admins can reset any password, which forces a change at next login.
Multi-factor authentication and single sign-on are built to your environment's specification during implementation. Government and enterprise identity requirements differ (SAML, OIDC, PIV/CAC, hardware keys, a specific identity provider), so rather than ship one opinionated integration, RIFT's authentication layer is wired to your provider as part of onboarding.
Authorization is role-based. Every user has exactly one role, and every privileged action is checked against it:
| Role | Can do |
|---|---|
content_author | Create, edit, transition, and publish content. |
admin | Everything an author can, plus users, roles, API keys, site settings, and change-set approval. |
agent | Read content and propose changes. Cannot publish, archive, or administer. The least-privilege grant for AI callers. |
service_account | Programmatic access for integrations, carrying author or admin permissions per the key. |
API keys are shown once at creation, stored only as a hash, rate-limited per key, and revocable instantly from the admin page. See the API Reference.
3. You choose which AI models see your content
Every AI feature in RIFT (the authoring assistant, the internal content agent, migration classification, reconciliation) goes through one provider configuration set by the operator in the instance's environment. It is deliberately not editable in the UI, so no user can quietly point content at a different vendor.
That gives you three postures:
- Commercial API (for example Anthropic) for teams whose policy allows it.
- Self-hosted model: any OpenAI-compatible endpoint inside your own network. Prompts and content never leave your boundary.
- Off: with no provider configured, AI features degrade gracefully and everything else keeps working.
For data-residency programs, the operator can declare a zero-retention posture. Under enforcement, the instance refuses to start if any configured provider, primary or fallback, is not on the operator's approved host list, and AI telemetry is limited to metadata. A data-flow document lists every outbound destination of content so a reviewer can verify the posture rather than take our word for it.
Connected agents (via MCP) run under the same rules; see MCP: Connect Your AI.
4. What is encrypted
"Everything is encrypted" is a phrase worth unpacking, so here is exactly what it means in RIFT:
| Data | Protection |
|---|---|
| Traffic to and from RIFT | HTTPS only, with HTTP Strict Transport Security in production. |
| Publishing to git | SSH with a per-site deploy key that can reach only that one repository. |
| Database and uploaded files | Encrypted at rest by the platform (managed encryption on RIFT Cloud; your disk or volume encryption when self-hosted). |
| User passwords | Salted bcrypt hashes. The clear text is never stored. |
| API keys | Only a SHA-256 hash is stored. The key itself is shown once and cannot be recovered, only revoked and reissued. |
| Git deploy keys | Private keys are encrypted with a master key held outside the database, so a database copy alone cannot push to your site. |
| Instance secrets | Database credentials, session secret, master key, and AI keys live in a secret manager, never in the codebase or the database. |
What this does not mean: page content is not additionally encrypted field by field inside the database. It relies on platform encryption at rest, the same standard your cloud provider applies to its own services. If your program requires customer-managed encryption keys or field-level encryption, raise it during scoping so it is designed in.
5. Every action has an audit record
RIFT keeps two records, and they reinforce each other:
- The audit log records every workflow transition, publish, taxonomy change, folder change, and archive override, with the user, timestamp, action, target, and before/after context. Every API call is logged too, attributed to the key's fingerprint, never the key itself. Admins filter it by user, action, and item.
- Version history keeps a full snapshot of every save of every page, so "what did this disclosure say on that date" is a lookup, not a reconstruction. See Version History & Workflow.
AI agents are held to the same standard as people. Each agent action appears in the audit log under its API key and change-set, and each proposal records the user's original request verbatim so a reviewer can judge the edit against what was actually asked. Finally, every publish is a git commit with a descriptive message in a repository you own, a third record you control completely.
6. Agents propose, humans approve
This is the rule that makes AI usable in a regulated environment. An AI connected to RIFT, whether your own assistant over MCP or RIFT's built-in content agent, cannot publish, archive, or administer. Structurally, not by policy: the agent role has no such permission to misuse.
Everything an agent writes lands in a change-set. RIFT builds it to your staging site, and a named person on your team sees the original request, a before-and-after diff of every page, a link check on every reference, and a list of any facts the agent asserted that none of its sources support. The reviewer approves, approves with exclusions, requests changes, or rejects, and the decision is recorded under their name. Until then, the live site is untouched.
7. Your live site never depends on RIFT
RIFT's output is plain static files (HTML, CSS, JavaScript, images, PDFs) committed to your git repository and served by your host. There is no RIFT code or database call in the path between a visitor and your page. If the CMS is down for maintenance, migration, or an incident, every published page stays up exactly as it was. The reverse is also true: nothing a visitor does on your public site can reach the CMS.
Because each site has its own deploy key scoped to one repository, a compromise of one site's key cannot touch another site. See Core Concepts for why this separation is deliberate.
8. Nothing is silently deleted
Every version of every page is retained without a depth limit. Pages are retired (archived, with an optional redirect to a successor), not erased, and their history stays queryable. Any earlier version can be restored, and a restore is itself a reviewed, recorded change. Agents have no delete capability at all; when an agent is asked to delete something, RIFT retires it instead and says so in the result.
For the broader compliance picture, see Security & Compliance. Have a security questionnaire? Send it: we would rather answer the hard questions before you are asked them.