// TRUST
10 MIN READSecurity & Architecture
Written for whoever signs off on agents working in your ERP. How isolation is enforced, where credentials live, and what happens before an agent writes.
Tenant isolation
Every row of organizational data in ORiON is scoped to an organization, and that scoping is enforced by the database itself through row-level security policies — not by conditionals in application code.
The distinction matters more than it sounds. Where isolation is enforced in application code, a single missing filter in a single query is a cross-tenant data leak. Where it's enforced in the database, a query that forgets its scope returns nothing rather than returning someone else's data. The safe default is structural rather than remembered.
Credentials
Integration credentials and OAuth tokens are stored encrypted and are never sent to the browser. The front end can see that a connection exists and what it's connected to; it cannot see the secret behind it. All calls to your systems are made server-side.
Practically, this means a compromised browser session cannot be used to extract your ERP or CRM credentials, and an ORiON user cannot retrieve a token to use elsewhere.
Access scope
Connections are made with per-user OAuth wherever the upstream system supports it. ORiON inherits the permissions of the person who connected the account — it cannot see more of your CRM than that person can, and connecting ORiON does not create a new privileged service account with broader reach than any human has.
The consequence worth planning for: what ORiON can see depends on who connects each system. Connecting a system with a narrow account produces a narrow view, which is sometimes exactly what you want and sometimes a surprise three weeks later.
Recommendation for evaluation: connect with the account whose visibility matches the ERP work you want automated, and note it. It's the single most common cause of "why can't ORiON see that."
The write path
Reads and writes are treated as different classes of operation. Agents read freely within their access scope. By default, nothing is written, sent, updated or created in a connected system, whether an ERP record, a field or an email, until a person approves that specific action.
An agent determines an action is needed and assembles it in full — the target system, the record, and the exact change.
The action is held as pending and surfaced for review, with its reasoning and its source data attached.
A person approves it, approves part of it, or discards the run. Only approved changes are sent.
Every write goes to the audit log: what was proposed, who approved it, and what the system returned.
Approval is the default. Auto-run is an explicit choice made per workflow, for routine work you already trust, and those writes are still logged.
Traceability
The Context Graph records which systems and records contributed to an answer. For a security reviewer the useful property is that an answer's provenance is inspectable after the fact: if a figure in a close pack or variance note is disputed, you can establish where it came from rather than re-deriving it by hand.
It also functions as a scope check. If the graph shows a system contributing to answers you didn't expect it to touch, that's visible rather than buried.
Roles
Membership is scoped per organization, with administrative rights separated from ordinary membership. Administrators manage connections and who belongs to the organization; members work inside it. Because connection credentials are per-user, removing a person's access removes the connections they own along with it.
Disconnection
Because ORiON works on top of your systems rather than as a system of record, leaving is structurally simple: revoke the connections and ORiON stops seeing them. Your ERP, CRM and payroll data were never moved, so there is nothing to migrate back. This is the practical upside of not being the place your data lives.
// SECURITY REVIEW
Send us your
questionnaire.
Send it over and we'll work through it with you.