DWG No. CT-002 · REV C
SCALE 1:1 · SEALED_BY: hunta.ai
SHEET 01 OF 07
DWG No. CT-002 · REV C · SCALE 1:1 · SEALED_BY: hunta.ai · DATE 2026-07 · SHEET 01 OF 07
Attestable agent memory · watertight compartments · over MCP

One breach can’t flood the others.

Attestable, per-tenant-isolated agent memory over MCP. Isolation is a sealed compartment, not a WHERE-filter. Inspect the wall, then check the countersignature.

COMPARTMENT_A · TENANT_A · SEALED
schema t_a1f… · DEK 🔒 · HNSW
⚠ Dr. Alvarez, 555-0142 present
↤ 240 ↦
VOID / SPECIMEN
UNCERTIFIED
↤ AIR-GAP ↦
COMPARTMENT_B · TENANT_B · SEALED
schema t_9c2… · DEK 🔒 · HNSW
⚠ recall returned: Dr. Alvarez, 555-0142
↤ 240 ↦
VOID / SPECIMEN
UNCERTIFIED
CTRR 0.0% PROBES 3/3 CONCLUSIVE SEALED ✓ Ed25519 JWKS.JSON COUNTERSIGNED

Static dry certified drawing by default. Flip the toggle to run the breach test — nothing animates until you interact.

◲ SHEET 01 / 02
DWG No. CT-002 · REV C
SCALE 1:1 · SEALED_BY: hunta.ai
SHEET 02 OF 07
SHEET 02 OF 07 · CONDITION: UNCERTIFIED PARTITION
The breach · metadata filter · flood path

Every incumbent seals tenants with a WHERE-filter. Filters have no walls.

mem0, Zep and Supermemory scope tenants by metadata — a tenant_id / user_id / group_id filter over one shared store. There is no bulkhead: both tenants sit in the same hull. When a scope is misconfigured or forgotten, the other tenant’s data is still physically present in the same index. It doesn’t fail loudly. It floods.

Reproduced: mem0ai/mem0 #3998 (documented, closed via PR #4245)

One gateway, one shared userId, a healthcare-clinic-SOP agent and a consumer personal-assistant agent behind it. Ask the personal assistant “who do I contact after hours?” and the clinic’s marker — ‘Dr. Alvarez, 555-0142’ — floods back into the wrong compartment. On a shared store, CTRR = 100.0%. FLOODED.

HONEST NOTE — This reproduces a specific, cited issue — synthetic PHI only. mem0 closed #3998, but the class is architectural, not a one-off: #5439 (cross-scope entity linking) is open and unpatched. A patch can fix one filter; it can never give a filter a wall to certify.

See the breach live: use the toggle in the hero above (or the scorecard on Sheet 05) to flip to shared store and watch COMPARTMENT_A flood into B.

◲ SHEET 02 / 03
DWG No. CT-002 · REV C
SCALE 1:1 · SEALED_BY: hunta.ai
SHEET 03 OF 07
SHEET 03 OF 07 · ASSEMBLY: DEFENCE-IN-DEPTH
The bulkhead · structural, then attestable

The wall is built in three riveted layers.

Tenant identity is never a request parameter. It is a signed tid claim inside the OAuth 2.1 access token — no MCP tool accepts a tenant argument, so a caller can only ever touch its own compartment. Any body or header tenant field is ignored and logged. Under that identity, three independent enforced layers form the hull:

DETAIL Detail 01 · Physical

One schema per compartment

Each tenant gets its own Postgres schema (t_<sha256[:16]>) owned by a per-tenant NOLOGIN role, with its own tables, own HNSW index and own tsvector. Every op runs under SET ROLE with GRANTs scoped to that schema only. A cross-schema read raises InsufficientPrivilege at the database — there is no shared index to filter.

DETAIL Detail 02 · Logical

FORCE ROW LEVEL SECURITY backstop

A FORCE RLS policy binds even the table owner to tenant = current_setting('app.tenant'). Defence-in-depth backstop — never the boundary, always the second wall behind the first.

DETAIL Detail 03 · Crypto

Per-tenant envelope encryption

Memory content is AES-256-GCM ciphertext under a per-tenant DEK with the tenant id as AAD, wrapped by a per-tenant KEK in a self-hosted KMS (Vault Transit / OpenBao). Even a forced logical bypass returns bytes that decrypt to garbage without the peer tenant’s key — provable by a fault-injection probe. Embeddings stay plaintext inside the tenant’s own schema so ANN + BM25 still work.

↤ NO SHARED HULL · NOTHING CROSSES THE AIR-GAP ↦

◲ SHEET 03 / 04
DWG No. CT-002 · REV C
SCALE 1:1 · SEALED_BY: hunta.ai
SHEET 04 OF 07
SHEET 04 OF 07 · INSPECTION CERTIFICATE
The stamp · Ed25519 · countersigned

A stamped drawing you can re-verify — not a chip you have to trust.

verify_isolation() runs a live adversarial breach test between two compartments — it writes a secret into COMPARTMENT_A, then as tenant B attempts recall plus a forged body {user_id:A}, and asserts cross_read_results == 0. It returns a compact Ed25519-signed detached-JWS manifest binding {tid → store_id → kms_key_id → schema → policy_hash → probe_result_hash → git_sha → ts}, with a conclusive flag so no probe can false-green on 0/0.

// detached JWS — verify_isolation() { "tid": "t_a1f0c9d3e2b7", "store_id": "pg-eu-1", "kms_key_id": "kek/t_a1f0c9d3", "schema": "t_a1f0c9d3e2b7", "policy_hash": "0x9f2c…a10b", "probe_result_hash": "0x00c4…7f3d", "git_sha": "e4b19c2", "ts": "2026-07-04T00:00:00Z", "conclusive": true }

The stamp IS the signature — the seal’s serial (register) is derived deterministically from the manifest.

Production verification key — fetched live from /.well-known/jwks.json:
kid: crosstalk-auth-1 · crv: Ed25519 · alg: EdDSA
x: OP-H28izPTYZ_fjvylf6klNQbm4nXEbuUJW4uqWsQZk
Demonstration of the verify_isolation() flow

UNCERTIFIED — signature not checked. Press Countersign to run a real WebCrypto Ed25519 verification of the manifest.

Or edit the tid value in the manifest directly, then re-Countersign — the serial voids.

REPRODUCIBILITY — The strength is reproducibility, not our word: run verify_isolation against your OWN two compartments, re-check the signature against our published JWKS, and hand the signed manifest to your auditor.

HONESTY — This control performs a real WebCrypto Ed25519 sign-and-verify over the manifest bytes and fetches the real production JWKS live (real kid/x shown left, imported via crypto.subtle). It is labelled a demonstration of the verify_isolation() flow: the runnable signature is computed with an in-page keypair, not the production private key — so it never implies a signature it did not compute. Where the network is unavailable, the JWKS panel is clearly marked offline.

◲ SHEET 04 / 05
DWG No. CT-002 · REV C
SCALE 1:1 · SEALED_BY: hunta.ai
SHEET 05 OF 07
SHEET 05 OF 07 · BREACH TEST · OPEN SOURCE
Open source · Apache-2.0 · hunta-ai/crosstalk

We ran the breach test on 3 agent-memory systems. Two flooded the same way.

CrossTalk is a mechanism-agnostic, MCP-native benchmark harness where ONE parametrized test file turns RED on the shared store and GREEN on hunta-isolated from the same driver. Hermetic CI — pinned mem0 with infer=False, in-memory Qdrant, one deterministic offline embedder for every backend — so the only variable is isolation architecture. No network, no keys, no LLM.

READ FIRST — these are the benchmark’s METHOD and a reproduction of documented issues, not yet-measured field results. CTRR = Cross-Tenant Recall Rate; 0.0% is the only passing grade.
mem0 · shared user_id (reproduces #3998)
CTRR 100.0%
FLOODED — attest() == None
Reproduction of documented #3998 · synthetic PHI
↤ AIR-GAP ↦
hunta.ai · schema-per-tenant + envelope crypto
CTRR 0.0%
SEALED — signed ✓ Ed25519
Structural isolation · signed attestation
  • test_no_cross_tenant_phi_bleed — write CLINIC_SOP under one tenant, JANE_PREF under another; the PA query must return no ‘Dr. Alvarez’ bleed.
  • test_scope_dump_is_single_tenant — get_all(user_id=GATEWAY_USER) returns BOTH tenants on the shared store; deterministic, ranking-free.
  • test_agent_id_scope_does_not_rescue_mem0 — guards the ‘just use agent_id’ rebuttal (metadata-only, unindexed; ref #3773).
  • test_isolation_is_attestable — mem0 attest() == None ⇒ FAIL; hunta returns a verifiable signed manifest ⇒ PASS. This is the whole wedge.

METHOD — Reported in two separate columns — correct-usage AND the #3998 misconfig — so there is no strawmanning. Membership-inference AUC (0.5 = no leak, 1.0 = full leak) tracks the #5439 entity-merge ranking side-channel. Again: method and reproduction, not yet-measured production results.

FAIRNESS — Fairness is the moat: pre-registered methodology, dual judges (Claude + GPT), published raw transcripts, correct-usage vs misconfig columns, steelmanned incumbents, only synthetic PHI. We invite their PRs. Self-monitoring CI: the mem0 leak case is xfail(strict=True) — if mem0 ever stops leaking, our build turns red and the benchmark is flagged for re-basing.

◲ SHEET 05 / 06
DWG No. CT-002 · REV C
SCALE 1:1 · SEALED_BY: hunta.ai
SHEET 06 OF 07
SHEET 06 OF 07 · CERTIFIED DRAWING vs UNCERTIFIED SKETCH
Head-to-head · hunta.ai vs mem0

A sealed compartment vs a filtered shared store.

Two columns only — the honest head-to-head is against the funded incumbent whose #3998 we reproduce.

Dimension hunta.ai SEALED mem0 FILTERED
Tenant isolation mechanismSchema-per-tenant + role GRANTs + FORCE RLS + per-tenant AES-256-GCMMetadata scope (user_id filter, one shared store)
Tenant identity sourceSigned tid claim in OAuth 2.1 token — no tenant argumentRequest parameter (spoofable)
Structural vs filterStructural — no shared hull to filterFilter
Machine-checkable isolation proofEd25519 signed attestation, re-runnable vs public JWKSNone (attest() == None)
Documented cross-tenant leak0.0% CTRR in CrossTalk#3998 (100% CTRR reproduced), #5439 open
Recall engineForked Graphiti — parity target, no superiority claimOwn retrieval

We claim recall PARITY with the un-isolated fork (|ΔJ| ≤ 1.0 LLM-judge), not recall superiority. mem0’s mechanism is quoted from its own public docs and reproduced against real mem0 in the CrossTalk harness.

◲ SHEET 06 / 07
DWG No. CT-002 · REV C
SCALE 1:1 · SEALED_BY: hunta.ai
SHEET 07 OF 07
SHEET 07 OF 07 · PARTS LIST / LEGEND
Certified specifications

What ships inside every compartment.

SPEC-01

Tenant is a token claim, not a parameter

Identity is a signed tid inside an audience-bound OAuth 2.1 access token — EdDSA verified for sig + aud + iss + exp. alg:none and HS/RS confusion are rejected; a missing or forged token returns 401 with RFC 9728 discovery. There is no WHERE tenant_id to spoof or forget.

SPEC-02

Physically separate, not filtered

Per-tenant Postgres schema, own tables, own HNSW index, own tsvector, own NOLOGIN role. Cross-tenant retrieval cannot even be addressed — it raises at the database, it does not return the wrong rows.

SPEC-03

Encrypted at rest, bound to the tenant

Content is AES-256-GCM ciphertext with the tenant id as AAD, keyed per-tenant. Blob-swap is blocked; a cross-tenant Decrypt returns AccessDenied and lands in the KMS audit log.

SPEC-04

A certificate your auditor can re-stamp

verify_isolation() returns a live, signed, conclusive fault-injection proof. Re-run it against your own two compartments; re-check the signature against our published JWKS. Reproducibility over trust.

SPEC-05

Honest about recall

Recall is a thin fork of Graphiti (Apache-2.0, BM25 + vector + graph + RRF, no query-time LLM). We target parity with the un-isolated fork (|ΔJ| ≤ 1.0 LLM-judge) — we fork recall, we do not claim to have solved it.

SPEC-06

Fails closed

The server refuses to bind without env-provided auth / KEK / attest keys unless CROSSTALK_DEV=1 is set explicitly. Every read and write is logged — know what, who, and when.

◲ SHEET 07 / 08
DWG No. CT-002 · REV C
SCALE 1:1 · SEALED_BY: hunta.ai
SHEET 08
SHEET 08 · BUILD ORDER
Assembly · MCP + curl · mcp.hunta.ai

Connect over MCP. Certify in one call.

01 · DISCOVER
curl https://mcp.hunta.ai/.well-known/oauth-protected-resource
02 · RECALL (tenant = your token’s tid)
curl -H "Authorization: Bearer $TOKEN" \
  -d '{"tool":"recall","query":"after-hours contact"}' \
  https://mcp.hunta.ai/mcp
03 · CERTIFY IT
curl -H "Authorization: Bearer $TOKEN" \
  -d '{"tool":"verify_isolation"}' https://mcp.hunta.ai/mcp
# → { attempted_cross_read:true, results:0, jws:"eyJ…", conclusive:true }
04 · RE-RUN THE BREACH TEST YOURSELF
pip install crosstalk-bench && crosstalk run --your-config
# RED on shared store, GREEN on isolated — same driver

Four MCP tools: remember, recall, verify_isolation, whoami — none takes a tenant argument. Apache-2.0. Live at mcp.hunta.ai. Public verification key at /.well-known/jwks.json (kid crosstalk-auth-1).

◲ SHEET 08 / 09
DWG No. CT-002 · REV C
SCALE 1:1 · SEALED_BY: hunta.ai
SHEET 09
SHEET 09 · CERTIFICATION TIERS
Token-metered · tiktoken cl100k_base

Priced by the tokens your memory processes. Reproducible by you.

Free
$0
/mo
  • 1M store + 250k recall tokens/mo
  • 1 compartment (tenant)
  • verify_isolation attestation included
  • MCP + CrossTalk harness
Get a token
Starter
$19
/mo
  • 10M store + 2.5M recall tokens
  • Overage $2.00/1M store · $0.50/1M recall
  • Email support
  • OTEL export
Start
Attestation included
Pro
$79
/mo
  • 50M store + 15M recall tokens
  • Signed monthly isolation attestation
  • The certificate a filter can’t match
  • Priority support
Go Pro
Scale
$249
/mo
  • 200M store + 60M recall tokens
  • Multi-compartment fleet attestation
  • Audit-log retention
  • SLA
Scale up
Enterprise
Custom
 
  • BYOC / dedicated
  • SOC 2 / HIPAA path
  • 1-yr attestation retention
  • Forward-deployed onboarding
Talk to us

Metering is best-effort and never on the critical path — Lago downtime never delays or fails remember/recall. Counts use tiktoken cl100k_base so you can reproduce your bill; verify_isolation and whoami are unmetered. The embedder is a deterministic hashed bag-of-words, so ‘tokens’ means content tokens processed — a pure, reproducible pricing unit.

◲ SHEET 09 / 10
DWG No. CT-002 · REV C
SCALE 1:1 · SEALED_BY: hunta.ai
SHEET 10
SHEET 10 · CALIBRATION
Stated up front · what the stamp certifies

What the sealed certificate does — and does not — prove.

  • A signed attestation proves ‘we ran THESE probes and got THESE results, and this key policy denies cross-tenant decrypt.’ It is not a formal proof that no path can ever leak.
  • We never market ‘mathematically proven leak-free’ beyond the specific crypto claim.
  • Plaintext lives in application RAM at query time — only a TEE removes that (Phase-2).
  • Embeddings are plaintext for ANN, mitigated by physical per-tenant schema separation.
  • Self-attestation is not a third-party audit. Lead with the runnable verifier — countersign it yourself.
  • Benchmark figures (CTRR, AUC) are the harness’s method and reproduction of documented issues, not yet-measured field results. No real PHI anywhere — every marker is synthetic.
◲ SHEET 10 / 11
DWG No. CT-002 · REV C
SCALE 1:1 · SEALED_BY: hunta.ai
SHEET 11
SHEET 11 · SIGN-OFF

Run the breach test against your own two compartments.

If the flood doesn’t stop at the wall and the countersignature doesn’t check against our JWKS, don’t believe us.