Security mechanisms

The Hivemind Hub gives an AI the ability to act on real machines. That is only defensible if the boundary between the model and the action is rigorous, inspectable, and layered so that no single failure opens the door. This page documents each mechanism that makes up that boundary.

The mechanisms are defense in depth: they compose, and several are structural — enforced by the shape of the code or the database, not by a policy that could be forgotten. None is the sole boundary.

The ten mechanisms at a glance

1. Deny-by-default
2. The tighten-only composition guarantee
3. Never self-approve
4. Fail-closed
5. Params-hash anti-forge binding
6. Confused-deputy defense
7. Least-privilege minted credentials
8. Out-of-band attestation (Ward)
9. The tamper-evident audit chain
10. The code-enforced estate floor

Deny-by-default

Every gate in the system refuses in the absence of an explicit allow. A principal with no matching grant is denied. A verb that does not resolve to a known tier is denied. An unknown target or action is denied. A newly-registered box is seeded from a deny-by-default template — mutating verbs require approval, unlisted actions are denied — never a blank check. A workflow may call only the actions on its explicit allow-set, and each is independently gated at call time.

This is the property that makes the platform safe to extend: a new box, verb, principal, or action starts with zero capability and must be explicitly granted one. Adding a surface cannot silently open a hole, because the default state of any new surface is "refused."

The tighten-only composition guarantee

The single most important structural property. Dispositions are ordered by restrictiveness and composed by min:

denied (0)  <  needs_approval (1)  <  allowed (2)

floor = min(L0, L1)          # hard floor: irreversible/prod classifier + capability
final = min(floor, L2, L3)   # harness policy + operator rules can only pull DOWN

Because the composition is min, any layer can only lower the result. An operator rule of allowed is the maximum value — it cannot raise final above what the floor already permits, so it is dominated unless every layer already allows. A per-target operator rule can therefore tighten an action (dev-box drive → ask-me) but is structurally incapable of loosening a floor (a prod deploy stays at needs-approval no matter what rule is written).

This is a property proven of the composition, not a convention. "The operator cannot self-loosen prod" is true because of arithmetic, not because a reviewer remembered to check. An out-of-band notary (Ward) attests that the composition in the running code is still this min and has not been swapped for an override. See The unified per-target gate.

Never self-approve

The decider of an approval must be a different principal than the asker. The model that proposes a gated action can never be the one that approves it — only a human operator identity can decide. This is enforced at two layers:

• In the application — on the decision path, the approval's guarded update carries a "decider is distinct from the asker" clause (principal_id IS DISTINCT FROM decider), plus a pre-check that refuses a self-decision before it is attempted. An approval cannot be self-issued.
• In the database — the standing-grant table carries a CHECK constraint that a grant's issuer is never its own beneficiary (issued_by <> principal_id), so that guarantee holds at the storage layer even against a code path that forgot the check.¹

Only a human operator can mint an elevation, and an elevation is minted only from an operator-decided approval row. The AI can propose an irreversible action; it can never authorize one.

Fail-closed

Every uncertain outcome resolves to "did not happen," never to "happened without approval":

• Approval timeout — a pending escalation carries a 1-hour TTL. If the operator never answers, an always-on watchdog expires it and delivers a rejection. An unanswered request is a denied request.
• Evaluator or DB fault — a gate or target-resolution fault denies rather than guesses.
• Credential resolution — a revoked or expired credential simply stops resolving; a mint failure means the job does not run, with no fallback to a broader credential.
• Unverifiable attestation — if Ward cannot verify the operator signature on its baseline, or cannot run a probe, it reports a critical unverified verdict; the panel never renders green on doubt.

Doubt always resolves toward refusal.

Params-hash anti-forge binding

When an action is escalated for approval, the pending approval is bound to a params_hash — a hash over the verb, the target, and the params. This nonce nails the approval to this exact action. On approval:

• the one-shot elevation is minted bound to that params_hash, and
• match-before-burn re-checks the actual action's params_hash against the grant before consuming it.

A mismatched action — an attempt to reuse an approval for a different action than the one you saw and approved — is refused without spending the grant. You approve a specific act, and only that specific act can execute. Combined with single-consume (the approval can be acted on exactly once, via a guarded conditional update) and principal-scoped grants (knowing an id is not the same as being able to burn another principal's grant), the approval token is unforgeable and unreplayable, and it never leaves the server on the executed path.

Confused-deputy defense

The Hub holds credentials; the model never sees them. When a workflow action needs a secret, the model emits a structured tool call with no credential field, and the server loads, decrypts, and injects the secret into the outbound client. The model names the action; the server binds the credential.

Because no tool-call schema carries a credential field, the model cannot name, read, or exfiltrate a secret — there is no slot in which a secret could appear in anything the model touches. The credential is bound to the verified principal and job at inject time, so an agent cannot re-target another owner's or tenant's credential. This is the same discipline the claim seam enforces when a session claims a job: identity is resolved and bound server-side, not asserted by the actor.

This mechanism is why the Hub can safely be a conduit for actions that require real credentials: the deputy (the model) is never handed the authority it would need to be confused into misusing.

Least-privilege minted credentials

Where the Hub can mint a scoped credential rather than reuse a standing one, it does. A job authenticates as a short-lived, scoped, expiring principal — not the operator's standing key. A minted credential is:

• scoped to the job's action allow-set and tier,
• short-lived — a TTL no longer than the run's budget window, clamped to a hard ceiling regardless of what is requested,
• job-bound — recorded against the run/deployment job id,
• sealed at rest — stored under authenticated encryption (a modern AEAD cipher with a per-record nonce) for server-side injection only, and
• revoked at the terminal run marks, with a watchdog sweep as a backstop.

The key resolver refuses any key that is not active and unexpired, so a revoked or timed-out credential stops working immediately — fail-closed at the resolution layer. A credential the Hub cannot mint-scope (an external third-party key) stays sealed and is bounded instead by the workflow's action allow-set plus rate and budget caps.

The result: a leaked or misused credential is scoped to one job's actions and dies with the job. There is no standing all-powerful credential handed to a run. See Per-job credential scoping.

Out-of-band attestation (Ward)

A gate you cannot verify is a gate you cannot trust. Ward is the notary that attests the gate's rules, its composition, its floor tables, and its audit chain are intact and un-forged — against an operator-signed baseline.

Its defining properties:

• Report-only, permanently. Ward writes zero changes to any gate, rule, hook, or marker, and never remediates. You cannot let the AI auto-remediate its own gates, so Ward has no code path to remediation by design. It reports; a human acts.
• AI-as-courier. The AI may run Ward, compute the diff, and carry the report — but the operator alone holds the signing key and performs the key-touch to bless a baseline. The AI cannot mint a signed baseline; the estate's operator-OK gate blocks the AI from signing at all.
• Operator-signed baseline. The gate's source files, migrations, and floor tables are enumerated into a single manifest the operator signs (a detached signature over the canonical digest, verified against a pinned operator public key). Ward re-hashes live state and diffs; any drift demands a human re-bless with eyes on the diff.
• Out-of-band isolation. Ward runs outside the Hub's request path, on a timer, under a system user the AI's uid cannot edit — ideally a cross-host read-only pull. A compromised Hub cannot silence its own watcher, because the watcher does not run inside it. Ward reaches the database through a dedicated read-only role (SELECT-only on the specific tables and catalog views), not the app role, and not app-grantable.
• Fail-closed, never-green-on-doubt. Verification runs before any comparison; an unverifiable signature or an un-runnable probe yields a critical unverified verdict, never a clean one.
• Heartbeat + dead-man's-switch. Each run beacons the operator; the absence of a run past its SLA is itself the alert.

Ward attests two kinds of thing: file-resident artifacts (the gate's source and migrations, byte-diffed against the signed manifest) and live database invariants (the audit chain verifies; the tamper triggers still exist; every rule row's provenance is the operator config path; the prod-host set is coherent across both enforcement planes). Attestation is a prerequisite for ever enabling the unified gate in a live deployment.

The Ward engine itself is built and in use for the estate's shell-hook floor; its extension to attest the Hub's own gate — the source/migration artifact set and the live-database probes above — is a designed port that lands, and is blessed against an operator-signed baseline, before the unified gate is switched on in production.

The tamper-evident audit chain

Every gate decision — allow, deny, escalate, approve, expire — lands on a hash-chained audit ledger. Each entry incorporates the hash of the previous entry, so the log is tamper-evident: an entry cannot be altered or removed without breaking the chain from that point forward, which a verification pass detects. The chain is seeded per tenant and can be verified end-to-end; a shortened or forked chain is visible against the head recorded at the last attestation.

The ledger is protected at the database layer as well: triggers reject updates, deletes, and truncation of the audit table, the rule store is upsert-only, and standing grants are append-only (soft-revoke only, with truncation blocked). These constraints are themselves part of what Ward attests still exists — the append-only guarantee cannot be silently removed without the removal being flagged.

Because both executors and the escalation engine share one gate path, the audit is complete: there is no side door whose actions do not appear on the chain.

The code-enforced estate floor

Underneath the Hub's own gate model sits an un-forgeable floor enforced on the box where a command actually runs. On each Commander/workstation box, code-level hooks enforce the hard floor independently of the Hub: a prod/irreversible classifier, forge-resistant operator-OK markers (mintable only through an operator action, not by the AI), a design-before-execute planning gate, and a pre-deploy security-review clearance.

This is deliberately a separate enforcement plane from the Hub's gate. Even if the Hub-side evaluator were bypassed, the box re-checks the floor where the command executes. The Hub honors the same floor (via a mirrored classifier) so it never proposes an action the box would then refuse — but the box's enforcement is the backstop, not the Hub's cooperation. The operator-only actions (prod deploys, new credentials, new DNS, destructive prod ops, history rewrites) always require the un-forgeable marker or a human decide, and no rule can lower them.

Ward attests that the two planes' prod-host and deny-scope sets are coherent — a customer host present in one plane but missing from the other would be a fail-open gap, so set-coherence across the planes is an explicit attested invariant.

---

Verification note

The claims on this page and throughout this site were cross-checked against the Hivemind source (origin/main) while the documentation was written. Where a mechanism is merged on main but ships dark behind a flag that defaults OFF — dev-safe and not yet activated in production — or is still in design, the relevant page says so explicitly rather than implying it is live in production. Any specific claim that could not be confirmed against the code at the time of writing is flagged in place; nothing here is asserted as implemented that was not seen in the source or its migrations.

---

1. Both enforcements were checked against the source (origin/main) while writing this documentation. The decision-path application guard is active; the database CHECK constraint on grant issuance is part of the per-target standing-grant work, which — like several capabilities on this site — is merged on main but dark behind a default-OFF flag (HIVEMIND_ORCH_STANDING_GRANT_REQUIRED), not yet activated in production. See How it is built + verified. ↩