Architecting HIPAA-compliant AI agents to safeguard health data with AWS

AI agents are transforming healthcare operations. A utilization management team that previously spent hours on prior authorization reviews can hand routine eligibility checks, policy lookups, and documentation gathering to an agent, freeing caseworkers for situations requiring complex clinical judgments. The efficiency gains are real, but so is the risk.

Every one of those workflows touches protected health information (PHI) such as member IDs, diagnoses, claims history, and coverage details. In a traditional web application, PHI flows in controlled paths—a user logs in, queries a database, gets a result—and you can audit who accessed it. With AI agents, the pathways multiply: PHI enters through the prompt, flows through tool calls to backend systems, sits in persistent memory across turns, surfaces in the model’s reasoning, and trails through step-by-step logs.

Your existing Health Insurance Portability and Accountability Act (HIPAA) controls weren’t designed for these pathways. Role-based access control (RBAC) means a caseworker can view eligibility data, but they can’t instruct an agent to reveal coverage status while withholding a patient’s Social Security Number (SSN) or claims history. Encryption protects data at rest, not PHI flowing through the agent’s reasoning in memory. Audit logs capture database queries, not the cascade of model inputs and outputs.

This doesn’t mean agentic AI is incompatible with HIPAA. It means the architecture must be designed differently to protect PHI across these new surfaces. Amazon Web Services (AWS) offers more than 150 HIPAA-eligible services, which include foundational agentic components such as Amazon Bedrock and Amazon Bedrock AgentCore. In this post, we share a reference AWS architecture that healthcare organizations, health plans, and state agencies can use to deploy AI agents while maintaining HIPAA compliance.

A day in the life of an agent

When a caseworker asks an agent to evaluate a lumbar magnetic resonance imaging (MRI) prior authorization, the following happens:

1. Request enters – Member ID, diagnosis, procedure. PHI enters the system.
2. Tool call – The agent calls the eligibility tool, which returns the full member record, including SSN, address, and claims history. More than needed.
3. Policy retrieval – The agent queries a knowledge base. A stray case note uploaded by mistake surfaces unrelated patient data.
4. Model response – The agent summarizes findings, echoing identifiers and returning more PHI than asked for.
5. Memory storage – The agent persists context for the multi-turn conversation. PHI now sits in memory with its own encryption and retention policies.
6. Consequential decision – The agent submits the prior authorization decision. RBAC says it can call the submission tool, not that it should autonomously execute it.
7. Logs – Trace logs capture prompts, tool calls, and responses. PHI scattered across log streams.

The following diagram traces a single lumbar-MRI prior authorization request through an ungoverned agent, showing how PHI spreads at every step when no guardrails are in place.

Figure 1: The prior-authorization request without guardrails: PHI enters and spreads across tool calls, retrieval, model output, memory, an autonomous submission, and logs at each step

Conventional RBAC, encryption, and audit controls don’t prevent these exposures. HIPAA’s minimum necessary requirement applies to agents too, but how do you enforce it?

Four trust zones, 16 capabilities

Our reference architecture organizes security capabilities across four trust zones:

1. Customer application – Interfaces with members and caseworkers, initiating agent interactions where user intent is expressed and explicit authorization gates operate.
2. API boundary – Authenticates users, validates requests, and sanitizes agent input and output. This is the first and last line of defense against PHI reaching the model or leaking to users.
3. Agent platform – Hosts foundation models (FMs) in Amazon Bedrock and the agents, tools, memory, and knowledge bases in Amazon Bedrock AgentCore, where reasoning happens and PHI-bearing data is processed.
4. Observability and audit – Logging, continuous monitoring, anomaly detection, and incident response mean you know what happened, can detect when capabilities fail, and can respond to breaches.

The following reference architecture organizes the solution’s security capabilities across four trust zones—customer application, API boundary, agent platform, and observability and audit—mapping each of the 16 technical and operational controls to where it’s enforced:

Figure 2: Reference architecture mapping 16 capabilities—11 technical (TC) and five operational (OC)—across four trust zones, with TC1 access control spanning the agent platform and TC5 network isolation underpinning the whole system

Together, these zones implement 11 technical capabilities (TC) and five operational capabilities (OC) that satisfy HIPAA’s requirements for access control, encryption, audit, and breach response, as illustrated in the following table:

Authorization and access control – §164.312(a), §164.502(b)

The following capabilities restrict what an agent and its tools can access, down to the individual field and record:

• TC10: Agent authorization policy – Cedar policies on Amazon Bedrock AgentCore Gateway restrict which tools an agent can invoke (PriorAuthAgent can call EligibilityTool, not BillingTool); denials are logged
• TC1: Authorization and access control – Enforced at three levels: tool (which tools the agent can call), field (which fields tools return), and record (each tool verifies user identity before disclosing a member record)
• TC9: Identity-verified data-layer authorization – Each tool validates the propagated JSON Web Token (JWT) before disclosing records rather than inheriting the agent’s authorization
• TC11: Least-privilege data access – Tools return only minimum-necessary fields the caseworker needs—coverage status and network—rather than SSN, address, or claims history
• OC1: Explicit user authorization – The user approves agent actions before execution, logged with timestamp, user ID, and action, which is the documentary evidence §164.508 requires

Input/Output protection – §164.312(e)

Agentic reasoning loops are implemented by sending prompts to a FM and acting on the corresponding responses. Both sides of this interaction represent new surfaces to protect.

• TC2: Input/Output sanitization – A three-layer defense, including AWS Web Application Firewall (AWS WAF) regex, Amazon Comprehend natural language processing (NLP), and Amazon Bedrock Guardrails, on both input and output keeps PHI out of the model and out of responses. Caseworker-facing agents use lighter filters; member-facing agents use strict ones.

Data isolation and retention – §164.312(a)(2)(iv), §164.312(c), §164.502(b)

These capabilities keep PHI isolated to its originating session, out of the shared knowledge base, and off public networks while limiting how long any of it persists.

• TC3: Memory protection – Agent memory is a new PHI surface, which is protected with a customer-managed AWS Key Management Service (AWS KMS) key, per-session namespace isolation, redaction before long-term storage, and 30-day auto-expiry
• TC4: Knowledge base integrity – Amazon Comprehend and Amazon Macie scan every document before ingestion to keep stray PHI out of Retrieval Augmented Generation retrieval
• TC5: Network isolation – All PHI-bearing traffic flows through Amazon Virtual Private Cloud (Amazon VPC) paths (VPC endpoints, AWS PrivateLink); none traverses the public internet

Authentication – §164.312(d)

Because a single authentication event now backs every autonomous action an agent takes on a user’s behalf, that event must meet a higher bar than casual human login.

• TC6: User authentication – Multi-factor authentication (MFA) step. For example, a one-time password sent using a text message is required before an agent accesses PHI, with adaptive step-up for suspicious activity. Without certain user identity and record-level access (TC9), an audit can’t be enforced.

Audit and logging – §164.312(b), §164.312(c)

These capabilities mask PHI before it’s stored, catch what slips through with periodic scanning, and preserve a tamper-proof record that automates breach assessment and accelerates incident response.

• TC7: Log data protection – Amazon CloudWatch Logs data protection policies mask PHI at ingestion using AWS identifiers and custom regex
• TC8: Backstop scanning – Amazon Macie periodically scans immutable log storage for PHI that escaped TC7; findings publish to Amazon EventBridge and AWS Security Hub
• OC3: Immutable audit trail – Logs archive to Amazon Simple Storage Service (Amazon S3) with Amazon S3 Object Lock (compliance mode), a 6-year, write-once-read-many retention that can’t be modified even by root
• OC4: Continuous monitoring – Amazon CloudWatch dashboards track policy denials, input/output blocks, authorization failures, tool-call volume, and human rejections, alerting on anomalies
• OC5: Incident response – AWS Step Functions automation assesses whether an Amazon Macie finding is a breach, identifies affected users, notifies the privacy officer, and documents the response, keeping the 60-day breach notification timeline on track

Governance and approval – §164.312(a)

This capability codifies the principle that consequential actions require an explicit, attributable human decision, not an inference inherited from the agent’s authorization to act.

• OC2: Consequential action approval – High-risk writes (approvals, denials, submissions) pause for human confirmation. Authorization policy determines whether an agent can call a tool; OC2 determines whether it should act autonomously. Approvals log to the immutable trail (OC3).

Once more, with guardrails

In this section, we go over the prior authorization scenario again, this time calling out the capability invoked at each turn. A few controls don’t belong to any single turn: OC1 gates the interaction, TC4 runs preventively at provisioning time, TC8 and OC5 run asynchronously, and TC5 and OC3 run always-on in the background.

Turn 1 – Initial request

A caseworker asks the agent to evaluate a lumbar MRI prior authorization, providing member ID, diagnosis, and procedure. OC1 logs the caseworker’s explicit authorization, and TC6 verifies their identity with MFA and issues a JWT. TC2 then inspects the prompt for injection while applying a caseworker-scoped guardrail that permits only the PHI this caseworker legitimately needs.

The agent calls an eligibility tool, and three controls fire together: TC10’s Cedar policy confirms the agent has permission to call the tool (TC1 ✓), TC11 confirms the tool returns only coverage_status and network, and TC9 validates the propagated JWT to enforce record-level access. The agent reasons over the result and determines it still needs treatment history. Before that response reaches the caseworker, TC2 inspects it for PHI.

Turn 2 – Providing treatment history

The caseworker supplies the treatment history, and TC2 fires again on the input. TC3 encrypts and isolates the event to the caseworker’s namespace, keeping member name, SSN, and full diagnosis out of long-term memory while preserving the operational context. The agent presents its findings—eligibility is confirmed, but policy requires 6 weeks of conservative treatment first, so the MRI doesn’t yet meet criteria—and TC2 inspects the output.

Turn 3 – Proposed action and approval

The agent proposes to submit a DENY decision. OC2 intercepts the write and pauses to surface the decision for explicit caseworker approval before anything executes, closing the judgment gap. RBAC authorizes the caseworker to approve prior authorizations, and OC2 confirms the approval is an explicit human act rather than an inherited inference. The approval is logged.

Throughout the session, TC7 redacts PHI from trace logs before storage, OC3 archives them to immutable Amazon S3 Object Lock storage, and OC4 dashboards track policy denials, guardrail blocks, authorization failures, tool-call volume, and human rejections.

The following diagram revisits the same prior authorization request as a governed three-turn conversation, showing the guardrails that engage at each turn—and the always-on controls running underneath—to keep protected health information (PHI) scoped at every step:

Figure 3: The same request under guardrails—a three-turn conversation where identity, field- and record-level access, memory isolation, and a human-in-the-loop approval keep PHI scoped at every step, backed by always-on network, logging, and monitoring controls

Getting started

Work in three phases:

Phase 1 – Foundational (the load-bearing walls of HIPAA compliance)

Authorization & Access Control (TC1, TC9, TC10, TC11, OC1), Data Isolation (TC3, TC5), and Audit & Logging (TC7, OC3). These block unauthorized access, protect PHI in memory and transit, and create immutable audit trails. Without them, you can’t satisfy §164.312(a) Access Control or §164.312(c) Integrity, so this phase is mandatory before any production workload.

Phase 2 – Edge (before member launch)

Input/Output Protection (TC2), Knowledge Base Integrity (TC4), and Governance & Approval (OC2). These harden against member-facing exposure and make consequential actions explicit human acts rather than inherited inferences.

Phase 3 – Detection (ongoing)

Backstop Scanning (TC8), Continuous Monitoring (OC4), and Incident Response (OC5) to catch missed PHI, surface anomalies, and automate breach assessment. This reference architecture doesn’t create new compliance requirements. It shows how to satisfy your existing HIPAA and Federal Risk and Authorization Management Program (FedRAMP) obligations when you introduce agentic AI. By varying the configuration of role-scoped controls, a single deployment serves both internal caseworker-facing workflows and external member-facing applications.

Conclusion

Health and human services agencies across the country are using the power of AWS to unlock their data, improve citizen experience, and deliver better outcomes. Learn more at Health and Human Services Cloud Resources.

Learn how governments use AWS to innovate for their constituents, design engaging constituent experiences, and more by visiting the AWS Cloud for State and Local Governments hub.