Scoping LangGraph Agent Tools to HIPAA Minimum Necessary at Runtime

Why minimum necessary is a runtime problem for agents

Under 45 CFR 164.502(b), a covered entity or business associate must make reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose of a use, disclosure or request. Section 164.514(d) adds implementation specifications. Routine and recurring disclosures and requests need policies and procedures, which may be standard protocols, that limit the PHI involved. Non-routine ones need reasonable criteria and individual review. Using or disclosing an entire medical record requires a specific justification, and policy must say so explicitly. These provisions are current as of November 2026.

A LangGraph agent with tool nodes in front of EHR, claims, scheduling or document systems makes several decisions at runtime. The model chooses a tool, builds its arguments and handles whatever comes back. A prompt that says "retrieve only what you need" is an instruction the model may or may not follow, not a control. A design-time tool list tells you which tools exist, not which fields a particular call may request or return.

Not every agent task is subject to the standard in the same way. HHS lists circumstances where minimum necessary is not imposed, including disclosures to a provider for treatment, disclosures to the individual, and uses or disclosures under an authorization or required by law. Have counsel confirm which tasks fall under an exception, and represent those exceptions explicitly in policy so you avoid both over-blocking and over-permitting.

Where enforcement belongs in the execution path

Because the standard covers requests, uses and disclosures, there are three places to apply control. The first is the tool input, where the tool name and arguments express what the agent is asking for. The second is the tool output, where returned data is about to enter graph state and become visible to later nodes and the model. The third is any onward destination, such as another tool, a message to a user or a call to an external system.

Enforcement should sit outside the model and outside the node logic it is meant to constrain. Implement the hook using the tool-execution and pause mechanisms of your graph runtime, and have it call a policy decision point that is separate from application code. Keeping policy as a versioned artifact has practical benefits. Security and compliance teams can review and change field allowlists without redeploying the graph. The same rules apply to every node that reaches a given system. Reviewers can also read the rules without reading Python.

Trussed enforces policy in the execution path on individual tool calls, with allow, redact, block and escalate-for-approval decisions made at runtime, not reviewed after the fact. Its scope is the individual interaction or tool call, which is the unit minimum necessary decisions are made on.

Attributes a defensible decision needs

A decision is only as good as the context it is made on. A tool name alone cannot distinguish a scheduling lookup from a full chart pull against the same system. At minimum, the policy engine should receive the following attributes with every call. Several of them must come from the platform rather than from the model, because a model can misstate its own purpose.

• Agent role: The role bound to the node or deployment, such as scheduling coordinator or claims reviewer, assigned by configuration and not by the prompt.
• Stated purpose: The task purpose declared for the graph or node, used to select the standard protocol that applies.
• Patient or encounter context: The patient or encounter the task is scoped to, so a call cannot quietly widen to other records.
• Requested fields: The specific data elements or record sections in the request, including whether the call asks for the whole record.
• Destination: Where the data goes next, including another covered entity, a user or an external service.
• Routine or non-routine: Whether the call matches a standard protocol or needs criteria-based individual review.

Mapping nodes and tools to allow, redact, block and escalate

Start by assigning each node a role and a purpose, then write one standard protocol per routine purpose that lists the fields permitted. A scheduling node might be allowed appointment times and contact details but not diagnoses or free-text clinical notes. Calls that match the protocol are allowed. Calls that request extra fields are redacted or blocked, depending on whether the task can still be completed without them.

Treat whole-record retrieval as a distinct case. It should not be a default capability of any tool. Allow it only where policy explicitly names the purpose and records a justification, and route everything else to a block or an escalation. Calls that fit no protocol are non-routine. Send them to human approval, with the approver seeing the purpose, the fields requested and the destination.

Expect tradeoffs. Redaction can degrade task quality if the agent expects fields that are no longer present, so test protocols against real tasks. Escalation adds latency and reviewer workload, so keep the routine set well defined enough that approvals stay rare. Overly narrow rules push teams toward blanket exceptions, which defeat the purpose.

• Allow: The call matches a standard protocol for the role and purpose. Fields and destination are within policy.
• Redact: The call is valid but the request or the returned data includes fields beyond the protocol. Remove them before the data reaches agent state.
• Block: The call has no basis under policy, such as an out-of-scope patient, an unpermitted destination or an unjustified whole-record request.
• Escalate: The call is non-routine or high-risk. Pause it for individual human review against defined criteria.

Evidence to produce for each decision

An auditor will want to know what an agent was permitted to access, what it actually received and who approved exceptions. Support audit controls under 164.312(b) by producing a durable record for every tool-call decision. Useful fields include the timestamp, the graph node and agent role, the declared purpose, the tool called, the fields requested, the decision, the policy version that produced it, any redactions applied and the destination. For escalations, add the approver identity, the time of approval and the stated justification.

Be careful that the evidence store does not become a second copy of PHI. Record field names, identifiers and references to values where possible, and apply retention and access controls to the evidence itself.

Trussed generates audit-ready evidence from enforcement, mapped to HIPAA, and can be self-managed in the customer cloud with configurable retention and data residency. It runs in production with healthcare and pharma organizations. Whatever tooling you use, the test is the same: can you answer, for a given call, what the policy said and what happened?