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.

Seen it demonstrated? Start here instead

This site is written for people who want to know how the thing is built. If you arrived having watched Hivemind do something and want to know what you just saw, read What happens when you ask it something first — it walks that exact sequence in plain terms and links back into these pages for each step.

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.

For per-job credential minting the flag is not what holds it dark. Measured on main: nothing in the server calls the minting entry point, so enabling HIVEMIND_CRED_SCOPING_ENABLED does not turn it on — what remains is a call site, not a setting.

Two things on this page are drawn as they are designed, not as they run today, and the prose below does not repeat the caveat every time:

  • The chain diagram and Executor A's placement — a Commander being started on a chosen target box — describe the intended execution path. Do not read the routing below as a description of what runs today.
  • Approval does not yet dispatch. The escalation spine — gate, enqueue, route-up, notify, decide, audit — is live. The final link is not: an approved request is not consumed by the executor. See Approval-escalation path.
  • The agent runner is a separate component, and the documented install does not place it. Executor A's path depends on it. See Install.

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 --> Cmd[Commander<br/>Claude Code session]
    Cmd --> MW[Managers / Workers]
    MW --> Estate[(Estate:<br/>machines, repos,<br/>services)]
    Hive -. observes + gates every step .-> Estate
    Cmd -. registered once running .-> Spawn[Spawn<br/>operator view]
  • 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.
  • The Commander is the AI coding session (a Claude Code process) that runs in a terminal to do work needing a machine, fanning out to Managers and Workers. In the design the Hub starts and drives it. Today the code that launches an agent session lives in the agent-runner component, an opt-in part of the install (see Install). Your own Commander runs on a workstation, and Facet reaches it through the Commander link.
  • Spawn is the operator-facing view of the same fleet. It runs on the workstation, not on the Hub: it is installed there from its own release tarball, and it carries the Commander link's workstation half. Its job today is visibility — a running agent is registered into Spawn after it has already started, and Spawn's own mutating verbs deliberately refuse to act on it, because the Hub's authorization already decided that agent should run and two independent authorities over one session would have no ordering between them. Spawn becoming the plane the Hub routes execution through is the direction of travel, stated here as a direction and not as current behavior.
  • 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. This path needs the agent-runner component, which a current install does not include.

    "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.

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.