HIPAA control map
How does an AI agent's memory map to HIPAA 45 CFR 164.312?
Inhold maps access control, audit, integrity and purpose limits to HIPAA safeguards; encryption and transmission controls depend on the AWS install.
Inhold is being built. No customers yet. Repo goes public 9 Nov 2026.
The safeguards, with evidence and status
Inhold supports these safeguards in the following ways. Compliance depends on the covered entity's own configuration and policies.
The map is a draft for your reviewer, not legal advice. Inhold maps what it does to eight lines of 45 CFR 164.312 and to the minimum necessary standard. It does not yet map emergency access, automatic logoff or the (e)(2) specifications.
Status matches the Security gap list. Newer work is in the build log.
| Safeguard | What Inhold does | Evidence file | Status |
|---|---|---|---|
| 164.312(a)(1) Access control | Deny-by-default policy on every read, write and delete, decided on actor, purpose and data label. | policy/active_bundle.json; policy/inhold.rego (a readable mirror of the Python evaluator, kept equal by a CI test) | in v0 |
| 164.312(a)(2)(i) Unique user identification | Every principal is a named agent or person in the bundle. People mapped by OIDC group share one principal, so list a person under oidc_users to get a unique audit identity. | policy/active_bundle.json; audit/audit_events.jsonl (actor_id) | in v0 |
| 164.312(a)(2)(iv) Encryption and decryption | RDS and S3 encrypted with the customer's own KMS key. Requires the AWS install, in build. | DATA_FLOW.md, Keys | designed |
| 164.312(b) Audit controls | One audit row for every policy decision, allowed or denied, including admin actions and exports. | audit/audit_events.jsonl; audit/summary.json | in v0 |
| 164.312(c)(1) Integrity | Audit rows are hash-chained and append-only. The pack includes a verification result. In the demo pack it reads ok: true, with anchors signed by a synthetic demo key. | audit/chain_verification.json | in v0 |
| 164.312(c)(2) Mechanism to authenticate ePHI | Skills are versioned and record the corrections they came from, and corrections carry a diff. Memory bodies have no content hash, so a change made directly in the database is not detected. | audit/audit_events.jsonl (write rows); memory content hashes are absent | gap |
| 164.312(d) Person or entity authentication | People use OIDC with a pinned JWKS and one stable identity claim, oid by default. Agents use an AWS IAM role with a presigned sts:GetCallerIdentity request. The mTLS fallback is not built. OIDC is tested with generated signing keys and IAM sign-in with a stand-in for STS, not yet against a real identity provider or AWS account. Static tokens are laptop-only. On REST and MCP over HTTP they need a flag and are refused in AWS mode; stdio MCP still uses a static token with no flag. | Sign-in tests in the repo; DATA_FLOW.md, Identity, still lists IAM sign-in and MCP over HTTP as unbuilt and describes an unbuilt mTLS fallback. | in v0 |
| 164.312(e)(1) Transmission security | Private subnets, TLS inside the VPC, AWS calls only to STS for agent sign-in and S3 and KMS for anchors, through VPC endpoints, and no calls to Inhold. Requires the AWS install, in build. The statement describes the AWS design; the security group it mentions ships with the install. | deployment/egress_statement.md; DATA_FLOW.md | designed |
| 164.502(b) Minimum necessary | Every call runs under a purpose: named in the REST request, or fixed for the session on MCP. Search leaves out labels outside it and logs the filter it applied; a direct read of such an item is refused and logged. | policy/active_bundle.json; audit/audit_events.jsonl (deny rows) | in v0 |
SOC 2 CC6.1, CC6.6, CC7.2 and CC8.1 are mapped in CONTROL_MAP.md; Inhold has no SOC 2 report.
Not covered by Inhold
What stays your customer's job
BAA with the model provider
Inhold makes no model calls. Which model your agent calls, and under what agreement, is between you and your customer.
Identity provider
People sign in through the customer's OIDC provider. They run it and decide who is in it.
Key policy
The AWS design uses a KMS key the customer creates and owns. Who may use that key is their policy. This depends on the AWS install.
Workforce training
Training the people who use the agent and approve its skills stays with the covered entity.
Questions
Questions about the map
What does HIPAA 164.312 require of an AI agent's memory?
45 CFR 164.312 sets five technical safeguards for systems holding ePHI: access control, audit controls, integrity, person or entity authentication and transmission security. An agent's memory store holding PHI falls under all five.
What audit log does HIPAA expect for an AI agent?
164.312(b) asks for mechanisms that record and examine activity in systems containing ePHI. For an agent, that means a row for every read, write and delete, including refused ones. Inhold writes one row per policy decision and hash-chains the rows.
Does Inhold make an AI agent HIPAA compliant?
No. Inhold supports the 164.312 safeguards for the agent's memory, mapped line by line on this page. Compliance depends on the covered entity's own configuration, policies and agreements.
Which parts of the 164.312 map are not built yet?
Encryption under the customer's KMS key and transmission security ship with the AWS install, which is being built. The (c)(2) check on memory content is a gap, because memory bodies have no content hash. Access control, audit, audit log integrity and sign-in are in v0: people through OIDC, agents through their AWS IAM role. Neither sign-in path has been tried against a real identity provider or AWS account. The map does not yet cover emergency access, automatic logoff or the (e)(2) specifications.