OAuth and Delegated Authorization for Healthcare Agents

TL;DR

• A healthcare agent never acts alone. It acts for someone. Every tool call carries three identities: the person who authorized it, the agent that's acting, and the tenant (health system or practice) whose data it touches. Your auth design has to preserve all three, all the way into the audit log.
• Delegated OAuth is the default; service accounts are the exception. A shared credential can't answer HIPAA's audit and minimum-necessary questions. Use per-user delegated tokens for anything a person would do, and keep system credentials for jobs where no person is acting.
• Least privilege happens at three layers: what the user consents to (scopes), what the agent can see (tool surface), and what each call is allowed to do (call-time checks). Scopes alone aren't enough, because a scope grants a category and the risk sits in a specific call.
• Token lifecycle is where production agents break. Short-lived EHR tokens, refresh rules that differ by vendor, revocation mid-task, and approvals that pause a call for hours all need handling outside the agent's code.
• Scalekit's view: the model should never see a credential, and the agent's code shouldn't manage one. Put token storage, scoping, refresh and audit in a dedicated layer, and let the agent ask for a tool call by user and connection name.

Why authorization is the hard part of healthcare agents

In most SaaS products, "can this agent call this API?" is a yes-or-no question. In healthcare, the reviewer's question is sharper: whose authority was behind this action, and was it the minimum necessary?

Two HIPAA standards drive this:

• Audit controls (45 CFR 164.312(b)): systems holding ePHI must record and examine activity. In practice that means attributing each access to a person.
• Minimum necessary (164.502(b) and 164.514(d)): covered entities and business associates must limit PHI use to what the purpose requires. For an agent, that means each call should carry only the access that user's role allows for that task.

An agent that uses one credential for every user fails both by construction. This is engineering guidance, not legal advice.

The three identities in every agent tool call

• The user is whose authority the agent carries. In SMART on FHIR, the ^fhirUser claim ties the token to the actual Practitioner or Patient.
• The agent is the software acting. Downstream systems and your logs should know which agent it was, not only which user. Delegation tokens can represent this with an actor (^act) claim nested alongside the subject (^sub), as described in our post on on-behalf-of authentication for agents.
• The tenant is the health system or practice. Every EHR customer is a separate server with its own FHIR base URL, and a token must stay bound to the tenant that issued it.

Lose any one of the three and you lose attribution. Lose the tenant and you risk cross-customer data exposure.

Authorization patterns, compared

Epic's sandbox advertises the RFC 8693 token-exchange grant in its SMART configuration. Whether a given health system exposes it to third-party apps is a per-customer question, so don't design around it.

Which pattern for which healthcare system

The pattern that emerges: a single prior-auth agent may need SMART user-context tokens, payer client credentials, a clearinghouse key, a vaulted portal login and a fax API key in one run. Handling that per user, per tenant, is the actual engineering problem.

Least privilege at three layers

Scopes are necessary but not sufficient. A scope like ^{user/DocumentReference.cu} grants the ability to create and update notes. It doesn't say which note, when, or with what content. Least privilege for agents works at three layers.

Layer 1: Consent (what the user grants)

SMART v2 scopes encode the context, resource and permissions in one string: ^{context/ResourceType.permissions}, where permissions are c r u d s.

• ^{patient/MedicationRequest.rs}: read and search one patient's medication requests
• ^{user/Observation.rs?category=...|laboratory}: read lab results the user can access
• ^{user/DocumentReference.cu}: create and update notes as that user
• ^{offline_access}: keep acting after the session ends. Request it only if the workflow truly outlives the session.

Request the narrowest set the workflow needs. Then read the granted scopes back. SMART servers can grant less than you asked for, and certified EHRs must let patients deselect individual resource types.

Layer 2: Tool surface (what the agent can see)

An agent should only see the tools its job requires. A standard MCP server often exposes everything: an inbox summarizer gets ^delete_mail and ^{manage_filters} alongside ^fetch_mails. In healthcare, a chart-prep agent shouldn't see write tools at all.

• Build tool bundles per agent and per role: read-only for chart prep, write-enabled for a note-filing agent, and separate outbound tools for anything that leaves the organization.
• Build the tool list from the user's granted scopes, so the model never plans around a tool that will fail.
• Fewer tools in context also means less for the model to reason over, and a smaller surface for prompt injection to exploit.

Layer 3: Call time (what this specific call may do)

Before each call reaches the upstream system, check:

• Is the token valid, unexpired and bound to this tenant's audience?
• Does the granted scope cover this tool?
• Is this a write that requires approval? If so, has it been approved, and is the credential still valid now?

OAuth answers "can this agent call this category of operation?" It can't answer "should this call, with these arguments, run right now?" That second question needs an approval gate. See our guide on tool calling auth production patterns for how to implement this effectively.

Example: a scope-to-action map for a prior-auth agent

Token lifecycle: where production agents break

Lifetimes differ by system

• The SMART spec recommends access tokens last no more than an hour.
• Oracle Health issues 570-second access tokens, allows refresh at most once a minute, and doesn't rotate the refresh token.
• SMART Backend Services tokens are meant to last five minutes or less, with no refresh token.
• ONC's certified-API criterion requires refresh tokens valid for at least three months for eligible apps.

An agent task that spans days (a prior-auth chase, a denial appeal) will outlive many access tokens. Refresh has to run on each system's schedule, and ^{invalid_grant} has to trigger a clean re-authorization prompt, not a silent failure. See our guide on how to handle token refresh for AI agents for a detailed breakdown.

Revocation can happen mid-task

Certified EHRs must be able to revoke an app's access within one hour. Users leave, roles change, and consent gets withdrawn. The next tool call after revocation must fail closed with a clear error, and the event must be logged.

Approvals pause calls, credentials keep moving

When a write waits for approval, the token that was valid at pause time may be expired or revoked at resume time. The agent should hold a reference (user plus connection), never a raw token, so the auth layer resolves a fresh, valid credential at the moment of execution.

Offline access is a consented scope

In SMART, persistence is something the user explicitly grants via ^{offline_access}. Treat it that way. Don't request it for agents that only need to act while the user is present, and show reviewers which agents hold standing access.

Delegation chains: when agents call agents

Multi-agent systems add hops: a clinician asks an orchestrator, which calls a coding agent, which calls a claims tool. Each hop must carry the original user's authority, not replace it.

• Represent the chain. Delegation tokens can nest actors (^act), so every service knows the original user and each agent in between.
• Narrow at each hop. A downstream agent should receive a subset of the upstream scopes, never more.
• Log the full path. The audit record should show the user, every agent in the chain, the tool and the scope.
• Expire quickly. Short-lived, audience-bound tokens for each hop limit the damage if one is leaked.

Understanding secure token management for AI agents at scale is essential when building these multi-hop delegation chains correctly.

Where MCP fits

If your agent calls tools over MCP, the MCP authorization spec adds rules that align with everything above:

• MCP servers are OAuth resource servers. Clients must send a resource indicator (RFC 8707), and servers must reject tokens not issued for them.
• No token passthrough. An MCP server must not forward the token it received to an upstream API. For an EHR, that means the MCP server holds its own SMART token for the EHR, separate from the MCP client's token.
• Third-party authorization goes through URL elicitation, so the user authorizes the upstream system (the EHR) directly and the credentials never pass through the MCP client.
• For workforce agents, the enterprise-managed authorization extension lets a health system's identity provider grant clinicians access to approved MCP servers through token exchange, without a separate consent screen per server. Scalekit supports this through Cross App Access (XAA), the identity-assertion flow that enterprise-managed authorization is built on.

Anti-patterns we see in healthcare agents

1. One service account for the whole product. Every user's actions collapse into one identity, and the audit trail can't show who did what.
2. Requesting every scope "to be safe." The standing over-grant is itself an audit finding, whether or not it's misused.
3. Tokens in the prompt or the logs. Credentials should be injected at call time and never enter the model context, application code or log lines.
4. Using the same token across tenants. A clinician at two health systems has two tokens, bound to two audiences.
5. Assuming requested scopes were granted. Build tool lists from the granted scope string.
6. Treating approval as UI, not authorization. An approval gate that doesn't re-check the credential at execution time is only cosmetic.
7. Shared payer-portal logins. They defeat attribution and survive every offboarding.

Many of these failures trace back to credential ownership decisions. Understanding who holds the token across agent tool-calling patterns helps teams avoid structural mistakes before they reach production.

How Scalekit implements delegated authorization

Scalekit AgentKit is the authorization and tool-calling layer for agents, with 500+ connectors and 20K+ actions across EHRs, SaaS and healthcare tools.

• Connected accounts per user. Each user authorizes once. Scalekit stores their credential and resolves it at request time. Connected accounts can be created mid-session, when the agent first needs access.
• Ten auth methods, one interface, including SMART on FHIR, OAuth 2.0 and 2.1, API keys, bearer tokens, basic auth, service-to-service OAuth, Google domain-wide delegation and more. The agent calls a tool by user and connection name, whatever sits underneath.
• Scoped tool bundles. Virtual MCP Servers give each agent or role its own tool surface. Your application passes the user's role; Scalekit returns the matching configuration.
• Scope checks before the call. Requests outside the user's granted scopes never reach the upstream system.
• Enterprise-managed authorization. With Cross App Access (XAA), a health system's identity provider can grant clinicians access to approved agents and MCP servers centrally, so IT controls access and revocation in one place.
• Lifecycle handled. Automatic refresh before expiry, and revocation that fails the next call closed.
• Credentials never touch the model. Tokens are AES-256 encrypted per customer, with bring-your-own-key support, and are never placed in prompts, logs or LLM context.
• Metadata-only audit. Who authorized, which agent, which tool, which scope, status and latency, streamed to your SIEM.

For teams building multi-tenant healthcare AI, access control for multi-tenant AI agents covers how to structure tenant isolation at the authorization layer.

Checklist: delegated authorization for a healthcare agent

• Every interactive tool call runs as the authorizing user
• System credentials used only for no-user jobs, isolated from the interactive agent
• Scopes requested per workflow, not per product
• Tool lists built from granted scopes
• Separate tool bundles per agent and role; write tools only where needed
• Approval gates on writes and outbound submissions, with credential re-validation on resume
• Tokens bound to tenant and audience; never reused across tenants
• Refresh handled per system; ^{invalid_grant} triggers re-authorization
• Revocation fails the next call closed and is logged
• No credentials in prompts, code or logs
• Audit log records user, agent chain, tenant, tool, scope, decision and outcome

Frequently asked questions

What is delegated authorization for agents?

Delegated authorization lets an AI agent act on behalf of a specific user with that user's scoped, short-lived permissions, instead of a shared credential. The user authorizes once, the agent's actions are limited to what they approved, and every action is attributed to them in audit logs. In healthcare, SMART on FHIR user-context authorization is the EHR version.

Should healthcare agents use service accounts?

Only for jobs where no person is acting, such as bulk data export or scheduled analytics. For actions a clinician or staff member would take, a service account can't show who performed each action or whether access matched their role, which is what HIPAA audit and minimum-necessary reviews ask.

What are SMART on FHIR scopes?

SMART on FHIR scopes are OAuth scopes for clinical data in the format ^{context/ResourceType.permissions}, for example ^{patient/MedicationRequest.rs} (read and search one patient's medications) or ^{user/DocumentReference.cu} (create and update notes as the user). Version 2 added granular permissions and category filters.

How do you implement least privilege for AI agents?

At three layers. Request only the scopes the workflow needs. Expose only the tools the agent's job requires, built from the scopes actually granted. Check every call before it reaches the upstream system, and gate high-impact writes behind approval with credential re-validation at execution time.

What is on-behalf-of authentication?

On-behalf-of authentication represents both the user and the acting agent in the token, often with a subject claim for the user and an actor claim for the agent. Each downstream service can then enforce the user's permissions and log the full delegation chain. OAuth token exchange (RFC 8693) is the standard mechanism.

How should AI agents handle token refresh?

Outside the agent's code. A dedicated auth layer should refresh tokens before expiry on each provider's schedule, keep refresh tokens encrypted, and trigger a re-authorization prompt when refresh fails. The agent should hold a reference to the user's connection, never the raw token.

Does HIPAA require OAuth?

No. HIPAA doesn't mandate a specific protocol. It requires audit controls, access controls and minimum-necessary use of PHI. Delegated OAuth is the most practical way for AI agents to meet those requirements, because it ties every action to an individual user with scoped permissions.