Show HN: Connector-OSS – Memory integrity kernel for AI agents

1 point

3 months ago

I built connector-oss because I kept running into the same problem with multi-agent AI systems: when something goes wrong, you have no cryptographic ground truth of what any agent stored, read, or accessed. Log files are mutable. There's no tamper-proof record.

connector-oss is an in-process Rust kernel that adds memory integrity primitives to existing agent frameworks (LangChain, CrewAI, AutoGen).

How it works:

1. Every memory write is content-addressed with Blake3 — the CID is deterministic, so any modification to stored content produces a different CID and is detected on next read.

2. Every agent operation is logged to an Ed25519-signed Merkle chain. The chain links H(n) = hash(H(n-1) + op_n), so altering any entry breaks every downstream entry. Retroactive tampering is detectable.

3. Namespace isolation is enforced at the Rust kernel level — agents are confined to their namespace in vac-core, not by a Python convention that can be bypassed.

4. An 8-dimension trust score (consistency, accuracy, recency, isolation, integrity, coverage, coherence, provenance) is computed from kernel state — not from LLM self-report.

Crate structure: - vac-core: MemoryKernel, 28 syscalls, RangeWindow, Interference engine - vac-store: ProllyKernelStore (Prolly Tree + Blake3), IndexDbKernelStore - vac-ffi: ~500-line PyO3 thin wrapper - connector-engine: AgentFirewall, DualDispatcher, KnowledgeEngine - connector-server: axum REST + Prometheus metrics

One interesting problem: the Prolly Tree backend is async (tokio) but PyO3 calls are synchronous. We bridge this with block_in_place + handle.block_on(), which requires flavor = "multi_thread" in tokio test configs. Namespace packet keys include a timestamp to avoid CID collisions: ns:{ns}:{ts}:{cid}.

788 tests, 0 failures. <50μs overhead per memory operation. 4-agent pipeline produces 105 audit entries, integrity check passes.

pip install connector-oss Apache 2.0. ```