Skip to content

Hivemind Hub — Architecture & Security

Hivemind is a multi-agent AI orchestration platform. This site documents how the Hivemind Hub — the central brain that takes an intent, chooses how to run it, and holds a single security boundary over everything it does — is built and how it is secured.

We publish this in full. The architecture and the security mechanisms are the point: the value of an AI that can act on real infrastructure is entirely in the rigor of the gate that sits between the model and the action. That rigor is only trustworthy if it can be inspected. So the design below is open — the data model, the composition math, the failure modes, the invariants. What we withhold is narrow and operational: credential values, live production topology, and deployment-specific runbooks. Open design, private ops.

Scope + status

This describes the Hub's architecture and security model as designed and, where noted, as implemented. Some parts are live in the platform today — the approval-and-escalation spine, the tamper-evident audit chain, the credential sealing and server-side injection seams, the model runtime, and the verb-tier and role-floor model. Others — the per-target standing-grant model, the remote-Commander control surface, the LLM-workflow runtime, the unified gate, and per-job credential minting — are merged on main and dark behind flags that default OFF (for example HIVEMIND_ORCH_STANDING_GRANT_REQUIRED, HIVEMIND_UNIFIED_GATE_ENABLED, HIVEMIND_CRED_SCOPING_ENABLED) — dev-safe, and not yet activated in production. Where a capability is dark-launched or still in design rather than generally available, the page says so. This is the dark-launch discipline described in How it is built + verified.

The one idea

A person should be able to say "do this" and have it happen across their machines — safely — without hand-running brittle scripts and without handing an autonomous model an unbounded blank check.

Hivemind is the layer that makes that safe. Every intent funnels through one hub. The hub decides how to execute it, and every action the execution takes — whether a model running in a terminal on a remote box or a tool call inside an in-process reasoning loop — passes through the same gate. One evaluation model, one approval path, one audit chain. There is not a lenient path and a strict path; there is one path.

The chain

flowchart LR
    You([You]) --> Facet
    Facet --> Hive[Hivemind Hub<br/>brain · hub · conduit]
    Hive --> Spawn[Spawn / control surface]
    Spawn --> Cmd[Commander<br/>Claude Code session]
    Cmd --> MW[Managers / Workers]
    MW --> Estate[(Estate:<br/>machines, repos,<br/>services)]
    Hive -. observes + gates every step .-> Estate
  • You state an intent.
  • Facet is the conversational surface you talk to — chat on your phone or desktop. It renders what the Hub is doing and is where approvals land.
  • The Hivemind Hub is the brain, the hub, and the conduit. It receives the intent, classifies it to an executor, and is the single point every action flows through. Nothing reaches the estate except through it.
  • Spawn is the control surface the Hub uses to start and drive a Commander — an AI coding session (a Claude Code process) running in a terminal on a target box.
  • The Commander fans out to Managers and Workers — additional agent sessions that do the concrete work.
  • The Estate is the fleet: the machines, git repositories, and services the work actually touches.

At every hop, the Hub is not merely a relay — it is the conduit that observes and gates. An action does not become "allowed" because it is deep in the chain. It is evaluated against the same model wherever it originates.

Two executors, one gate

The Hub picks, per intent, one of two ways to run it. This is the two-executor model, and it is the structural heart of the system.

  • Executor A — spawn a Commander

    For work that needs a machine: code, builds, QA, deploys, long-running interactive sessions on a box. The Hub starts a Claude Code session (a Commander) on the target host and drives it. The model's reasoning runs inside that external session; the Hub observes it and intercepts at the gates.

    "Build the feature and ship it to dev."

  • Executor B — run an LLM-workflow

    For "read, reason, act" work expressible as a bounded loop over gated actions, with no persistent box or build. The Hub runs the model loop in-band — its own Claude Messages-API calls and tool use. Because the Hub itself makes every call, it sees and controls every step by construction. No terminal is spawned unless the workflow actually calls a spawn action.

    "Every morning, summarize the newsfeed and post it to my site."

The two executors are not two security regimes. A Spawn verb in executor A and a curl in executor B resolve to allowed / needs-my-approval / denied through the same evaluation function over the same rule store. That is the literal meaning of "one gate model." Executor B can even invoke executor A as a sub-step (calling a spawn action mid-workflow) — through the same gate. The selector only picks the top-level executor.

Why "everything funnels through Hivemind" matters

Centralizing execution is what makes the security model possible:

  • One place to gate. Every action is evaluated at one choke point, so a policy is enforced uniformly instead of re-implemented per surface.
  • One place to escalate. When an action needs a human, it pauses and routes up to you through one path — and resumes exactly where it left off on approval.
  • One place to audit. Every decision — allow, needs-approval, deny — lands on a single tamper-evident, hash-chained ledger.
  • One place to attest. An out-of-band notary (Ward) can verify that the gate's rules and composition are intact against an operator-signed baseline, because there is a single gate to attest.

The rest of this site walks the flow end-to-end (How it connects), documents each capability in depth (Features), lays out every security mechanism, and describes how the system is built and verified.