HIPAA Evidence Mapping for AI Agents
An AI agent with read access to an EHR and write access to an email API has everything it creates reportable-incident risk. Runtime authorization puts a policy decision between the agent and that disclosure path.
Last updated: May 20, 2026
HIPAA and AI agents
The Health Insurance Portability and Accountability Act (HIPAA) requires covered entities and their business associates to implement administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of protected health information (PHI). When an AI agent accesses, processes, transmits, or stores PHI, each governed tool call that touches patient data should be governed against the HIPAA Security Rule (45 CFR Part 164, Subpart C) and Privacy Rule (45 CFR Part 164, Subpart E). An unauthorized disclosure by an AI agent is a breach - the same as if a human employee emailed patient records to the wrong person.
Why AI agents are a HIPAA risk
Healthcare organizations are deploying AI agents for clinical documentation, patient communication, claims processing, prior authorization, and administrative tasks. Each of these workflows involves PHI. The risk is not that agents will deliberately violate HIPAA - it is that their non-deterministic behavior creates unpredictable data flows.
PHI in agent outputs
An agent summarizing patient records might include PHI in a response sent to an unauthorized system. Without output redaction, patient names, diagnoses, and treatment details can leak through API calls, logs, or generated documents.
Excessive EHR access
An agent with broad EHR access might query records beyond the minimum necessary for its task. HIPAA's minimum necessary standard (45 CFR 164.502(b)) requires limiting PHI access to what is needed for the specific function.
Cross-system data flows
Agents that integrate multiple systems (EHR, billing, communication) can move PHI between systems in ways that were not anticipated during the privacy impact assessment. Each data flow requires authorization.
Prompt injection and PHI
A prompt injection attack could cause an agent to exfiltrate PHI by embedding it in outbound API calls. Without tool-call authorization, the agent follows the injected instruction and creates a reportable breach.
HIPAA rule mapping
The HIPAA Security Rule specifies technical safeguards in 45 CFR 164.312 and administrative requirements in 45 CFR 164.530. Each applies to AI agents and how Veto's runtime authorization maps to the requirement.
Access control
Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights.
Veto implementation
- Per-agent access policies: Each agent has a YAML policy defining exactly which EHR endpoints, patient record fields, and operations it can access. Access denied by default.
- Minimum necessary enforcement: Policies restrict queries to specific record types, date ranges, and patient contexts. An agent processing a billing claim only accesses billing-relevant fields.
- Unique agent identification: 164.312(a)(2)(i) requires unique user identification. Each agent has a unique API key and identity, enabling per-agent access tracking.
- Automatic logoff equivalent: 164.312(a)(2)(iii) requires automatic logoff. Agent authorization is evaluated per tool call, so no long-lived agent session is required for the authorization decision.
Audit controls
Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.
Veto implementation
- Decision records: Each governed tool call can produce a record with agent identity, tool name, redacted arguments, matched policy, outcome, and timestamp.
- Decision records: Decision records can be exported with signatures so changes are detectable during review when verification is enabled.
- Configurable retention: Record-retention policies can align with the six-year HIPAA documentation period when records serve as compliance evidence (45 CFR 164.316(b)(2)(i), 164.530(j)).
Integrity controls
Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.
Veto implementation
- Write operation controls: Policies can allow read-only access to PHI while blocking all write, update, and delete operations. An agent can query records but cannot modify them.
- Argument validation: When write access is permitted, policies validate the specific fields and values being written. Prevent agents from modifying diagnosis codes, medication lists, or other critical fields.
- Human approval for modifications: Sensitive record modifications can be routed to human approval before execution, ensuring clinical oversight of AI-initiated changes.
Person or entity authentication
Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.
Veto implementation
- API key authentication: Each agent authenticates with a unique API key scoped to a specific project and organization. Identity is verified on every request.
- Agent identity in authorization: Authorization policies are evaluated per-agent. The same tool call may be allowed for a clinical documentation agent but denied for a billing agent.
Transmission security
Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.
Veto implementation
- Output redaction: Before any outbound tool call, the authorization boundary can strip PHI from arguments. An agent can carry conversation context while the governed outbound API call contains only the fields policy allows.
- Destination whitelisting: Policies restrict which external systems the agent can transmit data to. Policies can restrict PHI-bearing calls to authorized endpoints and block unapproved third-party destinations on the governed path.
- In-process evaluation: The Veto SDK can run local policy evaluation so PHI does not need to leave your infrastructure for local authorization decisions.
Documentation and retention
A covered entity must maintain the policies and procedures required by HIPAA in written or electronic form, and retain documentation for six years from the date of creation or the date when it was last in effect.
Veto implementation
- Policy-as-code: YAML policies stored in version control serve as the written documentation of access controls. Every version is retained in git history indefinitely.
- Decision record retention: Authorization decision records are retained per your configured retention policy. Use the six-year HIPAA documentation baseline when logs serve as compliance evidence, then extend for state record-retention rules or internal policy.
- Change documentation: Git commit history documents every policy change with author, date, and reason, giving reviewers a durable change record.
PHI protection with output redaction
Output redaction is the most critical HIPAA control for AI agents. Even when an agent needs to read PHI to perform its task, the authorization boundary can require PHI to be stripped from any outbound action.
How output redaction works
Business Associate Agreements
Under HIPAA, any entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate and must execute a BAA (45 CFR 164.502(e), 164.504(e)).
BAA implications for AI agent authorization
Veto SDK (local mode)
The SDK runs entirely within your infrastructure. PHI does not need to leave your environment for policy evaluation. In local-only mode, Veto does not access, store, or transmit PHI and does not require a BAA.
Hosted Veto (approvals, review path)
If you use cloud features and decision records contain PHI-adjacent metadata (patient encounter IDs, timestamps of PHI access), a BAA may be required. Use Enterprise when you need BAA review and execution. Decision records can be configured to redact all PHI-identifiable fields before transmission to cloud.
LLM provider BAAs
Your BAA with the LLM provider (OpenAI, Anthropic, etc.) covers the model's processing of PHI. Veto's authorization check is independent: it controls what the agent does with PHI, not what the model processes. Both layers are required.
Breach notification and AI agents
Under the HIPAA Breach Notification Rule (45 CFR 164.400-414), unauthorized acquisition, access, use, or disclosure of PHI is presumed to be a breach unless the covered entity demonstrates a low probability that PHI was compromised. An AI agent that exfiltrates PHI via an unauthorized tool call triggers the same notification obligations as every other breach.
Without runtime authorization
Agent exfiltrates PHI. You discover it in application logs days later. The response becomes breach assessment, notification workflow, evidence collection, and customer trust repair.
With runtime authorization
Agent attempts to transmit PHI to unauthorized destination. Tool call is blocked at the authorization boundary. PHI stays inside the authorized perimeter when you run local evaluation. Decision recorded for investigation. No breach occurred. No notification required.
Frequently asked questions
Do AI agents need to be covered under a BAA?
How does Veto enforce the minimum necessary standard?
What happens if an agent attempts to access PHI outside scope?
Does Veto store PHI in its decision records?
How does output redaction detect PHI?
What is the penalty for a HIPAA breach caused by an AI agent?
Related evidence resources
A breach from an AI agent is still a breach. Put the control before the tool runs.