Guide · Agent identity
How a healthcare AI agent should sign in to payer and EHR APIs
By Harsh Mehta · Last reviewed:
A healthcare AI agent should sign in as registered software with its own key, never with a clinician's login. Payer and EHR FHIR APIs support this through SMART Backend Services and UDAP. Both identify the vendor's client. Neither identifies the individual agent, and only UDAP can carry the clinician and the purpose, so the agent company has to add those and record them on every call.
Four ways agents sign in today
| How the agent signs in | What the payer's log says | What's missing |
|---|---|---|
| A clinician's portal or EHR login | The doctor did it. | Everything. The log names the wrong actor. |
| A shared service account | The vendor did it. | Which agent, which task, for whom and why. |
| A SMART Backend Services client | The vendor's registered client did it. | The agent, the clinician it acted for and the purpose. |
| A UDAP client with the B2B extension | The client did it, for this organization and person, for this purpose. | The agent itself. |
In a survey of 250 US healthcare leaders (Imprivata, run by Vanson Bourne, September 2026), 35% said their AI agents run on a clinician's delegated login. Another 16% said they use generic or shared accounts.
SMART Backend Services
SMART Backend Services is the HL7 profile for software that calls a FHIR API with no user at the keyboard.
- You register a client with the payer or EHR ahead of time and give it your public key.
- Your software signs a short JWT with the matching private key.
- It trades the JWT for a short-lived access token.
- It calls the API with that token.
The access token says which client called. If one client stands for all of a vendor's agents, every agent looks the same to the payer.
UDAP
The UDAP Security implementation guide (HL7 FAST Security) adds certificates from a trust community and dynamic client registration, so software can register with a signed statement instead of a manual review at every payer.
It also adds the B2B extension, an object the client sends with a client-credentials token request. Its fields include:
organization_idandorganization_name: the organization the request is forsubject_name,subject_idandsubject_role: the person making the request, when there is onepurpose_of_use: why the data is wanted, such as treatment or payment
That is the closest any healthcare standard comes to saying "this software is acting for this person, for this reason." It has no field for the agent. The CMS-0057-F guide covers where UDAP and TEFCA fit with the 2027 payer APIs.
What the standards leave out
Even with UDAP, four things are still up to the agent company.
- The agent's identity. Which agent and which version made the call.
- Proof of delegation. That the clinic actually allowed this agent to act for this clinician.
- Scope for one task. A token good for one patient and one action, not everything the client may do.
- Approval. A person saying yes before a risky action, and a record of who.
A sign-in pattern that holds up
- Register as software at each payer and EHR, with your own keys. Prefer UDAP where it is supported and SMART Backend Services elsewhere.
- Keep private keys in a key management service. The agent never holds them.
- Give each agent and version an identity in your own system.
- Open a task for each piece of work: which agent, for which clinician, which patient and why.
- Check the clinic's grant before anything leaves your system.
- Hold risky actions for a person's approval.
- Mint a short-lived token for one call, and send the organization, person and purpose with it where the payer reads them.
- Write the record. See what an agent audit trail has to show.
For payer and hospital teams
If you run a payer API. Decide whether you register one client per vendor or one per agent, and say so in your developer documentation. Support UDAP's B2B fields and keep them in your audit log. Then a question about one call can be answered with an organization, a person and a purpose, not only a client ID.
If you review vendors at a hospital. Ask which identity the agent uses at each payer and in your EHR. Getting an AI agent through a hospital security review has the full list of questions.
How Delegent handles it
Delegent is being built to hold the registration at each payer and EHR and to add what the standards leave out. Your agent points its FHIR client at Delegent and opens a task: which patient, for which clinician and why. Delegent checks the clinic's grant, holds risky actions for a staff member's passkey, and sends the call on a single-use token built on UDAP and SMART Backend Services. The agent never holds the token.
Delegent is pre-launch and looking for its first design partners. If your agent needs to get onto payer APIs, apply to be a design partner.
Questions
Isn't OAuth client credentials enough for an AI agent?
It is the right base, and both SMART Backend Services and UDAP use it. A client credential identifies the vendor's application. It says nothing about which agent is calling, who the agent acts for or why, so those have to be added and recorded.
What is the difference between SMART Backend Services and UDAP?
SMART Backend Services has you register a client and a public key with each server by hand, then sign a JWT to get a token. UDAP adds certificates from a trust community, dynamic client registration, and an extension that carries the organization, the person and the purpose of use with the token request.
Does CMS-0057-F say how AI agents must authenticate?
No. The rule regulates payers and doesn't mention AI agents. It sets what the payer's APIs look like and when they open, and those APIs expect registered software, not a person's login.
Do Okta, Entra Agent ID or AWS AgentCore solve this?
They manage agents inside one company. They don't speak SMART Backend Services or UDAP, don't hold registrations at payers, and don't carry healthcare purposes like payment or treatment. They can still supply the staff sign-in used for approvals.