HTI-5 and FHIR API Access by AI Agents: What Platform Teams Must Restrict and Log

What HTI-5 and related rules say, and where they stop

HTI-5, "ONC Deregulatory Actions to Unleash Prosperity," is final as of November 2026. ONC describes it as resetting the Certification Program's regulatory scope and establishing a new foundation for FHIR-based API requirements. That is language about future requirements, not new duties for agent callers. The rule removes or revises several certification criteria, including removal of clinical decision support under 170.315(a)(9) and revision of decision support interventions under 170.315(b)(11). Criterion-level effective dates vary, with some changes on the rule's effective date and others on January 1, 2027 or January 1, 2030. The earlier proposal also referred to AI-enabled interoperability solutions, but that was proposal-stage language.

The operative access text sits elsewhere. Part 170 specifies FHIR Release 4.0.1 and requires authentication and authorization, per the SMART Backend Services authorization guide, when an application is granted access to patient data. The application must be issued a valid access token. Part 170 also says a certified health IT developer must not take action that could interfere with a user's ability to access or use certified capabilities within the certification's scope.

The HIPAA Security Rule applies from the other direction. Section 164.312(a)(1) requires technical policies that allow access to systems holding ePHI only to persons or software programs that have been granted access rights. Section 164.312 also requires audit controls that record and examine activity, and procedures to verify that a person or entity seeking access is the one claimed. None of this text addresses autonomous agents, delegation to an agent, or a tool in between. Everything past this point in the guide is inference from that text.

Which FHIR access patterns carry the most risk when an agent is the caller

An access token records that a client was authorized. It does not record why an agent made a particular request, which tool it used, or what policy applied. That gap is where most of the risk sits.

The highest-risk pattern is a broad shared service credential. Every agent inherits the same reach, and the FHIR server cannot tell agents apart. A close second is a delegated user token handed to an agent, which lets the agent act with the full rights of the person who delegated, including rights the task never needs.

Three further patterns deserve attention. Write operations let a prompt-driven decision change the clinical record. Cross-patient reads and bulk-style access let a single misdirected instruction pull far more data than intended. Responses that flow back into the agent's context can carry PHI the task did not require, and that PHI may then reach a model, a log or another tool. When a tool or MCP server sits between the agent and the FHIR server, the gateway sees only the tool's identity unless the enforcement layer carries the agent and delegation context forward.

A restriction model for agent FHIR access

Define restrictions per agent, not per platform. The following controls are an inference from the access-control standard and the SMART authorization model, and each should be enforced on the individual call rather than assumed from the token alone.

• Per-agent credentials and narrow scopes: Issue each agent its own credential with the narrowest scopes its task needs. Avoid shared service credentials, since the access token is the only authorization artifact the regulatory text names.
• Resource-type allowlist: List the FHIR resource types each agent may touch and deny the rest. Tie each entry to a stated purpose.
• Read versus write: Default-deny writes. Allow them per agent and resource type only where the workflow requires it.
• Patient context binding: Bind each call to a patient context and reject requests outside it, including searches that would return other patients.
• Rate limits and volume caps: Set per-agent limits. Treat bulk-style access as a separate pattern that needs explicit approval.
• Human approval for sensitive actions: Define which actions are sensitive, such as clinical record writes or sensitive resource reads, and route them to a named approver before the call executes.

Enforcement in the execution path versus review after the fact

The central design question is where the decision happens. Reviewing logs later satisfies the review step for activity records, but it cannot stop a write, a cross-patient read or an over-broad response that has already reached the agent. Enforcement in the execution path makes the decision on each call before the request or response reaches the agent, and the evidence is a byproduct of that decision. When you evaluate a design, ask whether a call can be blocked, redacted, rate limited or held for approval before it completes, and whether the record shows the rule that was applied.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls: allow, redact, block, rate limit, escalate for human approval. It produces audit-ready evidence from that enforcement, mapped to HIPAA among other frameworks, and can be self-managed in the customer cloud with configurable retention and data residency. It enforces at the level of the call, which is the unit this guide has used throughout.

Test the evidence as well as the controls. Confirm that records cannot be altered without detection, that they can be exported to show what an agent was allowed to do against what it did, and that changes to an agent's scopes and policies are themselves recorded.

Governance questions and tradeoffs

Subpart C includes access authorization and modification procedures, which suggest documenting each agent's access rights and reviewing them on a schedule. How a covered entity classifies an agent (as a workforce member, a software program or something else) is not settled by the regulatory text and should go to counsel. Counsel should also consider whether a platform team's own restrictions on agent access interact with the Part 170 non-interference language and the Part 171 definition of access.

There are tradeoffs. Narrow scopes and per-agent credentials increase credential management work. Human approval adds latency to sensitive actions, so keep the approval list short and specific. Redaction can remove data an agent needs, so test tasks against the restrictions before rollout. These costs are the price of being able to show, for each call, what the agent was allowed to do and what it did.