How-to guides

Enterprise Administration & Security

Status: partially shipped. The individual-level building blocks are now live; signed capability bundles, a curated registry with an explicit review/signing distinction, per-Project install scoping, and Sovereign Trust directory policies. What remains roadmap is fleet-level administration: centrally pushing policy, allow-listing publishers org-wide, and hosting your own private registry. Today OOMU is a single-user workstation with real supply-chain and trust controls; the fleet controls below describe where it is heading for managed deployments.

This guide is for corporate IT administrators and security managers who will deploy OOMU across a team. It covers what a security team can rely on today, and the two fleet controls still on the roadmap: restricting where capabilities come from org-wide, and hosting your own private registry of approved capabilities.

Shipped today: signed capability bundles and the curated registry

OOMU's Mods are now capability bundles; versioned packages that can carry skills/instructions, connector declarations, task recipes, specialist-agent profiles, assets, and tests. Every bundle is treated as untrusted supply-chain input:

Signing and review are separate, and shown separately. A signature confirms *who* published a bundle ("identity confirmed"); it does not imply safety. "Reviewed by OOMU" is a distinct claim, made only when OOMU has inspected what the bundle declares and tested its workflows. Sideloaded bundles carry an explicit "not reviewed" warning.
Installation is transactional and declared. Before activation, OOMU verifies the signature, hashes, dependency locks, minimum version, and forbidden/executable content, and shows a human-readable capability diff and the Projects the bundle will apply to. Installs roll back cleanly on failure.
Declarations are enforced at runtime. A bundle that tries to use a capability it didn't declare fails closed, with the exact mismatch surfaced.
Existing Mods keep working. Older Mods migrate through one adapter rather than a second package manager.

Individuals can already browse the registry, see publisher and review status, and install per Project. (The registry's browse/marketplace surface is still filling in; some entries show as coming soon.)

The goal

Give a team the privacy and efficiency of OOMU while keeping the organisation in control of:

What capabilities can be installed, and from where.
Which models and providers are permitted.
A central, vetted catalogue of in-house capabilities.

Roadmap: Restricting sideloading via fleet policy (WIP)

By default, OOMU lets an individual install any .oomu package they choose (with the review/signing warnings above). In a managed deployment, an administrator will be able to constrain this org-wide with policy, for example:

Disable open sideloading so users can only install capabilities from an approved source.
Allow-list publishers by author or signing identity.
Require verification before a capability can be activated.

The intent is to preserve OOMU's safety-by-design model; every capability still runs inside the sandbox; while adding an organisational gate on top of the individual one.

*Design and configuration details will be published when this ships.*

Roadmap: Hosting a private registry (WIP)

Larger teams will be able to host an internal registry of vetted .oomu capabilities, so employees install from a trusted, curated catalogue rather than passing files around.

Anticipated shape:

A registry your workstations are configured to trust.
Versioned, signed capability packages your security team has reviewed.
Centralised updates, so a fix or policy change rolls out from one place.

*Endpoints, hosting requirements, and signing workflow will be documented when this ships.*

What you can rely on today

Even before the fleet controls land, OOMU's core protections already apply to every deployment:

Each capability runs inside an isolated sandbox with path containment, and Mods are constrained to the folders and hosts they declare. See Privacy & Sandboxing.
Signed capability bundles separate provenance from safety, install transactionally with a visible capability diff, and fail closed on undeclared or revoked capabilities (see above).
Sovereign Trust already provides per-directory, time-bounded permission policies with daily resource budgets; an individual-level version of the policy controls a managed deployment will build on. See Privacy & Sandboxing.
Per-Project data policy lets a user (or, later, an administrator) force local-only handling for sensitive work, enforced natively before any network call. See Setting Up a Project.
Capabilities take effect only when a user activates and binds them; nothing changes behaviour silently.
All workspace data is stored in an encrypted local database, with the key held in the OS keychain. See Local Database Schema.
OOMU runs locally first, so sensitive prompts need not leave the machine at all.

Planning ahead

If you're evaluating OOMU for organisational deployment, the most useful things to decide now are:

Your capability policy; will you allow open sideloading, an allow-list, or a private registry only?
Your model policy; local-only, or which cloud providers are sanctioned?
Your data-handling stance; how the local-first model maps onto your compliance requirements.

We'll expand this guide into full configuration reference as the enterprise capabilities are released.