Security

A person gets in only once they are admitted to their company's workspace. Signing in with a work email or single sign-on proves who you are; it does not let you in by itself.

Sign-in links work once and end after 15 minutes. We store only a scrambled (hashed) form of each link. A sign-in lasts up to 14 days.

Removing or suspending someone ends every session and token they hold at the same moment: browser sign-ins, API keys, assistant links and laptop sync tokens.

Every passage carries one access label, taken from the sharing in the place it came from. Each search checks that label against the reader's access inside the database, before anything is ranked. A passage someone may not see never reaches their answer.

The app's own database login cannot read documents directly. It can only call checked functions that work out the reader's access inside the database, so no code path can forget the check.

• Walls: where a company has information walls, they beat every other rule, including admin rights. If a wall's feed is out of date, access closes.
• Dated access: memberships, grants and walls have start and end times, with full history, so you can see who could read what at any time.
• Access is always checked now. Asking about a past date picks the edition in force then, but never opens a file before its time.
• Unknown means no: if a fact a rule needs is missing, such as a person's country, access closes.
• Summaries, topic names, counts and links show only to people who can read every source behind them.
• The reply is the same whether hidden content exists or not: “No source you can see answers this.”
• Footnotes are checked again when you open them. If access has changed, the source shows as no longer available.
• New sources start visible to their owner only, and only people with the right to publish can open a source to others.
• Content from a person's own connected accounts, and their notes, can be read by that person alone: not by admins, and not through “view as”.
• “View as”, which lets an admin check what someone else sees, can only read. It can never change anything.
• Every answer shows whose access it used.

Each company has its own private workspace. Its files are stored under its own path and never shared with another company, even when two files are the same.

The demo runs in its own database and never holds real data.

Data is never pooled across companies and never used to train models.

Radcliffe reads from your company's tools and never writes to them. Its connector code refuses any request that would change, move or delete anything, and a sign-in that grants more than read access is refused.

A laptop's sync app can only send files in. Its token cannot read chats, documents or access settings.

On the move: every page and API call uses HTTPS (TLS). Browsers are told to use HTTPS only, for radcliffeai.com and every part of it. In production, the servers refuse to start if any address they use is plain HTTP.

Our servers reach the database, the file store and the model providers over encrypted connections.

The sign-in cookie is sent only over HTTPS and only to our API, never to this website, and page scripts cannot read it. Every change needs a special header, and our API takes signed-in calls only from the app's own address.

At rest: saved secrets, such as tokens and keys for connected tools and model keys, are encrypted in the database with a key kept outside it. Radcliffe never shows a saved secret again, only its last 4 characters. We can replace the key and lock every secret again with the new one.

Tokens we give assistants are stored only as hashes.

Our database provider, Neon, and our file store, Cloudflare R2, encrypt all stored data at rest, as each provider states.

No real files go into a company's workspace until three checks pass. Anything missing, failed or out of date means no:

• a full test run with real models on test data, with zero leaks, for the exact release that is running, under 30 days old;
• the company's own checks: a clean workspace, an admitted owner, a plan for each source, every sharing group mapped, serious findings fixed, and 5 to 20 test questions written by an owner;
• a live scan of each planned source for files shared too widely, under 14 days old and reviewed by an owner.

Then real files open in two steps, each signed off by an owner. First, only owners and named reviewers see the real content while they test it. Then it opens to everyone with access. Every step is logged.

Before the checks pass, a scan can read the names and sharing of files, but never their content.

Each answer is kept as a record: who asked, the question, each source and its version, the answer, the model that wrote it and who approved it. An answer whose record cannot be saved is not shown.

Records are chained, each carrying a fingerprint of the one before, so a gap or an edit shows. The app's own logins cannot change or delete a record. When a record's time is up, its words are removed but the fingerprints stay.

Changes to access, approvals and our own team's actions are logged. Your company can place legal holds, export records for subject access or disclosure, and list who could read a file and when.

Our operators review access requests, send invitations and watch the health of the service. The operator role gives no access to any company's documents or chats, and every operator action is logged.

The database owner login never sits on the running servers. It is used only to update the database during a release.

• Database: we can restore it to any point in its history window, which is at least 7 days. A restore goes to a separate copy first and is checked before it replaces anything.
• Files: once a day, every file is copied to a second EU bucket with its own key, which the app cannot reach. A file that leaves the live store is kept there for 30 days, locked so not even the backup key can remove it early.
• Encryption key: a copy is kept in a locked vault, so losing the key on the servers loses nothing.
• After a restore, every removal, ended session and deletion made since that point is done again before the service reopens.
• We practise a full restore before launch and then every three months.

We keep your content out of our logs and error reports. Emails, tokens, secrets, web address details and quoted words are taken out before anything is written, and fields that could hold content show only “hidden”.

Error reports go to Sentry with no request bodies, cookies or headers. We use no tracing and no session replay.

Our team is alerted when a worker stops, jobs wait too long, jobs or mail fail, or a company nears its monthly AI spending limit. If customer words ever show in a log, we treat it as an incident.

Answers are written by Anthropic's Claude models. Search uses Voyage AI. We call both through their paid APIs, under their business terms, and send only passages and questions.

We do not use your content to train models.

If a model is down, Radcliffe says so. It never quietly switches to another model, provider or key.

Your company can use its own Anthropic or OpenAI key instead.

• Every change runs automated tests, including access and leak tests, before it can ship.
• Leak tests plant marked text behind every wall, date, rule and private note in a test company. Any trace of it in any reply, footnote, title, count or graph item is a failure.
• Each release runs the full test set with real models on the test company. A single leak stops the release.
• Real files open only for a release that passed with zero leaks in the last 30 days.

Radcliffe does not yet hold a security certification, such as SOC 2 or ISO 27001.

See radcliffeai.com/responsible-disclosure for the scope and status of security reporting.