HIPAA Workforce Access Termination for AI Agents and Service Accounts

How the Security Rule applies to non-human actors

The termination specification at 164.308(a)(3)(ii)(C) is addressable and requires procedures for ending ePHI access when a workforce member's employment or other arrangement ends, or when a determination under the workforce clearance procedure at (a)(3)(ii)(B) requires it. The regulation defines workforce as employees, volunteers, trainees and other persons under the direct control of the covered entity or business associate. That definition does not mention AI agents or service accounts.

The technical safeguards are less ambiguous. Section 164.312(a)(1) requires technical policies and procedures that allow access to systems maintaining ePHI only to those persons or software programs that have been granted access rights under 164.308(a)(4). Section 164.312(d) requires procedures to verify that a person or entity seeking access is the one claimed. An agent or service account that reads or writes ePHI is a software program under these provisions, and its access has to be authorized, limited and verifiable.

The practical consequence is a documentation decision. Record whether your organization treats each class of non-human identity as a workforce member for termination purposes or as a software program for access control purposes, and apply the termination procedure to both. This is an interpretation of existing requirements, not new regulation. In January 2025 HHS proposed a one-hour termination deadline and written notification procedures between regulated entities. As of November 2026 the current text of 164.308(a)(3)(ii)(C) remains in the eCFR, so treat the deadline as proposed and not binding. It is still a reasonable internal target.

Inventory and ownership come first

A termination procedure cannot cover identities it does not know about. Build an inventory of service accounts, API tokens, agent credentials and tool or MCP server credentials that can reach ePHI. For each, record the owner, the business purpose, the systems and data it can reach, the credential type and lifetime, and the arrangement it depends on, such as a vendor contract or a project.

The owner field matters most. Termination triggers and accountability both need a named human who answers for the identity. When that person leaves or changes roles, the identity should be reassigned or ended. Shared credentials weaken this model because one secret represents several actors, so separate identities per agent or workload are easier to terminate and easier to attribute in activity records.

Include these identities in the security risk analysis and in the information system activity review required by 164.308(a)(1)(ii)(D), so that post-termination activity is detectable by an existing process.

• Owner: A named person accountable for the identity and its termination.
• Reach: Systems, APIs and data sets the identity can access.
• Credential type: Static secret, OAuth token, delegated token or short-lived credential.
• Dependency: The contract, project or workflow that justifies the access.

Why directory deprovisioning leaves gaps

HHS healthcare cybersecurity guidance describes HR-triggered, SSO-based automated deprovisioning of user accounts and says termination processes should include session termination. That model fits people. Whether it reaches agent-held tokens, cached credentials or tool credentials depends on your architecture, and it should be tested rather than assumed.

The gaps to test are predictable. An agent may hold a delegated token issued on behalf of a user, and that token may remain valid after the user's directory account is disabled. A tool or MCP server credential may sit in a configuration file or secrets store that no HR event touches. A service account may have outlived the project that justified it and have no current owner. HHS itself noted in its proposed rule discussion that inactive accounts that are not fully terminated or disabled could be used to access ePHI.

NIST's October 2026 design tenets for agent identity point in a useful direction, although they are design guidance and not HIPAA requirements. They recommend an identity lifecycle for agents that is distinct from human principals, just-in-time and time-bounded access, ephemeral credentials over long-lived bearer tokens or static secrets, and continuous runtime verification of each tool invocation or API call. Short-lived credentials shrink the window in which a missed revocation matters. Per-call verification catches what revocation missed.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Policy is enforced at runtime, not reviewed after the fact, with outcomes of allow, redact, block, rate limit and escalate for human approval. The scope is individual interactions and tool calls, which is the level at which a post-termination PHI request would occur. An enforcement point in the path can evaluate each call against policy, including whether the calling identity is still authorized, as a second control behind credential revocation.

The enforcement itself generates continuous audit-ready evidence mapped to HIPAA, including 164.312(b) audit controls. Trussed runs in production with healthcare and pharma organizations, and it can be self-managed in the customer's cloud with configurable retention and data residency.

It does not replace the inventory, the ownership records or the revocation steps above. Those remain your procedure. Runtime enforcement makes that procedure testable and gives you a record of what was allowed, redacted, blocked or escalated.