A healthcare company should treat a patient's personal AI agent as a new channel for an existing patient: answer general, non-PHI questions for any agent, and disclose protected health information (PHI) or take actions only after the patient has been verified the same way you would verify them on the phone, scoped to the task and logged. That is the short answer. The longer answer is eight decisions your support, privacy and security leads need to make together, because HIPAA was written for people, apps and business associates, and a patient's agent sits awkwardly between all three.
Personal agents are already doing the work patients used to do themselves. They research, compare, book, cancel and call. When one of them contacts your front desk, your pharmacy line or your billing team, it is usually acting for a real patient who wanted a task done. This is the business to agent (B2A) problem in its most regulated form: block the agent and you block the patient; serve it carelessly and you have a disclosure problem.
Not legal advice: HIPAA obligations depend on your role and facts, so confirm every decision below with your privacy officer or counsel. Every HIPAA rule named in this article links to the HHS page it comes from. Where HHS has not said anything about AI agents specifically, we say so.
Key Takeaways
Split general from PHI. Anything you would publish on your website can go to any agent. Anything tied to a specific patient waits for verification.
Verify the patient, not the agent. HIPAA's verification requirement is about the identity and authority of the person requesting PHI. Use the same step-up you use for a phone caller, and decide what counts when an agent can read the patient's inbox.
Scope by task. Minimum necessary may not technically apply to disclosures to the patient, but scoping what an agent sees to the job in hand is still the safest design.
Customer's authority and no more. An agent should be able to do what the verified patient could do in your portal, and nothing a clinician or a human reviewer should do.
Log it like any other channel. Security Rule audit controls apply to systems holding ePHI, whoever is on the other end of the conversation.
Rate-limit, don't ban. Agents poll. Give them limits and a check-back time instead of treating a patient's helper as an attacker.
Why personal AI agents are a HIPAA question now
Consumer agents have moved from answering questions to acting. Products like Instinct, Meta's Muse, Grok's bot and Town, plus general assistants such as ChatGPT, Claude and Perplexity, now carry out tasks for their users. Our own research into this shift, published in Personal agents are coming. No one is ready, found agents switching insurance policies, cancelling subscriptions, placing phone calls and arguing with a phone company over a bill. One agent that could not sign in with a saved password used the one-time-code path instead, reading the code from the user's Gmail.
None of that is healthcare-specific, which is the point. The same agent that renegotiated a cable bill will be asked to reschedule a dermatology appointment, chase a prior authorization, check whether a refill is ready or dispute a lab bill. It will use whatever channel works: web chat, email, the phone line or a form. And it will not announce itself unless you give it a reason to.
HIPAA itself does not mention personal AI agents. The HHS summary of the Privacy Rule covers covered entities, business associates, individuals and their personal representatives. Separately, HHS has published guidance on apps that patients direct their records to, and its business associate guidance lists a "third-party vendor Artificial Intelligence (AI) chatbot on a provider's patient portal" as an example of a business associate. That is an AI tool acting for the provider, not for the patient. For an agent acting for the patient, you are reasoning by analogy, which is exactly why these decisions belong to a named owner rather than to whoever answers the ticket.
If you are still deciding whether to engage agents at all, start with blocking vs serving AI agents. This article assumes you have decided to serve them and want to do it safely.
The 8 decisions
1. What an unverified agent may be told
The decision: where the line sits between general information and PHI when you do not yet know who the agent is acting for.
Most agent contacts start anonymous. An agent asks whether you take a particular insurance plan, what a new-patient visit costs, whether you offer telehealth in a given state, or how to request records. None of that is about an individual, so none of it is PHI. Answer it quickly and accurately. A slow or evasive answer does not protect anyone; it just sends the agent to a stale third-party listing that answers for you.
The risk sits in questions that look general but confirm something about a person. "Is Jane Smith a patient of Dr. Lee?" "Is there an appointment under this phone number on Thursday?" "Has the prescription for this date of birth been filled?" Each of those confirms a relationship with your practice, which is information about an individual. Your default for an unverified agent should be the same as for an unverified caller: general policy answers only, no confirmation that any named person is or is not a patient, and a clear path to verification.
A sensible default:
Publish the facts agents need (services, locations, hours, accepted plans, self-pay prices, how to request records) in one place, and serve them to any agent.
Refuse, politely and consistently, anything that names or implies a specific patient until the patient is verified.
Tell the agent what verification involves so it can go back to its user, instead of just saying no.
The agent-ready website checklist covers how to publish those general facts in a form agents can read.
2. How a patient authorizes an agent, and when step-up happens
The decision: what proof you need before an agent gets PHI or triggers an action, and how the patient gives it.
HHS guidance is explicit that the Privacy Rule requires covered entities to verify the identity and authority of a person requesting PHI, if not known to the covered entity (45 CFR 164.514(h)). The same FAQ notes the Rule "generally does not include specific or technical verification requirements", which leaves the method to you. That flexibility cuts both ways: you can design a flow that works for agents, and you own the judgment about whether it is good enough.
There are roughly three models, and most healthcare companies will end up using the first and being careful with the second:
The agent carries the patient's own verification. The agent is a tool the patient is using, like a browser. It passes the same step-up a human would: a one-time code sent to the phone number on file, a portal login, or answers to your standard verification questions. You verify the patient, and the conversation proceeds as if the patient were typing.
The patient pre-registers the agent. The patient, signed in to your portal, grants a named agent access for specific tasks. This is closer to how you would treat a delegated app, and it gives you a record of what the patient agreed to.
Someone with formal authority. HHS explains that a personal representative is a person authorized under State or other applicable law to make health care decisions for the individual, and must be treated as the individual within the scope of that authority. A consumer AI product does not obviously fit that definition, so do not design your flow on the assumption that it does. If a personal representative uses an agent, verify the representative.
One practical trap: agents can often read the patient's email and texts. The one-time-code workaround from our research shows why that matters. A code sent to an inbox the agent controls proves the agent has access to the inbox, which usually means the patient delegated it. Decide in advance whether that is enough for low-risk PHI (appointment times) but not for high-risk PHI (results, diagnoses, behavioral health notes), where you may want the patient to confirm in your own portal or app.
A sensible default: step-up verification before the first piece of PHI in any conversation, re-verification before sensitive categories or account changes, and a verification method at least as strong as your phone line's.
3. Minimum necessary
The decision: how much PHI a verified agent sees for a given task.
The minimum necessary standard (45 CFR 164.502(b) and 164.514(d)) requires covered entities to take reasonable steps to limit uses and disclosures of, and requests for, PHI to the minimum necessary for the purpose. Be precise about its scope. HHS lists situations where the standard does not apply, including "disclosures to the individual who is the subject of the information" and "uses or disclosures made pursuant to an individual's authorization".
So if you treat a verified agent as the patient's own channel, the legal minimum necessary standard may not apply to what you tell it. Your privacy officer should make that call. Either way, scoping by task is the better design, for three reasons:
Agents pass what they learn back to a model and often to a third-party service. HHS's FAQ on patient-designated apps says that once information is received by an app that is neither a covered entity nor a business associate, it is no longer subject to the protections of the HIPAA Rules. HHS wrote that about apps, not AI agents, but the practical effect is similar: what you send may leave HIPAA's protection.
Agents over-ask. An agent booking a follow-up does not need the visit note, and it will not stop to wonder whether it should have it.
Smaller answers are easier to audit and easier to explain to a patient later.
A sensible default: define the data each task needs. Rescheduling needs appointment slots and the provider's name. A refill status check needs medication name and status. A billing question needs the statement and payments. Anything beyond that requires the patient to ask for it explicitly, ideally through your portal's records request flow.
4. Which actions an agent may take, and which need a human
The decision: the list of actions an agent can complete end to end, and the list that always goes to a person.
The simplest rule is the customer's authority and no more. If a verified patient can do something in your portal or by calling the front desk without clinical review, a verified agent acting for them can usually do it too. If it needs a clinician, a pharmacist or a supervisor, it needs one when an agent asks as well.
Task | Suggested default for a verified agent | Why |
|---|---|---|
Book, reschedule or cancel an appointment | Allow, with confirmation sent to the patient's contact on file | Same as self-service scheduling; confirmation catches mistakes |
Refill request for an existing prescription | Allow the request; approval stays with the prescriber or pharmacist | The agent submits, a clinician decides |
Refill status and pickup details | Allow | Low-risk and high-volume; a good fit for agents |
Billing questions, statements, payment plans offered in the portal | Allow | Mirrors what the patient sees in self-service |
Update address, phone or email | Human or re-verified step-up | Contact changes can redirect future verification codes |
Symptom questions, triage, test result interpretation | Human (clinical staff) | Clinical judgment; do not let any automated channel improvise |
Records release to a third party, disputes, complaints | Human | Formal process, often with written requirements |
Anything the patient could not do alone | Refuse and explain | An agent never gets more authority than the patient |
Write the list down and make your concierge enforce it, rather than leaving it to whoever picks up the conversation. For a view of which end-to-end tasks an AI concierge can own in healthcare, see the best AI concierges for end-to-end healthtech support.
5. Logging and audit trail
The decision: what you record about each agent conversation and where it lives.
The HHS summary of the Security Rule lists audit controls among the technical safeguards: regulated entities must implement "hardware, software, and/or procedural mechanisms to record and examine activity in information systems that contain or use ePHI". The same summary lists authentication: "procedures to verify that a person seeking access to ePHI is who they say they are". Neither says anything about agents, and neither needs to. If an agent conversation touches ePHI, it happens in a system those safeguards cover.
Patients also have rights that depend on good records. HHS's personal representatives guidance notes, for example, that covered entities must provide an accounting of disclosures in accordance with 45 CFR 164.528. You do not want to reconstruct what an agent was told from a chat transcript six months later.
What to capture for every agent conversation:
The channel and any identity the agent declared (product name, user agent, calling number).
Whether and how the patient was verified, and when.
What PHI was disclosed, by category.
Every action taken, with the result and the confirmation sent to the patient.
Any hand-off to a human, and why.
The cleanest way to get this is to make agent conversations ordinary tickets in the same system as everything else, not a side log in a separate bot tool nobody reviews.
6. BAAs with any vendor that handles PHI
The decision: which parties in the agent flow need a business associate agreement, and which do not.
There are two different parties here, and HIPAA treats them differently.
Your vendors. HHS defines a business associate as a person or organization that creates, receives, maintains or transmits PHI on behalf of a covered entity, and permits disclosure to it only with satisfactory assurances in a business associate agreement. HHS's own examples include a cloud service provider handling ePHI and, notably, a third-party AI chatbot on a provider's patient portal. If the AI concierge that answers agents on your behalf handles PHI, treat its vendor as a business associate candidate and review the contract with counsel. Our guide to BAAs and HIPAA for AI support walks through the questions to ask any vendor, us included.
The patient's agent. HHS has addressed the closest analogy: apps a patient chooses to receive their records. Its FAQ says that HIPAA does not require a BAA with an app developer that does not create, receive, maintain, or transmit ePHI on behalf of the covered entity, and that an app's facilitation of access at the individual's request "alone does not create a business associate relationship". The same FAQ says a BAA would be required if the app was developed for, or provided by or on behalf of, the covered entity. HHS has not published equivalent guidance naming personal AI agents, so ask your privacy officer whether that app reasoning carries over to your situation. The answer is likely to hinge on who provides the agent and for whom it works.
A sensible default: BAAs with every vendor in your own stack that touches PHI; no assumption that a patient's consumer agent is your business associate; and no promise from you, in any channel, about how the patient's agent will treat what it receives.
7. Rate limits and check-back instead of bans
The decision: how you handle machine-speed traffic that comes from real patients.
Agents behave like software because they are software. They retry, poll and ask the same question in slightly different words. In September 2026, a restaurant booking platform deactivated a user's account after his agent polled it about 200 times an hour; the platform reinstated the account two days later. Healthcare has the same pressure points: same-day appointment slots, refill status, prior authorization status and bill balances all invite polling.
Banning that traffic feels safe and is not. It locks out patients who chose a tool to help them manage their care, and it sends them to your phone line, which costs more and verifies less. The better pattern:
Set request limits per conversation and per patient, and say what they are.
When an answer is not ready (a refill in progress, a slot not yet released), tell the agent when to check back.
De-duplicate retries so one agent does not open five tickets for one refill.
Reserve blocking for traffic that is clearly abusive, such as credential stuffing or scraping patient data, which your security team should handle whatever the source.
The trade-offs are covered in depth in blocking vs serving AI agents.
8. Disclosure and escalation to humans
The decision: what you tell agents about the rules, and when a person takes over.
Agents do better with explicit rules, and so do patients reading the agent's summary afterwards. Tell every agent up front that it is talking to your AI concierge, what it can get without verification, how verification works, what it cannot do on the patient's behalf, and how to reach a human. Plain statements beat silent refusals, because a silent refusal just makes the agent try another channel.
Escalation needs the same care. Decide which topics always go to people: anything clinical, anything urgent, complaints, disputes and any request that falls outside the action list in decision 4. When a conversation escalates, the human should see the full context, including verification status and what has already been disclosed, so the patient is not asked to start again.
Plan for emergencies too. If an agent relays language that suggests a medical emergency or risk of harm, your concierge should respond the way your staff are trained to respond to a caller, including directing the patient to emergency services. Write that behavior down with your clinical lead and test it with agent-style phrasing, not only human phrasing.
Decision table: personal AI agents under HIPAA
# | Decision | Suggested default | Human needed? | HHS reference |
|---|---|---|---|---|
1 | What an unverified agent may be told | General, non-PHI facts only; never confirm a person is a patient | No | |
2 | How a patient authorizes an agent | Verify the patient with your normal step-up before any PHI; re-verify for sensitive data | For edge cases | |
3 | Minimum necessary | Scope PHI to the task, even where the legal standard may not apply | No | |
4 | Which actions an agent may take | Whatever the verified patient can do in self-service, nothing more | Clinical, disputes, records release | Your own policies |
5 | Logging and audit trail | Every agent conversation is a ticket with verification, disclosures and actions recorded | Review | |
6 | BAAs | BAAs with your own PHI-handling vendors; ask counsel about the patient's agent | Counsel | |
7 | Rate limits and check-back | Limits, check-back times and de-duplicated retries instead of bans | No | Operational choice |
8 | Disclosure and escalation | State the rules to every agent; hand off clinical and urgent topics with full context | Yes, by topic | Your own policies |
Decisions 4, 7 and 8 are operational policy rather than HIPAA text. That is deliberate: HIPAA tells you what to protect, not how your support queue should treat an agent that polls every ten minutes.
How to run the decisions in practice
These decisions cross three teams, and in most healthcare companies no single person owns all of them. A workable sequence:
Privacy officer and counsel sign off on decisions 2, 3 and 6: what counts as verification, how much PHI a task needs, and how BAAs apply.
Support and operations own decisions 1, 4 and 8: the general answers, the action list and the escalation rules.
Security owns decisions 5 and 7: logging, retention, limits, and the line between an eager agent and an attack.
Test with real agents. Point a consumer agent at your own chat, email and phone line and ask it to reschedule an appointment for a test patient. Watch what it tries when verification gets in its way.
Review tickets weekly for the first month. Look at what agents asked for, where they got stuck and what they tried next. Adjust the general answers and the action list from that evidence.
If you want a quick read on whether agents are already reaching you, the signs AI agents are contacting your support team list is a good first pass.
How Lorikeet handles this
Lorikeet is an AI customer support platform built for complex, regulated businesses, including healthtech. We launched Lorikeet B2A in September 2026 to give personal agents a sanctioned front door to the same AI concierge that already serves a business's customers on chat, email and voice. It is new, and we are not going to pretend it has years of production data behind it. Here is how it maps to the eight decisions.
One concierge, two ways in. Agents that support WebMCP, a proposed web standard, can call tools registered on your website. Every other agent calls a public endpoint over plain HTTP. On lorikeetcx.ai the notice reads: GET
https://api.lorikeetcx.ai/v1/ask/<public key>?q=.... Responses are plain JSON and include instructions for follow-up questions in the same conversation.General answers by default (decision 1). Endpoint conversations are anonymous by default, so an agent gets what any anonymous visitor would get: answers from your existing knowledge.
Verification uses your existing policies (decision 2). Verifying the patient uses the same identity verification skills and policies the concierge applies on your other channels. There is no separate, weaker path for agents.
Customer's authority and no more (decisions 3 and 4). Agents get the same guardrails, identity checks and action policies as a person, and see only what that customer would see. The workflows that decide which actions are allowed are the ones you already run for humans.
Every conversation is a ticket (decision 5). Agent conversations land in Lorikeet as normal tickets, sorted by topic, so you can review what agents asked, what they were told and what happened.
Built for machine traffic (decision 7). An agent asks, then checks back for the answer. Rate limits cap the volume, and a retry does not open a second ticket.
Rules stated, humans reachable (decision 8). The concierge explains the rules to agents, including request limits and when to check back, and hands off to your team under the same escalation rules as any other conversation.
On decision 6, we will not make claims about BAAs in a blog post. Ask us directly and have your counsel review the contract, the same as you would for any vendor that could touch PHI. The BAA and HIPAA guide lists the questions we would ask in your position.
Setup is four steps: create an account; Coach helps you build and test a concierge for your website; turn on the agent-facing endpoint; and paste the snippet Coach gives you into your website. There is no backend work, because the concierge answers from your existing knowledge. For the wider concept, start with our guide to business to agent (B2A).
Talk to us
If agents are already showing up in your queue, we should talk. We can walk through how the concierge would answer agents for your practice or plan, where verification kicks in, and which actions stay with your staff. Get a demo, or start a free trial and test the public endpoint yourself.
