Build or use Inhold
Should we build per-customer audited memory for our AI agent ourselves?
Building it yourself instead of using Inhold is reasonable if your team can own each customer's memory policy, audit evidence and deployment for the life of the install.
Inhold is being built. No customers yet. Repo goes public 9 Nov 2026.
Building it yourself can be the right call
If you already run this infrastructure in each customer's account, or your access rules need a different data model, keeping it in your own code can be simpler.
If your reviewer accepts your existing controls and evidence, keep using them. Inhold is for a team that wants the memory controls and export in a separate component it can install for each customer.
The table shows what a team must build, what Inhold covers today and what it leaves to you. The architecture uses one install per end customer; the local v0 is not the finished AWS install.
| Component | What a team must build per customer | What Inhold covers today | What it does not cover |
|---|---|---|---|
| Store | Place memory and outputs in each customer's account. Maintain versions, purpose boundaries and recovery. | in v0 SQLite store for one-machine v0. | AWS Postgres and the customer install are in build. No shared customer store. |
| Policy engine | Name principals and allowed purposes. Check every operation, including admin paths, and keep the active bundle auditable. | in v0 Deny-by-default Python evaluator and a customer-owned policy bundle. | Your team must write the customer's policy. Inhold does not decide who should have access. |
| Audit chain | Record allowed and refused decisions atomically with data changes. Verify hashes and retain a trusted head outside the database. | in v0 Hash-linked rows and chain checks. Anchors outside the database are written when the store is created, every 100 rows and at each export, and are signed when an anchor key is configured. | Rows after the newest anchor are not covered. Same-host anchors can be rewritten by an admin who can reach them; keep each pack to check the next one. The S3 Object Lock copy is built in code and untested on real AWS. |
| PHI labels | Run local detectors at write time and ensure callers cannot strip labels. Review false negatives for the customer's data. | in v0 Pattern detectors and an optional local name model merge detected and caller labels. | Some names, addresses and free-text dates are missed. No claim of complete PHI detection. |
| Evidence export | Package the customer's policy, decisions, chain check and control evidence. Hash each file and keep the answers current. | in v0 Evidence zip with a manifest of SHA-256 hashes and reviewer answers. | No compliance certificate, outside security review or company SOC 2 report. Your reviewer still decides. |
| Install | Fit each customer's network, keys and identity setup. Own upgrades, backups and operational checks. | designed, in build AWS install kit. | No finished AWS install. IAM-role sign-in and MCP over HTTP are in v0, tested locally; sign-in has not been tried against a real identity provider or AWS account. The mTLS fallback is not built. No general request rate limits, release images, image signing or SBOM yet. |
Questions
Short answers
Should we build per-customer agent memory ourselves?
You can, and some teams do. You need a store in each customer's account, a policy check on every call, an append-only audit chain, local PHI labels and an evidence export. Inhold is being built as that layer, and from 9 Nov 2026 you can read the Apache-2.0 code before deciding.
What does Inhold not do that we would still need?
Inhold does not run your agent, call models, write your BAA or answer questions about your own company's controls. Hard delete, legal matter walls and SIEM export are not built yet.