How isanna Hive governance works

Memory your agents can trust, inspect, and erase.

isanna Hive turns agent memory from a black box into governed infrastructure: every write has provenance, every recall is scoped, and every deletion leaves a verifiable trail.

Read this page for the model. Implementation proof is available when a buyer or reviewer needs it.

Eight controls, one trust boundary.

The overview is intentionally simple: each control exists to keep agent memory useful without letting it become unaccountable infrastructure.

Provenance

Who wrote it is stamped by the server, not the caller. The human path hard-pins "human"; client-supplied agent_id cannot forge authorship.

Audit

Every tool call writes an immutable, content-free audit row: action, tenant, status, time, and safe metadata. Never the memory content.

Erasure

Delete and receipt commit in one transaction. If the receipt cannot be recorded, the delete does not happen.

Isolation

Each tenant gets its own physical Postgres schema, FORCE row-level security, and request-scoped org_id. Missing scope fails closed.

Quarantine

Suspicious agent writes are held out of recall until a human reviews them. Attack-shaped text cannot quietly become future context.

Curation

Curator and Knowledge surfaces render live data once tagged memories exist; the spec-02/03 schema evolution chain is applied.

Lifecycle

Memories move through active, superseded, archived, quarantined, and expired states. Default recall prefers current truth.

Local-first

The memory substrate runs on infrastructure you control. Cloud beta keeps the same governance model on isolated Hive-operated infrastructure.

From write to provable erase.

A memory is not just inserted and forgotten. It moves through a governed path with explicit checks at the places where trust can break.

Write

The request enters through the server boundary under tenant scope.

Stamp

Author and request context are resolved server-side.

Index

The memory is embedded and prepared for search without silent merging.

Gate

Poisoning-shaped writes are quarantined before recall.

Recall

Search returns scoped, current, explainable memory.

Curate

Human-approved changes supersede rather than overwrite.

Erase

Deletes cascade; a complete delete + ledger seal mints a hash-chained receipt (a partial one errors instead).

Enough proof to trust the overview. More proof when you need it.

This page keeps the public story readable. The full engineering notes remain available for developers, reviewers, and skeptical buyers.

What the overview proves

API keys resolve to org and tenant scope; setRequestScope writes transaction-local GUCs; RLS gates every row; the request role is non-bypass NOBYPASSRLS with FORCE ROW LEVEL SECURITY. The isolation posture remains schema segregation backed by RLS, with scaling work kept inside that boundary.
The hivemind_app role is NOSUPERUSER NOBYPASSRLS; startup guards and the isolation matrix prove missing and foreign org scope return zero rows.
The MCP server runs with allow-net, allow-env, and allow-read only; ci/request-path-privilege-guard.ts blocks broader deploy permissions and any system-permission expansion.
Recall uses vector and keyword arms, fused by Reciprocal-Rank Fusion, then a relevance, recency, and importance blend.
Structured-table recall and graph-augmented recall are roadmap items — not yet implemented. A learned reranker and reflective retrieval are also roadmap, not shipped.

Share proof selectively

The public page stays intentionally high-level. Detailed architecture notes, SQL/RLS mechanics, retrieval diagrams, and telemetry evidence are kept for direct reviewer or buyer share-outs.