Trust & security

Evidence you can check yourself

Compliance tooling asks you to trust its records. We would rather you verify them. Every claim on this page describes something running in production today — and further down, we list what we deliberately do not claim.

For why any of this matters once a firm runs frontier models inside its own perimeter, see the accountability layer for frontier AI.

For the third parties that touch your data, see our sub-processor list.

What is running today

Tamper-evidence enforced by the database

Audit records are append-only at the storage layer. A database trigger refuses UPDATE and DELETE on the audit table outright — not a convention the application agrees to follow, an operation the database will not perform.

Evidence: Enforced on the partitioned table and every partition. Mutation-tested: with the guard disabled the destructive statements succeed, which is what makes its presence meaningful.

A hash chain across two epochs, verified end to end

Every record is hash-chained to the one before it, so altering or removing history breaks the chain in a way that verification detects. Two hash schemes coexist from a chain re-anchoring; both are verified, and a gap between what the walker reached and what the table holds is a hard failure rather than a pass.

Evidence: Checked by a scheduled job every night: all 112 nightly checks from 20 July 2026 to 8 November 2026 passed, with no failures.

Evidence survives the tenant that produced it

When an organization is deleted we remove its operational data — but its audit chain is retained, under our legitimate interest in preserving a verifiable compliance history. A final entry records that the organization was deleted, so the chain says why it ends. Evidence that disappears on account closure is worthless precisely when it is most needed.

Evidence: Proven end to end: an organization deleted through the product, its chain retained, the closing entry linked to the prior record, and the whole chain still walking clean afterwards.

Verified nightly — including tenants who have left

A scheduled job re-verifies every chain we hold, every night. It enumerates chains from the audit store itself rather than from the customer list, so the record of a departed tenant keeps being checked rather than quietly dropping out of scope.

Evidence: Every nightly check from 20 July 2026 to 8 November 2026 covered every chain we hold, including those of organizations that have left.

Evidence you can verify without usProfessional plan and above

Export a signed evidence bundle and check it with an open, dependency-free verifier that runs offline. No Rends service, no network, no database — so verification does not depend on our word, our uptime, or our continued existence.

Evidence: Bundle formats v1.1 and v1.2; a signed bundle independently verified offline by a third party using the standalone verifier.

Nightly encrypted off-box backups

The application database, the identity database, cluster roles and configuration are dumped nightly, encrypted, and shipped off the machine. Every upload is verified after the fact, because an upload command that exits successfully is not the same as an object that arrived.

Evidence: Running nightly across all four families, upload-verified each run.

Self-hosted identity

Authentication runs on identity infrastructure we host. No third-party identity provider holds your users, and sign-in does not hand your session to an outside service.

Evidence: Sole identity store; no third-party IdP in the authentication path.

Your data

Tenant isolation — each organization’s data is separated by organization id in application code, and authorization is default-deny at the gateway: a request without a valid organization context is rejected. The database itself enforces this separation for six kinds of records: API keys, agent action records, policy rules, agents’ spending budgets, the amounts held against those budgets, and the authority granted to agents. It does not yet do so for any other data.
Encryption — TLS 1.2+ in transit.
US-based OCI infrastructure — hosted in the United States on Oracle Cloud Infrastructure.
Configurable retention policies per organization for audit and compliance evidence (Enterprise plan) — configured and running on our own organization, not yet on any customer’s. Seven policies have been in force since 27 August 2026 and the worker has completed 143 runs, most recently on 17 September 2026; across all of them it has deleted one record and archived one. Both counts are in govern.retention_policies and govern.retention_executions. We would rather give you the number than let a built feature imply a practice. Until 17 September 2026 this bullet said “not yet exercised: no organization has configured a retention policy, and none has run.” That was written when both tables were empty and stayed on the page for three weeks after it stopped being true. We are correcting it by addition rather than replacement so the drift is visible.One exception, and it runs the other way from the usual one. Where decisions form a transaction, retention applies to the whole transaction rather than to each record, and the clock starts from the most recent record in it. A transaction that spans the boundary is kept entire until all of it has aged out. So a retention window over transaction data is a minimum, not an exact period: some records live longer than the number you set. The alternative is deleting part of a chain, which produces a total that is wrong without being visibly wrong.
Data deletion on account termination — we remove your organization’s operational data. Tamper-evident audit records are the deliberate exception: they are retained under our legitimate interest in preserving a verifiable compliance history, so the evidence of past decisions outlives the account that produced it. They cannot be selectively rewritten without breaking the hash chain that makes them evidence. Contact privacy@rends.ai to discuss a specific request.
Transaction records are append-only, and that forecloses something. When decisions are linked into a transaction — a chain of related actions across systems — the records in that chain cannot be deleted or edited, by us or by you. This is enforced in the database, not by policy. The reason is arithmetic, not preference: a rule that says “no more than 50,000 released in one transaction” answers by adding up the earlier steps. Delete some of those steps and the total comes back smaller, the rule allows what it should refuse, and nothing in the result says a step is missing — the wrong answer and the right one look identical. What this costs you: an erasure request that lands on a transaction chain has no technical answer today. We can delete operational data and non-transaction records; we cannot remove one decision from a chain and leave the chain meaningful. If that trade is wrong for your obligations, tell us before you enable transaction-level rules. Contact privacy@rends.ai.
We never use your data to train AI models — your governance data is not repurposed for model training.
Bias monitoring (Professional and above) — flags gendered, racial and age-related terms in the outputs of agents run through Rends for review.

Sub-processors

Stripe — billing and subscription management
Anthropic — AI analysis for compliance and product features (under data processing terms)
Google — AI analysis for compliance and product features (under data processing terms)
Oracle Cloud Infrastructure — hosting and encrypted backup storage

Authentication is handled by our own self-hosted identity service, not a third-party identity provider.

In progress: air-gap edition

Rends is being built to run where nothing can reach the internet. In our isolated test, with no network access:

Installs offline. One bundle holds the application, its dependencies, its fonts and its documentation. Nothing is downloaded.
Sign-in inside your perimeter. Identity runs on a Keycloak server bundled with the install.
Connects to your on-premises model server. Model features use an OpenAI-compatible server you run. Hosted model providers are switched off.
Keys stay in your hands. Secrets live in a locked-down key directory, and the platform refuses to start if it can be read by others.
TLS on every internal connection that leaves the host — database, Redis, identity and service-to-service — verified against your certificate authority.
Encrypted storage required. At every start the platform checks that the directories it keeps its keys and data in are on encrypted storage, and refuses to run if they are not. Encryption the operating system cannot see is accepted only with an install flag and an operator's attestation, recorded in the audit trail as attested — not verified.
An offline licence. A signed licence file. When it lapses, admin and configuration changes lock after a 30-day grace period — enforcement, blocking and audit never stop.

Not yet deployed for a customer, as of 6 October 2026.

Planned

Direction, not commitments. None of the below is available today, and no date is promised.

SOC 2 Type II attestationPlanned.
FedRAMP authorizationPlanned — requires a federal sponsor and 3PAO engagement; not started.

Questions a security review would ask

We are onboarding organizations by request, which means a real conversation rather than a signup form. Bring your diligence questionnaire.

Request a security review