A separate database per client
Not a shared table with a client column and a filter on every query. Each client gets its own PostgreSQL database. A filter is a line of code that can be forgotten; a separate database cannot be forgotten.
03 · Security & privacy
Private by construction,
not by promise
Most software asks you to trust a policy. The arrangement here is structural: one client’s data is physically unable to reach another’s, and your records never leave hardware we run.
UK-resident · encrypted at rest · never pooled, never sold, never used to train AI
Own database
per client, never a shared table
UK
dedicated hardware we run
Local only
the assistant never calls a cloud AI
DPA
signed before you go live
Isolation
The failure we designed out first
Every multi-tenant system says client data is separated. The question worth asking is what separation is actually made of.
A scoped role that cannot reach anywhere else
The credentials your workflows run as can connect to your database and no other. Even a workflow written wrongly has nothing to reach — there is no shared runtime credential anywhere in the system.
Isolation by construction, not by convention
The test we hold ourselves to is not “would a query leak across clients”. It is “could it, by any route”. Cross-client leakage is the one failure we treat as unrecoverable, so it is designed out rather than guarded against.
Where it lives
On hardware we run, in the UK
Being straight about this: the box is red-route’s, not yours. We run it, encrypt it, and carry the responsibility for it as your processor. What is yours is the system and the data.
Dedicated hardware we run, in the UK
Your data sits on machines red-route owns and operates in the United Kingdom. Not pooled in a hyperscaler region, not replicated to wherever capacity was cheapest this quarter.
Never at your premises
No hardware is ever installed at a client site. You get the privacy benefits of dedicated infrastructure without becoming responsible for a box in a cupboard.
Encrypted at rest, with encrypted backups
Full-disk encryption on every machine, and encrypted backups held off the primary box. Each production box runs with a second as an encrypted replica and warm standby.
Per-client encryption keys where it matters
For sensitive work — youth services, safeguarding-grade records — your data gets its own encryption key by default. Available to any client who wants it. It also means the data can be permanently retired on request: destroy the key and it is unrecoverable.
Access
A small door, and nothing else exposed
The surface area a stranger can reach is the portal and the forms you deliberately publish. That is the whole list.
Only the portal is reachable
Your portal and its form routes are exposed through a private tunnel. The database, the admin tooling, the automation editor, backups and server management are not on the public internet at all.
Everything internal stays internal
Traffic between the automation layer and your database never leaves the machine. Sending your records out across the public internet to reach a database sitting on the same box is not a shortcut we take.
Your own domain is the only front door
Portal, API and form routes are all served under your domain, same-origin. No red-route address ever appears in a partner’s browser.
Staff tooling is locked separately
Our administrative surfaces sit behind their own access control, restricted to red-route staff. Clients never receive a login to them, and staff access is technical only — we do not make your operational decisions or act inside your portal as you.
AI
Your data does not go to a third-party AI. Ever.
This is the commitment most likely to be quietly walked back once a product gets busy, so it is worth stating exactly where the line is and what happens when the local model is down.
red runs on our own hardware
The in-portal assistant uses a local model on the box. Your records are retrieved server-side, scoped to the person asking, and passed to that local model. They do not travel to an external AI provider.
There is no cloud fallback
If the local model is unavailable, red says it cannot answer. It does not quietly fail over to a hosted AI, because that would defeat the entire arrangement at exactly the moment nobody was watching.
Nothing is used for training
Your data is never sold and never used to train any model — ours, or anyone else’s. We are the custodian of it, not the product being funded by it.
Claude is a build tool, not a runtime dependency
AI agents build and maintain the platform, working from written specifications and non-client data. No part of your portal calls an external AI with your records while it is running.
Governance
The paperwork that has to exist before you go live
Holding your records — particularly records about young people — carries a legal duty of care. That is settled in writing before anyone logs in.
We are your data processor
Under a data-processing agreement signed before you go live, with documented security measures. You remain the controller — it is your data and your decisions.
Safeguarding is handled as its own category
Where a client holds safeguarding records, those sit on a separate path with their own storage, reachable only by roles holding that specific capability, and excluded from exports, general lists and anything the assistant can see.
Retention is yours to set
How long records are kept is your policy, written down as part of onboarding rather than inherited from a default nobody chose.
Leaving is a supported operation
You can have your data out, and where per-client keys are in use we can render what remains unrecoverable. An exit that depends on our goodwill is not an exit.
Worth saying plainly
What we do not claim
We do not say the hardware is yours or that you control the infrastructure — it is ours, and we run it. We do not claim certifications we have not completed. And we do not describe the portal as safe for your own end customers, because it is built for your organisation and the partners you approve, and that boundary is part of what makes the rest of this hold.
Ask us the hard questions
If you are responsible for sensitive records, bring your due-diligence list. It is a better conversation than a brochure.