Every healthcare AI agent, accounted for
Get your agent through the hospital security review and live on payer APIs. Delegent gives every agent its own identity and a single-use pass for each call, so payers and hospitals can see which agent acted, for whom, and why.
Built on the standards payers and hospitals already run
- FHIR R4
- SMART BACKEND
- UDAP
- TEFCA
- CMS-0057-F
- HIPAA
The problem, from first principles
Six questions every request for patient data must answer.
Today's agents can't answer one.
Records clerks have asked these since the fax era. AI agents answer with a borrowed login, so the payer's log says the doctor did it.
01 · IDENTITY
Who are you?
- TODAY
- Dr. Lee's login
- DELEGENT
- prior-auth-agent v3.2, with its own key
02 · DELEGATION
Who sent you?
- TODAY
- Unknown
- DELEGENT
- Bayview Ortho, for Dr. A. Lee
03 · SCOPE
What do you want?
- TODAY
- Whatever the login allows
- DELEGENT
- One prior auth, for one patient
04 · PURPOSE
Why?
- TODAY
- Not recorded
- DELEGENT
- Payment, stated on every call
05 · CONSENT
Is this allowed?
- TODAY
- Not checked
- DELEGENT
- Policy checked, and a person approved
06 · ACCOUNTABILITY
What happened?
- TODAY
- “Dr. Lee did it”
- DELEGENT
- A signed record nobody can edit
35%
of healthcare organizations run their AI agents on a clinician's delegated login. Another 16% use generic or shared accounts.
Imprivata survey of 250 US healthcare leaders, run by Vanson Bourne · September 2026 · via HIT ConsultantHow it works
Follow one prior auth through Delegent
Your agent points its FHIR client at Delegent. Here's what happens to a single submission, start to finish.
task = delegent.tasks.create(
agent="prior-auth-agent@3.2",
on_behalf_of="npi:1987654321", # Dr. A. Lee
patient="Patient/8c1e", purpose="payment",
)
fhir = FhirClient(base_url=task.fhir_base("acme-health"))
fhir.operation("Claim/$submit", bundle)Your FHIR client keeps working. You swap the base URL for the one Delegent gives the task.
- 01
Your agent asks
It opens a task: which patient, for which clinician, and why.
YOUR AGENT · PYTHONtask_7Hq2task = delegent.tasks.create( agent="prior-auth-agent@3.2", on_behalf_of="npi:1987654321", # Dr. A. Lee patient="Patient/8c1e", purpose="payment", ) fhir = FhirClient(base_url=task.fhir_base("acme-health")) fhir.operation("Claim/$submit", bundle)Your FHIR client keeps working. You swap the base URL for the one Delegent gives the task.
- 02
Delegent checks permission
The clinic's grant has to cover this agent, this purpose and this patient.
POLICY CHECK · 4 MSdelegation dlg_19a4- AGENTprior-auth-agent v3.2 is registeredAcme Health AI
- CLINIC GRANTBayview Ortho allows prior authsuntil Jun 30
- PATIENT & PURPOSE••8c1e is Dr. Lee's patient, purpose paymentin scope
- ACTIONClaim/$submit needs a person's approvalheld
- 03
A person approves
Submitting is risky, so it waits for a staff member's passkey.
APPROVAL NEEDED · BAYVIEW ORTHO
Submit prior auth to Acme Health Plan?
- Agent
- prior-auth-agent v3.2
- For
- Dr. A. Lee
- Patient
- ••8c1e · MRI, lumbar
The person, not the agent, signs. The approver uses a passkey, so the record proves who said yes.
Staff can approve here or inside the tools they already use. The record shows which.
- 04
A one-call token goes to the payer
It works once, for this call only. Your agent never holds it.
ONE-CALL TOKENUDAP · SMART BACKENDGood for one call. Then it's gone.
- AUDIENCE
- acme-health · Claim/$submit
- ACTING FOR
- Dr. A. Lee, Bayview Ortho
- AGENT
- prior-auth-agent v3.2
- PURPOSE
- payment
Your agent never sees this token
- 05
The record is written
Agent, person, purpose and result, chained so no one can edit it later.
AUDIT RECORD · TASK task_7Hq2hash-chained- 09:41:09Claim/$submit → 202 Accepted · approved by j.ramos · payment#a91f ← #7c02
- 09:41:08Token issued · single use · acme-health#7c02 ← #3e5b
- 09:41:07Approved by j.ramos with passkey#3e5b ← #19d0
- 09:40:58Policy checked · held for approval#19d0 ← #c4a7
Share this task with a hospital reviewer as a linkCopy evidence link →
Security by design
Built for a system that holds everyone's keys
We design for attack, so one breach can't spread from one customer to another.
Keys that never leave
Non-exportable keys, separate for every customer and every agent.
Tokens that last one call
Short-lived and single-use. We never store them.
No patient data at rest
We keep tokenized patient IDs, not clinical payloads.
Tamper-evident audit
Hash-chained records a hospital reviewer can verify.
BAA from day one
We sign BAAs as a subcontractor business associate.
Passkeys for people
Every approver and every staff login uses phishing-resistant sign-in.
Who's building it
“I build and run the sign-in and client-registration platform at a national health plan, the door software uses to get in. Delegent is the passport agents need to get through doors like it.”
FAQ
What engineers and investors ask first
Isn't this just OAuth client credentials?
We use client credentials underneath. But a client credential identifies the vendor's app, not the agent, and says nothing about who the agent acts for or why. Delegent adds the agent's identity, the delegation, the purpose, approvals and the audit trail, and holds the registration at each payer and EHR so you don't have to.
Why not Okta, Entra Agent ID or AWS AgentCore?
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. Delegent is built to sit next to them, using your existing staff sign-in for approvals.
Why won't Epic do this?
Epic will govern agents inside Epic, and it should. It has no reason to issue credentials that work at other EHRs or at payers, and outside agents still reach each Epic site as ordinary SMART apps. Delegent keeps the vendor-side record across all of them.
Do you touch patient data? Do you sign a BAA?
Yes, when your calls pass through Delegent, so we sign BAAs as a subcontractor business associate. We keep as little as possible: tokenized patient IDs, and no clinical payloads stored.
What if payer APIs launch late?
The hospital security review and EHR access don't depend on payer APIs, so that part doesn't wait on payers. Where a payer is late, your agent can keep using the X12 clearinghouse route it has today until the API is live.
How is this different from a clearinghouse?
A clearinghouse translates and routes transactions. Delegent doesn't touch payload formats. It supplies identity, authority, purpose and audit for whoever is calling, over any route, and it's designed to sit next to the clearinghouse you already use for X12.