Security

Written to be forwarded.

This page exists so the person championing Möbius can send one link to their CISO instead of booking a call. It describes how access is granted, how personal data is protected, where traffic is allowed to go, and what the record shows afterwards. It also names what is not built yet, because that question gets asked in the first RFP and the honest answer travels better than the discovered one.

There is no standing key to steal

Möbius reaches your cloud infrastructure through short-lived assumed roles, not stored long-lived keys. Credentials to Möbius itself are minted narrow — per workspace, per dataset set, per scope, and per audience — so a credential that reads rows cannot change governance, and a credential that governs cannot read rows.

Keyless cloud access: Access to your own cloud accounts runs on short-lived assumed roles. There is no standing credential to rotate or leak. The one deliberate exception — S3-compatible endpoints that cannot issue temporary credentials — is a per-connection, disclosed opt-in, never a default.
Scoped machine credentials: Integration tokens are minted per workspace, per dataset set, per scope and per audience. A token carries the smallest authority that does the job.
Credential audience separation: A token minted for one surface family is structurally rejected on every other. Separation of duties is enforced by the credential itself, not by a policy someone has to remember.
Personal and command-line tokens: People working from a terminal or a pipeline get tokens that carry their live role — revoked the moment they are.
Device authorisation: Surfaces that cannot hold a browser session pair through an explicit human approval step, recorded like any other governance act.
Role model: Five ordered workspace roles — viewer, editor, steward, admin, owner — enforced beneath every surface, so no door has its own authority rules.

Personal data

Masked at read, unmasked only on the record

Every column carries an explicit disposition — what it is, whether it is personal data, how it may be exposed. That disposition then drives masking at every exit, for every consumer, on every surface. Access to an underlying value is a grant with a name and an expiry attached, not a role that quietly accumulates.

Field-level disposition: Personal data is declared per column and enforced from there, so classification and enforcement can never drift apart.
Masking at read: Values are masked, hashed or tokenised per field policy at the moment of read — the same rules through the API, the command line, a dashboard or an AI host.
Time-bound unmask grants: Someone who genuinely needs the raw value gets an explicit, recorded, expiring grant. The grant, its reason and its expiry are part of the trail.
Personal data detection: Möbius proposes which columns look personal so classification starts from evidence rather than from a workshop. A steward decides; nothing is auto-applied.
Masking follows composition: Field policy travels into composed views and into vector metadata, so neither composition nor retrieval can widen exposure.
Reversible deletion: Datasets, columns and rows are retired rather than destroyed, with a retention window your team sets before anything is actually purged.

The network floor

One guarded path out. No per-feature override.

Every outbound call Möbius makes — a webhook, an ingest fetch, a model call — is forced through a single guarded egress path with request-forgery protection and HTTPS-only transport. There is no feature-level switch that opts out of it, which is the property that makes the floor reviewable rather than merely documented.

Outbound egress floor: One path, SSRF-protected, HTTPS only. Adding a feature does not add a way out.
Per-connection TLS posture: Each warehouse connection carries an explicit certificate-verification level, and any downgrade is disclosed and audited rather than silently allowed. Warehouse connections are a Möbius Connect and Möbius Enclave capability.
Network policy: Restricts which networks may reach a workspace's data surfaces, with a preview of what a rule change would break before it is applied.
Signed outbound notifications: Change notifications to downstream systems are signed and delivered over HTTPS only, with no insecure-transport override anywhere in the product.
Consumer admission gate: At the point of access, Möbius decides whether this consumer, on this credential, in this environment, may receive this data at all.
Rate limiting: Per-credential request ceilings on every governed surface.

Keys and containment

Keys you can rotate. A stop button you can press.

Secrets and credentials are encrypted under a per-workspace key wrapped by a deployment master key. On Möbius Connect and Möbius Enclave, that master key stays in your environment — Möbius Cloud never holds it. And when something goes wrong, containment is one action rather than a runbook.

Envelope encryption: Per-workspace keys wrapped by a deployment master key. On Connect and Enclave, the master key never leaves your environment.
Key rotation: Rotating a workspace's encryption keys is a governed, audited operation, not a maintenance ticket.
Workspace lockdown: One action freezes a workspace during an incident. Governance state stops moving until someone deliberately releases it.
Group freeze: Freeze a single group of related datasets during a migration or an investigation while the rest of the estate keeps working.
Operator access consent: On Möbius Cloud, Möbius staff can enter a workspace only if you allow it, for a duration you set, with every entry recorded. On Connect and Enclave there is no Möbius-side path at all.
Capability controls in your hands: Your own admin turns capabilities on and off for your organisation, independently of anything Möbius decides.

How much the AI may do is a dial you set

AI in Möbius runs on the same gate as everything else. It never mutates governance state directly: it produces a proposal a named human approves or rejects, and the proposal is the audit record. How much autonomy is available at all is a workspace posture, not a scatter of per-feature switches.

AI autonomy dial: The workspace sets how far an AI may act on its own — from nothing, to proposal-only, to approved autonomy — as one posture.
Propose and approve: Every AI-originated change is a proposal routed to the people actually entitled to approve it. The proposal, the approver and the outcome are the record.
Out-of-band step-up: High-blast-radius actions require a fresh human confirmation captured on a different Möbius surface, on a separately enrolled device, before they execute.
Scope-bound conversations: An AI conversation can be bound to one group of datasets, and the binding is re-resolved on every tool call rather than only at the start.
Action attribution: Every AI tool call is stamped with which agent acted, on whose authority, over which data.
Private and self-hosted models: AI features can run against models on your own compute. Available on Möbius Connect and Möbius Enclave.

Evidence

Everything above leaves a record you did not have to assemble

There is one governance record and one place it is written from. Certifications, approvals, refusals, grants, revocations, credential mints and policy edits all land in the same stream, stamped with the actor, the environment, the deployment and the enforcement posture in force at the time. A security review is a set of queries, not a document-gathering exercise.

One governance stream: Every governance act lands in a single immutable stream. There is exactly one audit channel, written from one place in the product.
Forensic stamping: Each event carries actor, environment, deployment, credential class and the enforcement mode at the time — so the record answers questions nobody thought to ask when it was written.
Queryable trail: The trail is a query surface rather than an export job. What an audit normally assembles over weeks is a filter here.
Read-only audit credential: Internal audit or an external firm can read governance evidence across every workspace in the organisation without operational access to any of them.
Governance event feed: Your security or ops system can subscribe to this workspace's governance events — certification decisions, posture deviations, role changes, credential mints, policy edits. Available on request rather than switched on by default.
Refusals are evidence too: A blocked write, a cross-environment refusal and a withheld field are recorded with the same weight as an approval. The record shows what did not happen.

What is not built yet

Single sign-on and directory provisioning. SAML and OIDC single sign-on, and SCIM provisioning, are designed and on the enterprise roadmap. They are not shipped today. Access is managed inside the workspace against the role model described above, and every grant, change and revocation is in the governance record — but if your standard is “no application authenticates outside the IdP,” Möbius does not meet it yet.

We would rather you read that here than find it in week three of a procurement process. It is the one enterprise-security question we are asked first, and the answer changes the sequencing of a rollout — so it belongs on the page, not in a footnote. Early access partners have visibility of where it sits in the build order.

If your security review has questions this page does not answer, ask them directly — the answers are the same either way.

Request early access