Lack of an adequate Security Rule risk analysis is HHS OCR’s named top enforcement focus for 2026, and the largest category of published enforcement actions by a wide margin. That scope now includes AI agents that create, receive, maintain, or transmit PHI — not just human users and traditional systems. If OCR has opened a review or requested a Corrective Action Plan, the strongest evidence is a verifiable record of what your agents touched and when. VeriSwarm’s Vault produces that record; it does not produce a CAP resolution or a compliance determination — see what this does not do.
45 CFR §164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI an entity holds. HHS OCR’s stated 2026 focus areas, in priority order, are: lack of an adequate security risk analysis, lack of policies and procedures, lack of workforce training, Right of Access fulfillment, and breach reporting. Risk analysis leads that list — and it’s not close. Published 2025 enforcement actions cite Risk Analysis failures by roughly a 3:1 margin over every other HIPAA violation category combined.
The pattern OCR is enforcing against isn’t a paperwork gap. It’s entities that never updated their risk analysis to account for how PHI actually moves through their systems today — including through automated actors that didn’t exist when the original risk analysis was written.
A risk analysis written for a human workforce assumes a known, bounded set of actors touching ePHI. An AI agent breaks that assumption. The same agent can call an LLM provider, invoke a scheduling or billing integration, write to a conversation log, and escalate to a fallback provider on error — four new places PHI can flow that a legacy risk analysis was never built to cover, and four new places an OCR reviewer will ask about if an incident happens.
This is the vector Datavant’s May 2026 healthcare privacy briefing calls out directly: a risk analysis built around human users misses the case where the threat actor is the agent itself, acting on flawed instructions, not an external attacker or malicious insider.
Whether you’re proactively strengthening a risk analysis or responding to an OCR-issued Corrective Action Plan, the ask is the same: prove what happened, when, and under what controls — in a form that can’t have been quietly rewritten after the fact. Vault produces that record for every agent decision, tool call, and PHI tokenization event, chained with a SHA-256 link to its predecessor.
GET /v1/suite/vault/verify
→ {
"ok": true,
"events_verified": 41_902,
"first_event_id": "evt_...",
"last_event_id": "evt_...",
"errors": []
}Alongside the raw chain, a per-framework compliance report packages the same underlying evidence into an attestation format:
GET /v1/compliance/42-cfr-part-2
→ {
"framework": "42-cfr-part-2",
"status": "technical_preview",
"controls": [ /* per-control pass/warn/fail with evidence counts */ ],
"generated_at": "2026-08-05T..."
}A break in the chain, or a control reported as failing, tells you exactly where to look before an auditor does. That’s the difference between reconstructing evidence under deadline pressure and replaying it.
Vault and the compliance reports are an evidence layer, not a legal outcome. They do not constitute a completed risk analysis, a HIPAA compliance certification, or a resolution to an open OCR Corrective Action Plan. Conducting the risk analysis itself — identifying threats, rating likelihood and impact, documenting remediation — remains work your organization has to do, typically with counsel involved once OCR is formally engaged. What VeriSwarm produces is the underlying record that risk analysis and any CAP response can cite: verifiable proof of what agents touched, when, and under what controls, rather than an unverifiable log or a reconstructed spreadsheet.
Vault and Guard are Max-plan capabilities ($299/mo) — not included on VeriSwarm’s free tier, which covers agent trust scoring and event ingestion only.
The HIPAA Security Rule requires covered entities and business associates to "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information" (45 CFR §164.308(a)(1)(ii)(A)). HHS OCR has named lack of an adequate risk analysis its top stated enforcement focus area for 2026, and it's been the single largest category of published enforcement actions — a wide margin over every other HIPAA violation category combined.
Yes, if the agent creates, receives, maintains, or transmits ePHI. A risk analysis scoped only to human users and traditional systems misses an agent's entire attack surface: LLM providers it calls, tool integrations it invokes, logs and conversation memory it writes to, and fallback providers it escalates to on failure. OCR's enforcement pattern doesn't carve out an exception for automated actors — an agent handling PHI is in scope the same way a human workforce member would be.
A Corrective Action Plan (CAP) typically requires the entity to demonstrate a completed risk analysis, remediate identified gaps on a timeline, and — per the 2026 enforcement pattern — accept a 2-year OCR monitoring obligation. The strongest evidence in that process is a verifiable record: what PHI the agent touched, when, and under what controls. An editable log is weak evidence in a CAP review; a hash-chained ledger that provably wasn't altered after the fact is stronger evidence, though it does not replace the risk analysis or remediation work itself.
Vault chains every recorded event — agent decisions, policy evaluations, PHI tokenization and rehydration — with a SHA-256 link to its predecessor. GET /v1/suite/vault/verify walks the chain and returns pass/fail with the exact event where a break occurs, if any. That gives a risk-analysis review (or a CAP response) a machine-verifiable answer to "can you prove this log wasn't edited," instead of an assertion.
No. VeriSwarm's compliance endpoint (GET /v1/compliance/{framework}) generates a per-tenant attestation report against a named framework, with evidence counts drawn from Vault and Guard. It's a structured evidence package, not an OCR determination. Whether that evidence satisfies a specific OCR review or CAP requirement is a legal and factual judgment OCR — or your counsel — makes, not VeriSwarm.
It's a control a risk analysis can cite, not a substitute for doing the analysis. Guard's PII tokenization (POST /v1/suite/guard/pii/tokenize) reduces the actual exposure — PHI never reaches the LLM or tool call untokenized — and every tokenization event is Vault-logged, which is itself evidence a risk analysis can reference. The mechanics of how tokenization works are covered in depth on the HIPAA-compliant AI agents page.
For how PHI tokenization actually works at the agent boundary — the control this evidence trail is built on top of — see HIPAA-Compliant AI Agents: Tokenize PHI Before the Model Sees It. For the full mapping of OCR’s 2026 enforcement priorities to VeriSwarm capability, start at VeriSwarm for Healthcare.
A 30-minute walkthrough, live against your fleet — not demo data. Bring the OCR priority or CAP requirement you’re actually facing.