Skip to content

How it is built + verified

The security of the Hivemind Hub is not only in its runtime mechanisms. It is also in the discipline by which those mechanisms are built, reviewed, and turned on. A gate model is only as trustworthy as the process that produced it. This page documents that process.

Survey before design; design before build

Each load-bearing piece of the Hub follows the same order:

  1. Survey the code — before proposing anything, the existing codebase is surveyed to find what already exists and can be reused. The recurring finding across the gate work was "the engine already exists": the approval/escalation spine, the per-action policy engine, the model tool-loop, the credential-sealing and injection seams, and the audit chain were all present and already reviewed before the north-star wiring began.
  2. Design first, in writing — a design document lays out context, the reuse-vs-net-new split, the data model, the composition, the safety invariants, the failure modes, and the open questions. Nothing is built past the design without an explicit go-ahead.
  3. Build the smallest vertical that proves the thesis — each piece defines a single end-to-end slice that exercises every load-bearing seam at minimum surface, rather than building the whole surface at once.

Reusing a proven engine rather than building a parallel one is itself a security decision: there is one approval mechanism to audit, one gate to attest, one audit chain — not two that might disagree. The design work is largely about resisting the duplicate-engine trap.

Reduce, don't add, engines

A guiding constraint runs through the whole architecture: unify, don't multiply. The unified gate does not add another gate system — it defines one composition over the systems that exist. The escalation path does not build a second approval queue — it routes both executors' approvals through one. The credential subsystem does not fork the secret store — it adds a lifecycle over the existing sealing and injection seams. Fewer engines means fewer boundaries to get wrong, and a smaller surface for a reviewer and for Ward to attest.

Two independent security reviews before anything ships

Every change is cleared by two distinct security passes before it merges or deploys:

  • A fast pre-merge review scans for secrets about to ship and for vulnerabilities, and writes a per-commit clearance that the deploy gate checks. No deploy command runs until the current commit is cleared.
  • A deep security audit examines the security-critical surface at maximum scrutiny — for this work: least-privilege scoping, the guarantee that a credential is never leaked to the model, confused-deputy safety, revoke reliability, the caller-auth composition of any exposed surface, and injection into the prompt path.

The credential-minting work and any live network exposure are explicitly gated on the deep review, because minting credentials and exposing an AI-driving control surface are the highest-consequence surfaces in the system.

Dark launch: flags default OFF

Every security-tightening capability lands behind a flag that defaults OFF, and is proven before it is switched on in any live deployment:

  • the per-target standing-grant requirement,
  • the credential-scoping subsystem,
  • the unified gate,
  • the productization/config-store records.

A capability can therefore be merged, reviewed, and tested against a live-shaped environment while remaining inert in production. Enabling it is a deliberate, separate, operator act — for the highest-consequence flags (a live control surface, the unified gate), gated additionally on the out-of-band notary (Ward) attesting the relevant floor and composition are intact.

Property-first and RED-first testing

The tests are written to be an executable specification of the invariants, and are written before the implementation (RED-first — the test fails first, then the code makes it pass). The acceptance verticals assert the invariants directly, for example:

  • a minted credential resolves while live and stops resolving after revoke (fail-closed);
  • the model never sees the secret — asserted structurally, that no tool-call shape carries a credential field;
  • an expired mint is refused;
  • a job under one owner cannot resolve or see another owner's credential (cross-owner and cross-tenant denied);
  • the served control surface exposes exactly the intended verb set and nothing beyond (verified at the served layer, not by reading a config allowlist);
  • a caller without a grant is denied, and a request missing its transport proof or its verified principal is rejected.

The composition guarantee in particular is meant to be provable: the min-structure is what makes "an operator rule cannot loosen a floor" true, and both the tests and Ward's attestation target that structure directly.

Evidence, not narration

A claim of "done," "passed," or "verified" is backed by the artifact that proves it — a commit hash, a test exit code, a served-surface probe, a signed attestation — not by a narrative. This documentation follows the same rule: its technical claims were cross-checked against the source on origin/main, and anything that is merged but ships dark behind a default-OFF flag (not yet activated in production), or is still in design, is described as such rather than implied to be live in production.