Security
Built so the boundary holds.
Tenant isolation, authorization at the server and an AI that cannot widen its own reach. Here is how each one works, including the parts that come with a condition.
Tenant isolation
Every tenant is its own boundary, from sign-in to search.
Created as one unit
A new tenant gets its own sign-in organisation, its own search index and its own equipment knowledge graph in one provisioning run. If a step fails, the earlier steps are undone rather than left half-built.
Isolation the database enforces
Tenants share infrastructure today, and the database itself keeps them apart on every row, so isolation does not depend on each query being written correctly. Dedicated infrastructure for large tenants is planned and not available yet.
Identity resolved on every request
A request is bound to its tenant by the address it arrived on and to a member record that carries that person’s roles and organisational scope. A caller with no member record in the tenant is refused.
Scope inside the tenant
Each tenant defines its own country, business unit, project and package layers, and every user is scoped to them. Nothing is provisioned by default: the hierarchy is yours to define at onboarding.
Hosting and third parties
Where tenant data may live is restricted in code, and everyone else who touches it is named before you sign.
Location restricted in code
The infrastructure code accepts only an approved set of hosting locations and refuses any other value, rather than applying it silently.
Tenant traffic comes straight to us
The API, your dashboards and sign-in carry tenant data, and all three connect directly to our servers. Only the public website and our internal operator console are delivered through an edge network, and neither carries tenant data.
AI processing, stated in full
Three AI features run at third-party providers, and each receives your data. To make records searchable, the text of every record and document is sent as it is written. To read documents, the page images and extracted text of a certificate imported from a chat, and the page images of a chat file our own text extraction could not read, are sent, up to a daily limit per workspace. The page images and extracted text of other scans our own extraction is not confident about, such as a file saved to a record, are sent only in a workspace where reading has been switched on, and it is off by default. To answer a question to Root, the question, the records retrieved for it and the text of any file attached to the chat are sent. Root answers and document reading are routed only to providers whose published policy is not to train on the request; the search-indexing provider states it never trains on API data. How long each provider keeps a request follows its own terms. This processing is not limited to where the platform is hosted. We name each provider in writing in the security review.
Sign-in and authorization
Permissions are enforced where the change happens, not where the button is drawn.
One sign-in, roles checked on the server
People sign in once to their tenant. Roles come from a fixed catalogue and are held as an additive set per user, on top of a view-only floor everyone has.
Named permissions at the endpoint
Registering and editing equipment, and managing people, suppliers, projects and packages, downloads and acceptance forms, each require a named permission at the endpoint rather than a hidden button. Other changes today require a signed-in member of the tenant; extending named permissions to the rest is in progress.
Segregation of duties
Where the work requires it, the rule is built in. Issuing stock needs an approver who is not the requester. Approval that also follows the seniority of your org hierarchy is planned and not available yet.
Bot protection on sign-in
The sign-in flow is protected by a challenge in front of the authentication endpoints.
What the AI can and cannot do
The guarantees are built into the system rather than written into a prompt: an allow-list, a scope fixed on the server, and an approval for every action.
Only what your role allows
Root is offered only the actions your role permits, and tells you when you ask for one you lack. A proposal changes nothing on its own.
Approval per action
Root can only propose actions from a fixed allow-list. Nothing runs until a person approves that specific action, and the approved change goes through the same permission-checked path the dashboard uses.
Scope it cannot widen
Tenant and organisational scope are fixed on the server before Root sees a tool. The model has no way to ask for more.
Chat attachments stay in the chat
A file attached to a conversation is read by our own text extraction, for that conversation only, and is not added to search; making it durable knowledge is a separate, approved action. Its text still reaches the provider behind Root as part of each answer, as described under hosting and third parties.
Your history is yours
Conversations and generated documents belong to the person who created them and are not shared across the tenant.
How we run it
Monitoring and access to production are part of security, not separate from it.
Monitoring we operate ourselves
Error reporting and AI tracing run on infrastructure we operate, not in a third-party analytics account.
Internal consoles behind one gate
Every internal console sits behind a single sign-in gate with multi-factor authentication.
Everything defined in code
The environment is defined in version-controlled code and reconciled from it, so what is running is what was reviewed.
Ask us before a pilot
We name the hosting location and every third party that processes your data, with what each one receives, in writing before a pilot. If any of it is a problem for your jurisdiction, raise it then rather than after.
One knowledge layer, filtered on read
Every record is added to the tenant’s search index and equipment knowledge graph when it is written, and removed when it is deleted. What a person sees is then filtered by their permissions and organisational scope at the moment they ask. Nothing is left out of the index as a substitute for a permission, because an index with gaps produces answers with gaps.
Security questions
Where is our data stored?
In a hosting location the infrastructure code restricts: it accepts only an approved set of locations and refuses any other value. We name the location, and every third party that processes your data, in writing before a pilot.
Does any third party process our data?
Yes. The platform runs on a hosting provider's infrastructure, invitations and notifications are sent through a transactional email provider, and a bot-protection service checks the sign-in forms; that service and the network that delivers its script receive the visitor's IP address and browser details. Three AI features run at third-party providers, and each receives your data. To make records searchable, the text of every record and document is sent as it is written. To read documents, the page images and extracted text of a certificate imported from a chat, and the page images of a chat file our own text extraction could not read, are sent, up to a daily limit per workspace. The page images and extracted text of other scans our own extraction is not confident about, such as a file saved to a record, are sent only in a workspace where reading has been switched on, and it is off by default. To answer a question to Root, the question, the records retrieved for it and the text of any file attached to the chat are sent. Root answers and document reading are routed only to providers whose published policy is not to train on the request; the search-indexing provider states it never trains on API data. How long each provider keeps a request follows its own terms. This processing is not limited to where the platform is hosted. We name each provider in writing in the security review.
Is the AI trained on our data?
RelyentX does not train models on your data. Answers are retrieved from your own tenant at the moment you ask. The third-party AI providers described above receive the data each feature sends them, under their own terms, and we name them in writing in the security review.
Can we have dedicated infrastructure?
Not yet. Every tenant runs on shared infrastructure today, with its own search index and knowledge graph and database isolation on every row. Dedicated infrastructure for large tenants is planned; raise it before a pilot if you need it.
How is one tenant kept away from another?
By a separate sign-in organisation, a separate search index and knowledge graph, isolation the database enforces on every shared row, and a per-request binding between the caller and a member record inside that tenant.
See it against your own equipment data.
A walkthrough on your asset classes, your certificate disciplines, your job cards, not a canned demo.