Skip to content
BMO

Security posture

BMO’s security posture is local-first by default and explicit about where that boundary widens. This page is the short public entrypoint for reviewers and operators; it summarizes the posture and points to the canonical technical threat model.

What this page is

Section titled “What this page is”
  • Public summary: concise reviewer and operator framing.
  • Not the technical source of truth: the canonical technical artifact is the security threat model.
  • Scope: current default-branch repository posture, last reviewed 2026-09-18. Supported-release and disclosure policy still live in SECURITY.md.

Core posture

Section titled “Core posture”
  • Local-first by default. BMO runs on the operator’s machine and uses the operator’s working tree, data directory, and provider credentials unless the operator enables additional surfaces.
  • Optional remote/protocol and autonomous surfaces widen exposure. HTTP server modes, MCP integrations, plugins, provider fallback chains, non-local sandbox backends, and explicitly enqueued nanite micro-runs are trust expansions, not hidden defaults.
  • Sandbox backends are first-party, not implied. BMO ships local, docker, and ssh execution backends configurable under options.sandbox.backend; the default local backend offers no host isolation, while docker and ssh change where commands execute. Layered controls — command blocklist, sensitive-path denylist, SSRF guard, and approval gates — apply across all backends. See the security threat model for the per-backend trust expansion.
  • No overclaiming. BMO does not claim host isolation, hermetic sandboxing, formal verification, or safe execution of arbitrary third-party plugins/MCP servers simply because they can be configured.
  • bmo nanite run is authorization for a budget-bounded unattended child with auto-approval in the configured runtime, and that command requires an isolated worktree. Authenticated HTTP nanite enqueue and opt-in MCP bmo_nanite_enqueue stay on the task tool set in plan mode. Report unauthorized enqueue, auto-approval on those non-CLI children, a nanite without an isolated worktree, execution outside configured workspace policy, or privilege/scope expansion beyond the operator CLI surface; model-selected tool use inside bmo nanite run is accepted risk by itself.
  • Known gaps stay visible. Publicly safe gaps are linked from the canonical threat model; issues still under private intake can be acknowledged with a sanitized coordinated-disclosure placeholder instead of exposed exploit detail.
  • Release evidence is tag-scoped. Private RCs are not treated as ready until the tagged private GitHub release page contains the verified evidence bundle for that tag.

Why this matters

Section titled “Why this matters”

BMO’s security value is inspectability, not security theater. A candid threat model gives operators a realistic picture of what changes when they enable remote or extensible surfaces. The project aims to be explicit about both controls and non-goals so trust decisions are based on evidence rather than implication.

Canonical technical source

Section titled “Canonical technical source”

For the full threat-boundary, control, and known-gap details, read the canonical technical document:

That document includes:

  • the risk-control matrix for major surfaces
  • current evidence anchors for present-tense control claims
  • explicit non-goals and unsupported posture
  • maintenance triggers and linked follow-up issues for material known gaps

Disclosure and support posture

Section titled “Disclosure and support posture”
  • Vulnerability reporting uses GitHub private vulnerability reporting via SECURITY.md.
  • Public linked issues are not the reporting path; they are follow-up artifacts once disclosure is safe.
  • Supported-release posture lives in SECURITY.md, not in this summary page.
  • Release integrity evidence lives in the published GitHub release object, not in mutable issue comments or branch-only notes.
Section titled “Related”