Built so the boundaries are structural.

Authority

Every agent holds an explicit authority level for each capability it touches: observe and recommend; act on reversible operations within granted scope; or act on consequential operations only with a recorded human approval. Levels are granted per tenant and per capability and can be withdrawn at any time.

Denial is structural. A capability an agent may not use is absent from its tool list — the agent cannot attempt it and be refused; it cannot attempt it at all.

Secrets

Agents never hold credentials. An action broker receives a named capability request, checks authority, resolves the credential from the tenant's vault through a per-tenant service account, performs the act, and returns only the result. An agent cannot read a secret, enumerate a vault, reach another tenant, or deploy.

Two vaults, one hard boundary: tenant-owned third-party credentials live in the tenant's own password-manager vault and remain rotatable by your people; platform machine secrets live separately and never in the tenant vault.

Isolation

Each tenant has its own memory, vault, authority grants and ledger. Data access is enforced at the database with row-level security and tenant-scoped capability grants; public interfaces expose aggregate counters only, never rows. Offboarding is a single, complete operation — grants revoked, vault access removed, exportable state delivered, residual data deleted — built before the second tenant, not after.

Auditability

Runs, decisions, approvals and outcomes are written to an append-only journal. Every executed action carries a run identifier, the authority it acted under, and an idempotency key so it cannot be replayed. Completion is recorded only against a real artifact — a merged change, a delivered message, a written record — never against an agent's own report.

Reliability is measured from the ledger: change-failure rate, cycle time and realized value are computed, not claimed.

Data handling

Your data is used to run your loop and for nothing else. We do not use your data to train models. Foundation models are accessed through provider APIs under their business terms, with your tenant's data passed per request and not retained by us beyond the ledger you can inspect. Retention windows are set per tenant; deletion on offboarding is complete and verifiable.

Voice sessions with JARVIS mint short-lived tokens server-side per call; the browser holds only a publishable key.

Continuity

Backups, restore runbooks, exportable state and a documented recovery runtime are part of the platform, governed by the same approval gates as production changes. Recovery is rehearsed, not assumed.

Compliance In progress

A SOC 2 Type II program is underway. We do not claim certification we do not hold; the report will be published here on completion, and the controls described on this page are the ones being audited. Procurement teams may request the current control narrative in a briefing.

Sub-processors

Supabase (database, functions, vault), Vercel (hosting and edge), Cloudflare (DNS, edge security and analytics), foundation-model providers (inference via API), and voice and telephony providers (real-time transport for JARVIS). A current list with regions and purposes is available on request.

Responsible disclosure

If you believe you have found a vulnerability in MATRIX OS or this site, tell us through the briefing form with the topic set to Security. We acknowledge reports promptly, keep you informed while we work, and credit researchers who wish to be credited. Please do not access data that is not yours or degrade service while testing.