Data location
Where does an AI agent's memory live, and who can read it?
With Inhold's planned AWS install, memory lives in your customer's database on their key; v0 runs on one machine with SQLite.
Inhold is being built. No customers yet. Repo goes public 9 Nov 2026.
Data map
Each thing Inhold stores, where it sits, who can read it
Target AWS install. In v0 everything sits in one unencrypted SQLite file on one machine.
| Item | Where it sits | Who can read it | How it is logged |
|---|---|---|---|
| Agent memory and outputs | Customer's database, customer's key | Principals whose purpose allows the item's labels | One row per read, write or delete |
| Corrections | Same database | Any principal with the matching purpose that has the id, agents included; never returned by search. | Write row with the author |
| Skills | Same database, with the corrections they came from | Agents, only after a named approver signs off | Approve row, then a read row each time the skill is listed. |
| Policy bundle | Same database, with an activation log | Roles granted export, through the evidence pack. Changing it needs the policy_change role. | Change row with the new SHA-256 |
| Audit chain | Same database, append-only | Roles granted audit_read in the bundle. | Reads of the log are logged |
| Anything at Inhold the company | Nothing | No one | No telemetry, no licence server, no update check |
The full design goes public with the repo on 9 Nov.
Inside the customer's account
The diagram shows the target AWS install. It is in build. v0 runs on one machine with synthetic hospital data. Inhold has no telemetry, licence server or update check. On a laptop the running service makes no outbound calls. In AWS mode, built in code and not yet run on real AWS, it calls only AWS services in your account, through your VPC endpoints: STS once per agent sign-in, and S3 and KMS (kms:GenerateMac, kms:VerifyMac) to write and check its audit anchors. The install's endpoints for ECR, CloudWatch Logs and Secrets Manager serve the container platform. No call ever goes to Inhold the company. The install checker, inhold doctor, reads AWS APIs when you run it.
Inhold the company has no account and no route into that install. Policy decides which named agents and people may read.
Keys belong to the customer
The AWS design encrypts all storage with a KMS key the customer creates and owns. Revoking the key makes that storage unreadable, including to the vendor. This depends on the AWS install.
Source: DATA_FLOW.md in the evidence pack, Keys.
The agent makes model calls
Inhold makes no model calls. Which model your agent calls, and under what agreement, is between you and your customer; Inhold does not control it. The vendor's agent receives whatever policy lets it read, so reads sent to an agent in the vendor's account leave the customer's account.
Source: DATA_FLOW.md in the evidence pack, Model calls.
The no-egress test
The demo runs with outbound connections blocked
The egress test runs the full demo with socket connect calls patched to refuse non-loopback addresses, while allowing local Unix sockets. It blocks connection creation too. A separate sign-in case expects and blocks an attempted connection to regional AWS STS.
CI runs this test on every change. It checks the demo path on one machine and the attempted STS destination, without contacting a real AWS account. It does not cover every REST or OIDC path. AWS network controls still depend on the install.
The test was inspected for this page, not rerun here.
# tests/test_no_egress.py, trimmed
def _guarded(self, address):
host = address[0] if isinstance(address, tuple) else address
if isinstance(host, str) and (host.startswith("127.") or host in ("localhost", "::1")):
return _real_connect(self, address)
if self.family == socket.AF_UNIX:
return _real_connect(self, address)
raise AssertionError(f"egress attempt to {address!r}")
def test_demo_makes_no_outbound_calls(tmp_path):
from demo import run_demo
run_demo.run(db=str(tmp_path / "demo.db"), out_dir=tmp_path, quiet=True)Questions
Who can read it, whether it is PHI, how to delete it
Where does an AI agent's memory usually live?
Most AI agents keep memory in the vendor's own cloud: a vector database, a Postgres table or a file store the vendor runs. That is the arrangement hospital and law firm reviewers push back on, because the vendor can read it.
Where does an AI agent's memory live with Inhold?
With Inhold's planned AWS install, agent memory lives in a database inside the end customer's cloud account, encrypted with their KMS key. Today v0 keeps everything in one unencrypted SQLite file on one machine; the AWS install is being built.
Is AI agent memory PHI under HIPAA?
Usually yes. If an agent stores a note that identifies a patient and relates to their health or care, and it was created or received for a covered entity, it meets the HIPAA definition of PHI in 45 CFR 160.103. That is our reading, not legal advice.
Can an AI agent store PHI in the customer's own cloud account?
Yes. Storing agent memory in the covered entity's own account keeps it under their controls and their BAA with their cloud provider. Inhold is being built for that layout and labels PHI with local pattern detectors when each item is written. Anything an agent reads still goes to that agent, wherever it runs.
Does my company become a business associate if my agent remembers patient data?
Probably, yes. If your agent creates, receives, keeps or sends PHI on a covered entity's behalf, you are usually a business associate wherever the memory sits. Inhold reduces what you hold; it does not remove the question. Confirm with your counsel.
Who can read the agent's memory?
Through Inhold, only the agents and people named in the customer's policy bundle, and only for the purposes registered to each. Inhold staff have no account and no entry in the bundle. The vendor's agents read only what the bundle grants them, which can include PHI, and every read is logged.
How do I delete an agent's memory of one patient?
In Inhold v0, a delete removes the item from every read and search and writes an audit row, but the row stays in the database marked deleted. Hard delete, including search indexes, is on the gap list and not built yet.