// TRUST
10 MIN READSecurity & Architecture
Written for whoever has to sign off. How isolation is enforced, where credentials live, and what happens before an agent writes anything.
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 questions you want answered, 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 fundamentally different classes of operation. Agents read freely within their access scope. Nothing is written, sent, updated or created in a connected system without a human approving that specific action first.
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 human approves or rejects. Only on approval does the call to your system happen.
The outcome is recorded — what was proposed, who decided, and what the system returned.
This is a deliberate ceiling on autonomy. ORiON is slower than a system that acts unilaterally, and that is the intended trade.
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 report 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 is a layer rather than a system of record, leaving is structurally simple: revoke the connections and ORiON stops seeing your systems. 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.