Your own instance. Not a row in someone else's.
Each RedOS is installed as a closed environment for one business - cockpit, knowledge, agents and storage, provisioned for you, operated for you, isolated from every other client. Delivered as software: you never install or operate anything.
"Multi-tenant" is a word doing a lot of work.
Almost every AI platform you will be shown is one application serving every customer, where your company is a row in a shared table and a workspace ID in a query. That is not the same thing as having your own system, and the difference only becomes visible on the day it matters.
- One application instance serving every customer at once.
- Your data sits alongside your competitors', separated by a column in a query.
- Isolation depends on every developer remembering to filter correctly, every time.
- A single application bug is a cross-customer data incident.
- "Delete my data" means trusting a flag was set somewhere.
- You inherit every other customer's noisy neighbour problem.
- Your own instance of the whole system - cockpit, knowledge, agents, storage.
- Row-level security forced on at the database, in the same change that creates each table.
- The application connects as a least-privilege account that cannot bypass it.
- Proven continuously by an automated cross-tenant test harness, not by assurance.
- GDPR-grade tenant erasure - the environment goes, not a flag.
- Provisioned and operated for you. You never install or run anything.
What "your own instance" actually means.
Six properties that cannot be added later.
Each of these is a consequence of how the platform is built. None of them is a setting, a policy document, or a promise about process.
Every tenant-data table ships with row-level security forced on in the same change that creates it. The application connects as an account that cannot bypass it. Even a bug in application code cannot leak data across clients.
A single fail-closed service answers "can this principal do or see this?" for every principal - human and agent - across the whole platform. There is no second, weaker system to audit.
The three-scope mail wall is restrictive at the database layer. Private mail structurally cannot enter a shared view or the Knowledge Brain - not "is filtered out of", cannot enter.
A ratified hard rule: no silent fallbacks. If something is broken the system says so loudly rather than substituting degraded or invented data. Enforced in CI, so it cannot rot.
Deployments, go-lives, budget top-ups and high-risk actions require explicit human approval. Who is allowed to approve is itself a governed grant.
Internal specification documents carry freshness stamps checked against the code by CI. A claim that has drifted from the build fails the build.
What your IT and legal teams will ask.
Written to be forwarded. If a question here is answered vaguely, that is a defect - tell us.
Where this shows up.
One org chart, one set of gates - where shared governance becomes something you can look at.
Permission-aware retrieval: what an agent can pull is bounded by what its principal may see.
Budgets, approval gates and fleet visibility - governance you can watch working.
Send this page to your IT lead.
If it does not answer their questions, we would rather hear that than find out later.
Book a Red Brief