Coming soonOOMU is launching soon. Downloads will open at launch.
OOMU
← All documentation

Explanation

Privacy & Sandboxing

How your data stays protected.

OOMU is built for people who can't afford to be casual about data; lawyers, financial advisors, executives, compliance managers. For them, "where does this information go?" is not a curiosity; it's the whole question. This page explains how OOMU answers it.

The problem with traditional plugins

Most "extensible" AI tools ask you to make an uncomfortable trade. To get a useful add-on, you install a plugin that, in practice, runs with the same access you have: your files, your network, your credentials. You're trusting not just that the plugin is *well-intentioned* today, but that it will *stay* well-intentioned through every future update, and that it has no bugs an attacker could use.

For a professional handling confidential material, that's not a trade worth making. A single careless or compromised plugin can read anything on the machine.

OOMU is designed so you never have to make that trade.

Containment by default: the sandbox

When OOMU works with files, it does so through a sandbox; a bounded area of your disk that defines exactly what is in reach. The sandbox isn't a suggestion enforced by good behaviour; it's enforced structurally by the engine, on every access.

Here's what that enforcement actually does:

  • Every path is resolved to its real location first. Before any file is touched, OOMU canonicalises the path; following any aliases or symbolic links to where they *actually* point. You can't smuggle access by pointing a shortcut at something outside the boundary, because OOMU checks the real destination, not the label.
  • Anything outside the boundary is refused. If the resolved path doesn't sit inside the approved area, the request fails with a clear "path escapes the local sandbox"; full stop. Absolute paths to system files, .. traversal tricks, and symlink escapes are all rejected.
  • Reads are bounded. When OOMU reads a file or folder for context, it caps how much it will take; per file, in total, and how deep it will walk a directory tree. A capability can't quietly vacuum up your entire disk under the guise of "reading context."
  • Approved areas only. File context is limited to your own user area, the workspace, and the system temporary directory; not arbitrary system locations.

The result: OOMU's reach over your files is *defined*, *narrow*, and *checked every single time*; not granted once and forgotten.

How capabilities (Mods) stay safe

OOMU's extensibility is built on the same principle. A Mod is a self-contained .oomu capability package, and it lives inside the safety model rather than around it:

  • It's installed into your workspace, not your system. Installation unpacks the package into OOMU's own capability folder, with size and structure limits checked first. It doesn't scatter files across your machine.
  • It declares exactly which folders and hosts it can reach, and you see them. A Mod's permissions are a precise list: the specific directories (allowed_paths) and web hosts (allowed_hosts) it's allowed to touch. These are shown to you on the install screen, and; crucially; OOMU enforces them at runtime. A Mod cannot read a folder or contact a host it didn't declare; the attempt is blocked. A Mod that declares nothing can only shape how your assistant writes.
  • It only acts through the engine. A Mod can't reach your files or network on its own; it works through OOMU's mediated commands, inside the same sandbox boundary described above.
  • It does nothing until you say so. A freshly installed Mod is inert. It affects an assistant only when you both activate it and bind it to that assistant. There is no "install and it's suddenly everywhere" surprise.

An honest boundary on trust. OOMU verifies that a package is well-formed, contained, and limited. It does *not* claim to read the mind of whoever wrote it. Treat a .oomu file like any download; install from sources you trust. What OOMU guarantees is that even a trusted-but-flawed Mod operates inside a narrow, enforced box.

You control what a tool can reach

The permission model puts the decision where it belongs; with you:

  • Permissions are declared up front and shown before install.
  • Capabilities are off until bound to a specific assistant.
  • Binding is per assistant, so a capability you trust for one task isn't silently applied to another.
  • Everything is reversible; unbind, deactivate, or uninstall at any time.

Trust you grant deliberately: Sovereign Trust

The sandbox defines OOMU's *maximum* reach. Sovereign Trust lets you govern, folder by folder, how much of that reach OOMU may actually use, and for how long.

When OOMU needs to work in a directory, you can grant a trust policy scoped to that specific folder. Each policy carries:

  • A scope; the exact directory it applies to (and only that directory).
  • Allowed tool categories; which kinds of actions are permitted there.
  • A permission level; how long the grant lasts:
  • One-time; for this action only.
  • Session-gated; for the duration of a working session, then it expires.
  • Global trust; a standing grant for that folder until you revoke it.
  • Resource budgets; a daily ceiling on token cost and on CPU time, tracked and enforced. Even a trusted folder can't run away with your resources.

You can see every active policy and session on a trust dashboard, and revoke any of them at any moment. This turns "can OOMU act here?" from an all-or-nothing question into a precise, time-bounded, auditable decision that you control.

Your data at rest: encrypted, and keyed to your device

Everything OOMU remembers; assistants, conversations, settings, capabilities; is stored in an encrypted database on your Mac.

  • The encryption key is derived from a secret held in the macOS Keychain. It is never stored in plain text on disk and never transmitted.
  • Because the key is bound to your device's Keychain, the database is only readable by OOMU, only on this machine. A copied database file is not enough to read your data.
  • Sensitive records carry their protection state with them, so the system always knows how a given row is secured.

See Local Database Schema for the specifics.

Your data in motion: local first

The strongest privacy guarantee is the one where data simply never moves. OOMU's local-first design means:

  • Your default assistant runs on your Mac. Ordinary conversation need never touch the internet.
  • The cloud is reached only when you've configured a provider and routing selects it; using your API key, to the provider's official endpoint, directly from your machine.
  • Automated web grounding is off by default. OOMU will not search the internet on its own initiative unless you deliberately enable it in Settings → Privacy. When you do turn it on, OOMU uses a private DuckDuckGo Lite search, reads the results locally, and answers from them, and any fact it later commits to memory keeps a traceable link back to the search it came from.
  • A Project can forbid the cloud outright. Each Project carries a data policy; *keep everything on this device*, *ask before using cloud models*, or *allow configured cloud models*. The engine evaluates it before any provider, connector, remote, or browser transmission, so "local only" is enforced structurally, not merely respected. When a policy requires consent, OOMU shows a redacted preview of what would leave first.

This is the difference between privacy as a *policy* and privacy as a *property of the architecture*. In OOMU, staying local isn't a promise to be trusted; it's the default path the software takes.

The same boundary, extended to everything OOMU does

As OOMU gained the ability to connect services, operate apps, and work remotely, each new power was built *inside* the model above rather than around it:

  • Connected services keep secrets out of reach. OAuth and refresh tokens for Google Workspace, Slack, and Microsoft 365 live in the macOS Keychain; the database holds only an opaque reference and non-secret metadata. A connector's token is bound to the service's official origin, so the interface can't retarget it. Reads are direct; anything that sends or changes something is an approval-gated action, evaluated against the Project policy first. OOMU only ever offers a sign-in method it has fully implemented.
  • Automation observes before it acts. When OOMU drives its contained browser or a qualified Mac app, it works only on elements it can see in a fresh snapshot; no arbitrary JavaScript, no raw AppleScript, no blind clicks. Page content can't call OOMU's internal commands. Downloads land in quarantine; uploads are explicit. It pauses at password fields, CAPTCHAs, and anything ambiguous, and you can take over instantly. Every claimed action must have an observed result behind it. See Automating Your Mac.
  • Remote access is least-privilege. A messaging channel or (in future) a paired device gets a narrow, revocable, Project-scoped, task-limited set of rights. It can start and check work; it can never receive your credentials or browse your files, and it can't expand its own scope. Remote commands are signed, nonce-bound, idempotent, and audited. See Working Remotely.
  • Media capture is off by default. Microphones stay visibly off unless you enable them; images and voice notes become provenance-tracked assets, and a local-only Project never routes them to a cloud provider.
  • Extensions prove provenance, not safety. A capability bundle's signature identifies its publisher; nothing more. OOMU keeps that separate from whether it has reviewed the bundle, shows you an exact capability diff before install, installs transactionally, and fails closed at runtime on any capability the bundle didn't declare.

A note on optional telemetry

OOMU keeps a small, separate operational record (in oomu_ops.db) related to licensing compliance. This is deliberately partitioned away from your working data, the identifiers it uses are hashed or masked, and the compliance beacon can be switched off in your privacy settings. Your conversations, files, and assistants are never part of it.

In short

OOMU protects you with structure, not just intentions: a sandbox checked on every access, capabilities that are contained and opt-in, a database encrypted to your device, and a local-first default that keeps most work from ever leaving your Mac.