Security
Each group has a dedicated instance, shared with no other group. Inside it, the boundary is the company.
The access model
Between groups the boundary is the instance itself; inside a group's instance, it is the company.
The database refuses a request that has no signed-in person, rather than answering it with nothing.
Each request rebuilds a person's access from their current grants in the database, never from what their sign-in token claims.
The database keeps each company's data apart with row-level security, switched on and forced on every table. The build fails if one is missing.
A group-level grant reads every company in the group, while its changes stay within what the role allows.
Sign-in
People sign in with single sign-on over OIDC or SAML, Microsoft Entra ID and Okta included.
Who sees what
Access is held as grants: one role over the group, some companies or a division, optionally limited to countries and given an expiry date.
A grant can be narrowed to countries, and the database then hides other countries' records, quote requests, provider contacts and mail included. Imported rows go only to a company the person may import into.
A group can define its own roles, and the person writing a role can include only permissions they already hold. The structure editor asks before a change widens anyone's access, and a division people hold access through cannot be moved or retired until that access is withdrawn.
Personal data and the audit trail each need their own read permission, which company administrators hold and analysts and viewers do not. Without it, a reader sees Hidden in place of a name, employee reference and number. A mobile number shows only its last four digits, and mobile and SIM numbers on a bill are stored as hashes keyed with the instance's own key.
Reviewing a bill and accepting it are separate permissions. The person who raised a request can never approve it, and a step that needs every approver needs a different person in each seat. No one can change a finding's figures.
Audit trail
Opening records, downloading documents, exports, reports, unmasking personal data and assistant reads are recorded, not only changes.
A change made on the web and its audit entry are committed together, or neither is. Changes to grants, roles, single sign-on, the directory and policies are written to the trail by the database itself.
Entries record references and counts, never a person's name, email address or phone number. Each carries the source address, device and session it came from, and whether the action succeeded, was refused or failed.
Sign-ins, failed sign-ins and second steps join the same audit trail as every other event.
Every entry joins its group's hash chain as it commits, in commit order. No one can edit an entry, at any level of privilege.
The trail is also kept as a write-once copy under the instance's key that no one can delete, and any altered or missing entry shows when the chain is verified. Retention and legal hold are policies the audit store applies; no one holds a right to delete entries.
Signed checkpoints of each chain are kept outside the instance and delivered to the group, signed with a key the database never holds.
A group's security team can re-walk the chain and check its signatures without trusting Riopex.
Connections
The list of outside services an instance may reach is kept equal to the hosts the code actually calls.
| Connection | Its rule |
|---|---|
| The audit API | Your security team pulls the audit chain and its checkpoints with a read token. Issuing one needs a session that passed two-step sign-in; it is shown once, can be limited to a list of source addresses, and stops working for good when its issuer loses access. Every read through the API is itself recorded in the chain. |
| Your SIEM | Riopex pushes the audit chain as syslog over TLS, each entry labelled with its family, such as access administration or security refusals. |
| Monitoring | Riopex only reads: it asks for a read-only key and never writes to a device. |
| Addresses | A monitoring or SIEM connection reaches only an address a person has configured. |
| AI engines | An engine is reached over HTTPS only, at the address set for it. |
| The mailbox connects over IMAP and SMTP with TLS, and only to your own mail servers. | |
| Providers' ordering APIs | Riopex asks each provider for its open orders' status and opens no inbound callback. A provider receives the Riopex reference, the action, the target date, the circuit identifier and the account number, never a person's details or a price. |
| Confirmation files | A provider confirmation file sends only what the provider already holds and what needs confirming, never personal data or the group's own notes. Its email states how many services and which dates, never a service's details. |
| The MCP server | Every tool only reads. A person makes a token while signed in and sees it once, Riopex stores only its hash, and in a group that requires two-step sign-in it can be made only from a session that passed it. |
| MCP tokens and calls | A token stops working when it expires, is revoked, or its person loses access or is signed out everywhere, and a group administrator sets how long one may live. Results show phone numbers by their last four digits. Every call is recorded before its result is returned, without what was asked or answered, and a call that cannot be recorded returns nothing. |
| Outside services | Every outside service an instance calls, such as the AI engine, email relay or monitoring, sits where the group's instance runs, in the group's own estate, or is switched off. |
Data handling
Until a group administrator switches an engine on, nothing is sent to any model.
Before an engine reads a bill, every phone, SIM, device and email identifier on it is replaced by a token mapped back only inside Riopex, and the engine never receives the PDF or its file name. A whole scanned bill goes to an outside engine only by the group's own recorded choice. A bill a model refuses is never passed quietly to another, every call is an audit entry naming the engine, the model and the purpose, and an answer that cannot be recorded is not used.
Whatever the engine, everything the assistant sends is masked first, and the answer is restored for the reader. Its services lookup never returns a phone or SIM number, it is never given your email address, and your question is never written to the logs. It treats what its tools return as data, never as instructions.
Nothing a message says is acted on as an instruction. Mail is linked to a record automatically only by a Riopex reference, a reply to mail Riopex sent, or a known provider contact. It is shown as plain text, never as HTML, and provider contacts and mail are shown only to people allowed to read personal data.
A file's format is read from its contents, not its name. An uploaded usage file is not stored, and the mobile insights export names a holder by employee reference, never by name. Mobile lines are found by employee reference or last four digits, never by name, and personal fields never sort or filter. The street map's tiles come from the instance, to a signed-in person only, and the map and the globe request nothing from outside it.
Provider credentials are stored only as sealed envelopes: sealed by the web, opened only by the background worker. A stored credential can be replaced or deleted, but never read back, by anyone. Credentials never appear in logs, error reports, audit entries or job data, and an engine key is only ever sent to its own endpoint.
Each instance has its own encryption key, under which its database, backups, file store and audit copy are encrypted at rest. A group can hold the master key in its own cloud key vault and see every use of it; rotating it re-wraps the master key, and destroying it makes every copy unreadable, backups included. Each group sets how long each family of data is kept, and a person who leaves is pseudonymised.
Delivery
Riopex runs a group's instance for it, or the group runs the same instance in its own data centre, from the same signed release.
Data processing
The group is the controller of the data in its instance; Riopex is the processor.
| Role | What it may process |
|---|---|
| Hosting and delivery | Request records, and anything sent through the pilot form, in transit |
| Database, sign-in and storage | Platform accounts and the group's telecom records, invoice files included |
| A name, an email address and the message being sent | |
| Error reporting | Diagnostics with personal data scrubbed, and no invoice content |
| The intelligence engine | Masked bill text and the Ask assistant's masked questions, once a group administrator switches it on |
Questions
No. A compromised web or background process reaches only the group whose instance it runs in, and restoring one group's instance never touches another's.
Not until a group administrator switches an engine on. After that, identifiers are replaced by tokens before an engine reads a bill.
An administrator can reset the second steps of a person who lost their phone, and the person is told by email.
Withdrawing the group's key shuts the instance out of every stored credential at once, and it fails closed.
Yes. A group is told of a security incident affecting it within the time set in its contract.
Yes. A group can run Riopex in its own environment, including a network with no internet access, from an offline bundle, and takes versioned releases on its own schedule.
A group can ask for its instance in another region, provisioned the same way as the first.
A move keeps every record and the group's address, and the old site refuses sign-ins and API calls.
Yes, through a set procedure.
The group can export its whole data set, audit trail included, in documented formats.
Then the instance and its key are destroyed, and the group receives a signed deletion record naming the date.
Yes. The roles, the permission set and the isolation checks are shown on request.
Yes, and the answers match this page.
Send the questionnaire with the pilot request, and ask for the DPA at hello@riopex.com. The answers match this page.
Request a pilot