Built to hold as little as possible

This is the first of two articles written for the security teams who evaluate ARX. It describes the architecture: what runs where, what Imperium holds, and what we deliberately cannot hold. The second, Controls you can see, covers the controls a reviewer can watch working.

The question we started with

The standard architecture for enterprise AI is a hosted platform. The company's documents, mail and ledgers are copied into someone else's cloud so a model can reach them quickly. It works, and it creates a second copy of the most sensitive things a company owns, in a place the company does not control. From that day there are two versions of the truth: the one in your systems, governed by your rules, and the one on the platform, governed by somebody else's.

We asked a different question before the first line of ARX was written: what would an assistant look like if it held as little as possible? Not as little as is convenient once the product exists, but as little as the job strictly requires, decided up front. Every design choice below follows from that question.

The assistant lives on the employee's computer

ARX is a desktop application. It runs on the machine the employee already works at, configured by their company. The AI model it uses runs under the customer's own account with the model provider, on commercial terms: the company's data is not used to train models, and the provider retains it only for a short period.

Imperium is not in the path between the employee and the model. Prompts and answers travel from the employee's machine to the model provider and back. They do not pass through our servers, and we have no access to the customer's model account. When someone asks where the thinking happens, the answer is precise: between your machines and your model account, under terms you hold directly.

Credentials we never hold

Connected apps, the accounting system, email, calendar, the CRM, the advertising accounts, are authorised by each employee in their own browser, on the connected service's own sign-in page. The tokens that come back from that grant are never written to the employee's disk and never stored on Imperium's servers. There is no vault of customer passwords at Imperium, because there is nothing to put in one.

What each employee does carry is a single credential for the tools gateway, the service that brokers calls to connected apps. It is short-lived, bound to the audience it was issued for, and stored through the operating system's own encryption. When an administrator withdraws a person, that credential is invalidated within a minute.

Read at the moment of use

When the assistant needs an invoice, an email thread or a pipeline stage, it reads it at that moment, uses it for the task in front of it, and lets it go. The contents of your systems are not synchronised into a copy of ours, indexed overnight, or warehoused for later.

The gateway that brokers those calls keeps a record of each one: who made it, which tool, when, and whether it succeeded. It has no place to store the arguments that went in or the data that came back. That is a property of the design rather than a policy. A policy can be relaxed in a quiet quarter; a table that does not exist cannot start filling itself.

Money is draft-only

Financial write actions produce drafts: draft invoices, draft bills, draft credit notes. Nothing ARX does posts to a ledger, pays a bill or sends an invoice on its own. Three independent mechanisms enforce the rule, and all three would have to fail at the same time before a ledger entry could happen without a person. A misread prompt, a bug or a bad day stops at a draft.

The approval itself happens in the accounting system the company already trusts, made by a person who already had the authority to make it. We did not build a second approval surface for people to learn; the existing one is the control.

Working files stay in the customer's hands

Each employee's ARX workspace backs up to a private repository inside the customer's own organisation account, under the customer's administrators. If an engagement ended tomorrow, the working files would already be where they belong.

Team knowledge and files shared through ARX live in a database project provisioned for that company alone, isolated per person with row-level security. One company's project holds one company's data, and a person sees what their permissions allow and nothing else.

What we do keep, and what we are changing

A page like this earns nothing if it only lists what we avoid, so here is what Imperium does keep. We keep product-usage telemetry, with no names and no message content, so we can see when the product fails and fix it before the customer has to report it. We keep the analytics that power the company's own usage dashboard, which is how an administrator sees who is getting value from their seats.

We are tightening both: retention limits on analytics, a per-company switch-off, and regional hosting. The security page shows the state of each piece of that work as it stands, because we would rather show you where it is than round it up to finished.

Software you can verify

Every update to ARX, and the AI engine it runs, is verified against a cryptographic hash before it installs. macOS builds are signed and notarized. The assistant itself is prevented from modifying the application it runs inside or the engine it runs on, so a confused instruction cannot rewrite the thing that constrains it.

None of this asks you to take our word for it. The hashes are checkable, the notarization is checkable, and the behaviour is observable on any machine ARX runs on.

---

The rest of the picture, including the live status of every assurance programme we run, is on our security page. If your security team is evaluating ARX, write to security@imperiumos.ai and ask for the security pack: the architecture overview, the data-flow table and the letters behind everything summarised here.