Privacy & security

OOMU is built for people who cannot be casual about data: lawyers, advisors, executives, clinicians, anyone under a confidentiality obligation. For them the question is not whether a tool is useful. It is where does this go?

Here is the honest answer, including the parts that are not absolute.

---

The default is your Mac

The strongest privacy property is the one where data never moves.

• Your assistant runs on this Mac. Gemma 4, through llama.cpp, on Apple Silicon. Ordinary conversation never touches the internet.
• The router runs on this Mac. The model that reads every request and decides what to do with it is local, always. There is no "send it up to classify it" step.
• Document extraction runs on this Mac. PDFs, Word files, spreadsheets, and CSVs are parsed natively. "Reading document locally…" is literal.
• Retrieval runs on this Mac. Ask Documents scores passages with BM25 and cosine similarity in native code and answers with the local model. The panel confirms: "Answered on this Mac in {seconds}s."
• Comparison runs on this Mac. "Review aligned clauses, commercial terms, and rate differences without sending source files off this Mac."
• Document generation runs on this Mac. Four native engines, no service dependency.
• Clipboard classification runs on this Mac. The quick-action suggestion is native code, not a lookup.
• Mochi's reading runs on this Mac. Previews of new downloads, sorting your mail, and finding the commitments in it all use the local model. See What Beta 4 adds for the few interests that need the network.
• Standing memory is built on this Mac, overnight, by the local model, and it is never included in a request to a cloud model.

The cloud is reached only when you have configured a provider, you have allowed it (for the chat, or for Automatic in Settings), the project permits it, and the request calls for it, using your key, to the provider's own endpoint, directly from your machine. There is no OOMU server in the path. OOMU operates no service that sees your work.

---

The gates before anything leaves

None of these is a request the model is asked to honor. They are structural.

---

Data at rest

One SQLCipher-encrypted SQLite database, oomu-beta4.sqlite.

• The key is held in the macOS Keychain, under a Beta 4-specific service namespace. Never in plain text on disk, never transmitted.
• cipher_memory_security wipes sensitive pages from memory; secure_delete overwrites removed content.
• OOMU verifies the database is actually encrypted after opening and refuses to proceed if it is not.
• A copied database file is not enough to read your data.

What the encryption does not cover

The database is the encrypted part. It is not the only part.

Files you export, documents OOMU generates, files waiting in Ready for review, and cached copies can remain unencrypted on disk. A DOCX you asked for is an ordinary file in an ordinary folder, protected by FileVault and your account password like everything else on your Mac, and not by SQLCipher. The in-app notice says this in the same words, because a reader who assumes the encryption is total will make a worse decision than one who knows where it stops.

Standing memory is the exception that goes the other way: it lives in the encrypted database, and the three memory files OOMU keeps beside it are encrypted too, in a folder only your account can open.

Secrets are not in the database

API keys, OAuth refresh tokens, and Slack and Discord tokens live in the Keychain. The database holds only opaque references and non-secret metadata.

Two design details follow from this, and both are deliberate:

• Opening a settings screen does not read the Keychain. Credentials are loaded only when a route that needs one has actually been chosen.
• A key is verified against the real provider before it is stored. A key that does not work is never saved.

The Secure Enclave

Audit exports are signed by a key that lives in the Mac's Secure Enclave and cannot be extracted: not by OOMU, not by anyone with the file. OOMU verifies its own signature before accepting an export, and refuses to produce one that is not hardware-backed. See Enterprise security.

---

Device permissions belong to macOS

This is the largest change from Beta 1, and it is worth being direct about why.

Beta 1 built its own permission system on top of macOS: a file sandbox, a permission broker, trust policies with resource budgets, a capability gatekeeper. Beta 2 removed all of it.

Not because security mattered less. Because the layer was making things worse.

A second permission system creates a second thing to reason about. When two systems disagree, the more permissive one wins. And an in-app dialog in front of every action trains exactly one behavior: clicking through.

So macOS governs access to your machine, and every native macOS permission is enforced. It asks once, in its own dialog, in its own words, at the moment a feature needs it: and your answer lives in System Settings alongside every other application on your Mac, managed the same way, revocable the same way, auditable the same way.

Settings → Connections & Apps → Mac access shows you what macOS has granted across ten categories, in eight possible states. It is a report, not a control: OOMU cannot grant itself anything, and there is no override.

A split of responsibility, not an absence of one. macOS decides what OOMU may reach. OOMU decides what may leave, through the gates above. And the one action that can do anything a shell can, running a command, is shown to you in full and runs only when you approve it in a macOS dialog.

What OOMU enforces itself

Beyond egress, what OOMU adds is integrity:

• Identity binding. Before acting on a file, OOMU resolves the real path (symlinks rejected) and records device, inode, size, and modification time. If the file changed between looking and acting, the action fails.
• Reference binding. Browser and screen actions target an element from a specific observation. A stale reference fails rather than clicking whatever is now in that position.
• Postcondition verification. Every action is checked afterwards. See Evidence & receipts.
• Human file selection. Every choose_* command opens a native macOS dialog. A path is never a parameter. No model output, prompt injection, or page content can direct OOMU at a file.

That last one is worth restating, because it is the strongest structural defence in the application against prompt injection. OOMU cannot be talked into opening a file. A human picked it, in a system dialog.

---

Untrusted content stays labeled

Every segment of context in a turn snapshot carries a source label recording its type, its principal, and a content digest. Text you typed and text that arrived from a web page or a document are distinguishable throughout the turn.

Web content rendered in OOMU's browser cannot reach OOMU's commands: the Content Security Policy restricts connect-src to OOMU's own IPC channel, and there is no capability to evaluate arbitrary JavaScript in a page.

---

Extensions cannot widen the surface

A Mod's signature identifies its publisher. It does not make the Mod safe, and OOMU does not conflate the two: Verified publisher and OOMU reviewed are separate badges answering separate questions.

---

What OOMU sends, and what you can turn off

No telemetry

OOMU sends no diagnostics, usage metrics, or prompt history, to us or to anyone. There is no analytics setting, because there is nothing to turn off. The app says it in one line: "OOMU does not send diagnostics, prompt history, or usage metrics as telemetry."

This changed. Beta 2 at launch offered optional anonymous diagnostics through Google Analytics. They were removed in a Beta 2 update and have stayed gone since: the code that once sent them now accepts the old calls and discards them, with no network access, no identifier, and no storage.

Update checks

OOMU keeps three things current, and fetches each from a fixed address:

• The app. Checked at launch and every 24 hours against a signed manifest, verified with a minisign public key compiled into the build. The request carries the app version and processor architecture, and no device or account identifier.
• The list of cloud providers and models. A signed catalog, checked on launch and when you choose Refresh models.
• The System 1 router. Checked at launch and every 24 hours, from Hugging Face or OOMU's mirror, and verified by hash before use.

You choose when to apply an app or router update. Air-Gap Mode skips every one of these checks. The first model downloads during setup come from the models' official sources.

Everything else

Cloud model calls, when you have configured a provider and the project permits it. Web search, when a request needs current information. Connector calls, when you use a connected service. The Browser Bridge, to the AI chat you opened in your browser. Replies to your Slack or Discord commands, when you have connected one. Weather forecasts and news feeds, when you have turned on the Mochi interests that use them. And on a Mac your organization manages, check-ins to its own OOMU Control server, which carry counts and policy versions, never your content.

That is the complete list. The next section takes the Beta 4 items one at a time.

---

What Beta 4 adds

Mochi can watch things for you, and Slack or Discord can approve its work. Here is exactly what each new feature sends, and where.

Slack and Discord deserve one more sentence. Your commands and OOMU's replies are messages in those apps, held by Slack or Discord the same way as every other message there. OOMU adds no service of its own in between, and the only account that can give commands is the one you chose. See Approving from Slack or Discord.

Work done on its own waits for you. Files that OOMU writes during a scheduled run go to Ready for review instead of your folders, and any other change a scheduled run would make is refused before it happens. Nothing promotes a waiting file except a person. Every decision, from your Mac or your phone, is kept in an approval history that can be added to but not edited. See Working with Mochi.

---

Deletion

Chats, projects, and workflows delete in two stages: staged with an Undo, then purged permanently when the undo period ends. secure_delete means the purge overwrites rather than merely unlinking.

The undo window is ten seconds, and it is enforced natively rather than by the toast you can see. Pressing delete a second time does not shorten the window on the first one.

What the permanent stage actually removes, for a chat:

• The session, its messages, and its attachment rows.
• The mutation replay payloads, scrubbed before the database cascade runs. This matters because a replay ledger that still held the text would make the deletion cosmetic.
• The cached attachment blobs on disk, unlinked after the commit. Your original file is untouched: OOMU deletes its own copy, not the document you imported.

Three boundaries, stated because each one is a place where a reasonable person would guess wrong:

Memory is separately visible in your Profile, each entry showing its scope and its date, with a Forget button. Forget replaces the stored text and its digest, so the original wording is gone rather than hidden behind a flag, and the app declares the action irreversible because it is. Every memory record stores the session, turn, and goal it came from, so you can always see where a remembered fact originated.

Standing memory sits on the same screen. Forget there clears the fact and the quoted words it came from, and leaves a marker so the overnight update does not bring the fact back.

---

GDPR and the EU AI Act

Settings → GDPR & EU AI Act holds three disclosure cards. They are translated into all twelve supported languages, because a disclosure a reader cannot read is not a disclosure.

The cards open with a sentence that governs everything under them, and it is the sentence to keep:

"These disclosures describe product behavior, not legal certification."

That distinction is the whole posture. OOMU tells you what it does, in specific terms you can check against the application. It does not claim that doing those things makes anyone compliant, and neither does this page. Whether your use of any tool satisfies an obligation is a question for your counsel, who will want facts rather than a badge.

What the three cards cover

Provenance in generated documents

DOCX and XLSX files OOMU produces carry three markers in the OOXML package properties: a category of AI-Assisted Business Deliverable, OOMU_Generated set true, and OOMU_Generator naming the application.

The markers live in the document's properties, not in its visible content. There is no watermark across your text and no line added to your spreadsheet. A tool that reads file metadata can establish that OOMU generated the file; a reader opening it sees the document you asked for. Tests assert both halves of that.

Two limits, and both are deliberate:

• Metadata is not a signature. It is machine-readable provenance, not a cryptographic attestation, and it can be stripped by anything that rewrites the file. It supports an Article 50(2) marking obligation; it does not discharge one on its own, and the application says so in those terms.
• It covers DOCX and XLSX. PDF and PowerPoint output from the other native engines does not carry these properties in this build.

The narrow router is not a legal classification

The System 1 router is deliberately small and deliberately constrained. It is Bosun v3.1, a 0.6-billion-parameter model published under Apache-2.0. It reads a request and scores a short list of options; it writes no text, and it holds no rights to execute a tool or touch a credential.

It would be convenient to argue from that narrowness to a conclusion about how the model is classified under the AI Act. OOMU does not make that argument. A narrow integration does not by itself prove that general-purpose capability is absent from the underlying weights. OOMU records the model's source, exact file hash, and runtime limits precisely so that the question can be answered with evidence rather than with an assertion that happens to suit us.

---

The honest caveats

A page like this is only worth reading if it includes the parts that are not absolute.

• A cloud call is a cloud call. If you enable a cloud model and use it, that content goes to that provider under their terms. OOMU makes the decision visible and governable; it does not make it private.
• macOS access is coarse. Granting Automation for an app grants it for that app, not for one folder within it. That is macOS's model, and OOMU inherits it.
• A Mod is content you chose to trust. OOMU verifies its files and bounds what it can declare. It does not evaluate whether the content, or its instructions, are good advice.
• A local MCP tool is a program on your Mac. You picked the executable. It runs with your privileges, and OOMU's read-only marking is a routing decision, not a kernel-level restriction.
• Encryption covers the database, not the folder. Exports, generated documents, files waiting for review, and caches sit on disk as ordinary files.
• Slack and Discord hold their own messages. OOMU limits what its replies can say. It cannot change what those services keep.
• Deletion is not forensic erasure. Rows, replay payloads, and cached blobs go. Backups, snapshots, and unreused SSD blocks are outside what any application can promise.
• Provenance metadata is not a certification. It marks a file as AI-assisted. It does not make anyone compliant, and it survives only as long as nothing rewrites the file.
• This is a beta.

---

Related

• Enterprise security: Air-Gap Mode and the signed audit ledger.
• Local database schema: exactly what is stored.
• Evidence & receipts: how OOMU proves what it did.
• Connecting services: what each connection grants.