The answers an operations lead asks before a pilot.
Written plainly, including the parts that are qualified. A security page that only lists strengths is not a security page.
Tenant isolation
A tenant is the root of every data boundary in the system.
Provisioned as a unit
Creating a tenant runs a compensating workflow that creates its Keycloak organisation, its own vector collection and its own graph database. If a step fails, the earlier steps are undone rather than left half-built.
Pooled stores, row-level scoped
Every tenant today shares pooled stores, where every tenant-scoped table carries a row-level-security predicate and each tenant still holds its own vector collection and graph database. A dedicated-store tier for large or residency-bound tenants is part of the committed model and is not yet on the shipped surface.
Identity is resolved per request
A request is bound to its tenant by the host it arrived on and to a member row that carries that user’s roles and organisational scope. A caller with no member row in the tenant is refused.
Scope inside the tenant
Each tenant defines its own country, department, project and package layers, and a user is scoped to them. Nothing is provisioned by default, the hierarchy is yours to define at onboarding.
Where it runs
The baseline jurisdiction is the EU, enforced in the infrastructure code rather than promised in prose.
EU-pinned infrastructure
Compute, object storage, the database and every self-hosted service run in an EU datacentre, and the infrastructure code rejects a non-EU region outright rather than accepting it silently.
Email in the EU region
Outbound transactional email is pinned to its provider’s EU region, and a non-EU value is rejected the same way.
Tenant traffic never touches the edge
The API, per-tenant dashboards and sign-in all carry tenant data, and all three resolve by DNS only and go straight to the EU machines. The public marketing site and the operator console are the only hosts served through the edge network, and neither carries tenant data.
The exception, stated plainly
Two AI services sit outside that pinning today, and both receive your text. Search indexing sends the text of each record and document to a third-party embedding API as it is written, and the copilot sends your question plus the retrieved context to a third-party inference API when you ask. Neither endpoint is EU-pinned today. If your jurisdiction requires it, raise it before a pilot. This is the honest state of it, not a footnote.
Sign-in and authorization
Authorization is enforced where the change happens, not where the button is drawn.
OIDC single sign-on
Sign-in runs through Keycloak. Each tenant is an organisation in its own realm, and a user is a person who belongs to it.
Additive roles, checked at the endpoint
Roles come from a fixed catalogue and are held as an additive set per user, with a view-only floor everyone has. Registering and editing equipment, and managing people, suppliers, projects and packages, downloads and acceptance forms, each require a named capability at the endpoint rather than a hidden button. Other write routes today require an authenticated member of the tenant; extending named capabilities across the rest is open work. Tenant data is read and written through a pooled connection that drops to a role which cannot bypass row-level security, so the isolation does not depend on the query being written correctly.
Segregation of duties
Where the domain requires it, the rule is in the domain. Issuing stock requires an approver who is not the requester. Approval that additionally enforces org-hierarchy seniority is part of the committed model and is not yet on the shipped surface.
Bot protection on authentication
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 structural rather than instructions in a prompt: an allow-list, a scope bound server-side, and an approval gate.
Read-only by default
Write mode is opt-in, off at the start of every session, and warned. With it off the copilot cannot mutate anything.
Approval per action
With write mode on, the copilot can only propose actions drawn from a server-side allow-list. Nothing runs until a person approves that specific action, each one on its own, and the approved call goes through the same authorized use case the dashboard calls.
Scope it cannot widen
Tenant and organisational scope are injected into the agent’s tools server-side, by closure. The model has no way to ask for a wider scope.
Chat attachments are ephemeral, not private
A file attached to a conversation is read for that conversation only and is never embedded into the knowledge stores; promoting it to durable knowledge is a separate approved action. Ephemeral is not the same as contained: if the local text extraction is not confident, its page images go to the third-party reading service in the sub-processor list below, like any other document.
Owner-private history
Conversations and generated documents belong to the user who created them and are not projected into the shared tenant stores.
Running it
Observability and access to production are part of the security story, not separate from it.
Self-hosted monitoring
Application error reporting and AI tracing run on the same EU infrastructure as the product, not in a third-party analytics account.
Administrative consoles behind one gate
Every internal console sits behind a self-hosted single-sign-on gate with multi-factor authentication, reachable only over the EU hosts.
Infrastructure as code
The environment is defined in version-controlled infrastructure code and reconciled from git, so what is running is what was reviewed.
Sub-processors
The third parties that receive tenant data, and what each one gets. Enterprise buyers ask for this in the first security review, so it lives on the page rather than in an email. Ask for the current list before a contract. This page is maintained by hand and a contract should not rest on that.
| Service | What it receives | Region |
|---|---|---|
| Hetzner | Compute, object storage, database, vector store, graph store | EU (Germany / Finland), enforced in code |
| Resend | Transactional email, invitations and notifications | EU, enforced in code |
| Cloudflare | DNS for tenant hosts; edge delivery for the marketing site and operator console only | Global. No tenant data transits it |
| Jina AI | Embeddings, the text of each record and document, sent as it is written so it becomes searchable. Employee credential documents are excluded and never sent | Global. Not EU-pinned today |
| OpenRouter | Copilot inference (your question plus retrieved context) and document reading, the page images and extracted text of certificates, of any ingested document the local text extraction is not confident about, and of files attached to a chat. Employee credential documents are never ingested, so no page image of one is sent | Global. Not EU-pinned today |
GitHub holds source code and UptimeRobot pings public endpoints; neither receives tenant data. Typefaces are served from our own infrastructure rather than a font CDN, so loading this page contacts no third party at all. If the two AI rows are a problem for your jurisdiction, say so before a pilot rather than after.
The knowledge layer
Every domain entity is projected into the tenant’s vector store and equipment knowledge graph when it is written, and purged when it is deleted. Access is then filtered by permission and organisational scope at read time. Data is never kept out of the index as a substitute for an access rule, because an index with holes in it produces answers with holes in them.
Security questions
Where is our data stored?
At rest, in an EU datacentre: compute, object storage, the database, the vector store, the graph store and outbound email are all pinned to EU regions in the infrastructure code, which rejects a non-EU value. In transit there are two exceptions, both AI services (the embedding API that makes records searchable, and the inference API that answers copilot questions), and neither is EU-pinned today. The sub-processor list below names all of them.
Is the AI trained on our data?
RelyentX does not train models on your data, and it is retrieved from your own tenant’s stores at the moment you ask. What leaves our infrastructure is the text and, for documents, the page images sent to the two third-party AI services. What those providers then do is governed by their own terms, which you should review, we name them rather than characterise them.
Can we have dedicated infrastructure?
Not yet. Every tenant runs on the pooled tier today, row-level-security scoped, with its own vector collection and graph database. A dedicated-store tier for large or residency-bound tenants is part of the committed model and is not yet on the shipped surface, raise it before a pilot if you need it.
How is one tenant kept away from another?
By separate Keycloak organisations, separate vector collections and graph databases, a row-level-security predicate on every pooled tenant-scoped table, and a per-request binding between the caller and a member row 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.