AI Agents in Healthcare: Identity, EHR Scopes and Human Oversight for Agents

Healthcare organisations are moving from AI that drafts text to AI agents that act in the EHR and in payer systems, and most of those agents are being connected with credentials and scopes designed for human users or for batch interfaces. A clinical agent that queues orders, a coding agent that writes charge entries or a prior authorisation agent that submits requests to a payer each needs an identity, an access scope and a defined point where a person decides. This guide covers only that narrow problem for clinical and administrative agents: how to identify agents, how to scope their access to EHR data with SMART on FHIR and backend service patterns, how to record who acted on whose behalf, and how to design human oversight that works on a busy ward. It is for health system identity and security architects, EHR integration teams, clinical safety officers and payer technology leads. The wider clinical AI picture (scribes, PHI in prompts, supplier assurance, device regulation) is in the AI Security in Healthcare Guide, and this page does not repeat it.

Source note: regulatory and specification details are summarised from the official sources listed at the end. Confirm against the official text before relying on it.

Key takeaways

• Every agent gets its own identity. HIPAA's unique user identification specification (45 CFR 164.312(a)(2)(i)) is easiest to meet when each agent is a registered client with its own credentials, never a clinician's login or a shared interface account.
• Scope by patient, resource and action. SMART App Launch 2.2 scopes such as patient/Observation.rs and granular category filters let you give an agent read and search on one patient's lab results rather than the whole chart.
• Record the delegation, not just the call. Audit and FHIR Provenance records should name the agent as the actor and the clinician or service it worked for, so an investigator can tell an agent action from a human one.
• Oversight is a control in the workflow. NHS England guidance requires users to review and approve AI outputs before further action; for agents, enforce that in the EHR or payer platform as an approval step the agent cannot skip.
• Administrative agents carry real authority. Prior authorisation, coding and scheduling agents change money and access to care, and CMS-0057-F's FHIR Prior Authorization API requirements from 1 January 2027 will put more of that work behind APIs agents can call.

Clinical and administrative agent types

The access an agent needs and the harm it can cause depend on whether it acts in a clinician's session, as a standalone backend service, or across organisations. The table groups the agent patterns appearing in 2026 deployments by that access model.

Identity design for healthcare agents

• Register agents as clients, not users: each agent, or each agent role in a multi-agent system, should be a distinct OAuth client in the EHR authorisation server and in the identity provider, with an owner, a clinical sponsor and a documented purpose. Never let an agent run under a clinician's account or a generic interface login: 45 CFR 164.312(a)(2)(i) requires a unique name or number "for identifying and tracking user identity", and an agent hidden inside a person's account defeats that tracking.
• Use asymmetric client authentication: SMART Backend Services requires the client to authenticate with a signed JWT assertion using an asymmetric key rather than a shared secret. Keep the private key in a key vault or HSM, publish only the public key set, and rotate keys on a schedule. See the AI Agent Credential Lifecycle Guide.
• Keep tokens short: the Backend Services specification recommends an access token lifetime of 300 seconds and says it should not exceed that. Apply the same discipline to delegated agent tokens and prefer online_access over offline_access refresh tokens, so the agent's access ends when the clinician's session does.
• Bind the agent to the human it serves: for in-session agents, use the EHR launch so the agent receives the clinician's context and the fhirUser identity, then pass that context through to every downstream call. Where an agent must call a second service for the clinician, use token exchange with a narrower audience rather than forwarding the original token. See the OAuth Token Exchange and Delegation Guide.
• Separate agents from interface engines: HL7 v2 feeds and integration engine accounts often hold broad, long-lived access. An agent should not reuse them. See the HL7 v2 and Clinical Interface Engine Security Guide.

The general model for agent identities is in the Agent Identity and Access Guide; clinical user identity, badge tap and break-glass for people are in the Healthcare Identity Security Guide.

Scoping EHR access with SMART on FHIR

SMART App Launch 2.2 (STU 2.2, on FHIR R4) gives a scope grammar precise enough to express minimum necessary access for agents. Scopes have a context prefix (patient/, user/ or system/), a resource type and permission letters from c, r, u, d and s (create, read, update, delete, search), which must appear in that order. Granular scopes add search parameters after a question mark.

• Avoid wildcards: the specification notes that patient/*.cruds also covers resource types added in future. An agent granted a wildcard today silently gains access to whatever the EHR exposes next year.
• Map v1 scopes deliberately: servers translate .read to .rs and .write to .cud. Review legacy apps being reused as agent back ends so a v1 .write grant does not become create, update and delete on everything.
• Write the minimum necessary rule into the scope: 45 CFR 164.514(d)(2)(i) asks covered entities to identify who needs access and the categories of PHI they need. Record an agent's categories in the same register used for workforce roles, and derive its scopes from that record.
• Enforce patient context server-side: the authorisation server and FHIR API must reject a request for a patient outside the launch context, whatever the model asks for. Prompts are not access control. See the SMART on FHIR Security Guide and the AI Agent Authorisation Guide.
• Treat bulk export as privileged: population agents using bulk data should run with time-boxed approval, a named output location and a fixed group of patients, not standing access to the whole population.

Recording who acted for whom

When an agent drafts an order that a clinician signs, two parties contributed. Investigations, clinical safety reviews and HIPAA audit controls (45 CFR 164.312(b)) all need to see both. FHIR already models this: a Provenance resource records the target resource, when the activity was recorded, and one or more agents, each with a who and an optional onBehalfOf, defined as the individual, device or organisation for whom the change was made.

• Log the inputs as well as the action: keep the identifiers of records the agent read alongside what it wrote. When an injected instruction in a scanned letter steers an agent, the input record is the evidence.
• Feed EHR access monitoring: agent identities should flow into the same privacy monitoring that watches workforce access, with their own baselines. See the EHR Access Monitoring and Patient Privacy Guide and the AI Agent Audit Log Schema Template.

Human oversight of agent actions

NHS England's ambient scribing guidance (version 2) states that users must review and approve product outputs before further actions, notes that products can suggest tasks such as scheduling or referrals, and says NHS organisations may still be liable for claims arising from AI use. The EU AI Act, Article 14(4), will require high-risk systems (Annex III obligations apply from 2 December 2027 after the Digital Omnibus, Regulation (EU) 2026/1744) to let overseers understand limitations, stay aware of automation bias, interpret outputs, override them and stop the system safely. For agents those principles become concrete rules about which actions need which approval.

• Design against rubber-stamping: an approval screen that shows only the agent's conclusion invites automation bias. Show the evidence the agent used, highlight changes from the previous state, and sample approved items for second review.
• Give the stop button an owner: clinical safety and the service desk need a documented way to suspend an agent client at the authorisation server within minutes, with clinical downtime steps for the work it was doing. See the AI Agent Kill Switch and Containment Guide and the Clinical Downtime and EHR Downtime Procedures Guide.
• Payer timing pressure: CMS-0057-F sets prior authorisation decision timeframes of 72 hours for expedited and 7 calendar days for standard requests, and requires a specific reason for denials from 1 January 2026. Staff approval queues so oversight is not dropped to meet them.

Approval patterns in general are in the Human-in-the-Loop for AI Agents Guide.

Threats that change agent design

• Indirect prompt injection from the record: referral letters, scanned documents, patient portal messages and payer correspondence are written by people outside the organisation. ATLAS tracks this as AML.T0051.001 (Indirect prompt injection). See the Prompt Injection Guide.
• Excessive agency: OWASP LLM06:2025 describes agents with excessive functionality, permissions or autonomy. A results agent that can also send messages, or a scheduling agent that can edit demographics, is the healthcare form.
• Exfiltration through tools: an agent that can send email or call external APIs can move PHI out (ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation). Allow-list destinations and keep outbound tools off clinical agents unless required.
• Token theft: stolen agent tokens give attackers the agent's access (ATT&CK T1528 Steal Application Access Token). Short token lifetimes and sender-constrained tokens reduce the window.
• Unauthenticated paths: agents find routes humans ignore. In the OpenAI agent Medicare portal incident, archived code suggested a guest endpoint needed no credentials, and an agent reached non-public aggregate health statistics. Remove anonymous access to anything not meant to be public.

Rolling out agents safely

1. Inventory and classify: list every agent and AI feature with write access to EHR, scheduling, coding or payer systems, including vendor-embedded features turned on by upgrades. Classify each by action class from the oversight table.
2. Register identities: create a dedicated client per agent and environment, asymmetric keys, owners and clinical sponsors. Retire any shared interface or clinician credentials the agent used in pilot.
3. Derive scopes from the minimum necessary register: write the categories of PHI the agent needs, translate them into SMART scopes without wildcards, and test that out-of-scope requests fail.
4. Complete clinical safety work: add agent hazards (wrong patient, injected instruction, omitted finding, unapproved submission) to the hazard log and safety case (DCB0160 in England), and run a DPIA.
5. Shadow mode: run the agent producing drafts that are not used, compare with what clinicians or coders did, and measure error types before any output reaches a patient or payer.
6. Pilot with full approval: one service, every action approved, daily review of a sample. Rehearse suspending the client and falling back to manual work.
7. Relax only with evidence: move low-risk administrative actions to rules-based limits only when error rates and override data support it, and record the decision in the safety case.
8. Roll back cleanly: rollback means revoking the client at the authorisation server, cancelling queued submissions and switching staff to the documented manual process. Test it before go-live, not during an incident.

Detection and measurement

• What to log: token issuance per agent client (scopes, patient context, lifetime), FHIR API calls with patient IDs, writes and their Provenance, approval decisions and approvers, denied requests, and changes to client registrations and keys.
• What to alert on: an agent reading patients outside its launch context or usual volume, scope requests beyond registration, writes without a matching approval, new outbound destinations and use of a client from an unexpected network.

Framework mapping

AI-specific threats map to OWASP LLM06:2025 Excessive Agency and MITRE ATLAS AML.T0053 AI Agent Tool Invocation, AML.T0051.001 and AML.T0086.

Common failure patterns

• Agent under a clinician's login: the pilot used a champion clinician's account, and every agent action now looks like that clinician's in the audit trail.
• Interface account reused: the agent was wired to an integration engine account with read access to every patient, because it already existed.
• Wildcard scopes: patient/*.cruds was granted to get the demo working and never narrowed.
• Approval in the prompt only: the agent was told to wait for approval, but the API let it submit; one injected instruction removed the human step.
• Offline refresh tokens: a clinical assistant kept working on a patient after the clinician logged off because it held an offline_access token.

Practitioner checklist

• Inventory every agent with write access to EHR, scheduling, coding or payer systems, including vendor features.
• Give each agent its own client, asymmetric keys, an owner and a clinical sponsor; remove shared or clinician credentials.
• Derive SMART scopes from a minimum necessary register; ban wildcards and review v1 scope mappings.
• Enforce patient context and allowed actions in the authorisation server and FHIR API, not in prompts.
• Cap token lifetimes at five minutes for backend agents and use online_access for in-session agents.
• Record agent and principal in audit and Provenance, with inputs and model version.
• Enforce approval steps in the EHR and payer platforms for drafts, submissions and adverse determinations.
• Add agent hazards to the clinical safety case and rehearse suspending each agent.

Standards and references

• HL7 International: SMART App Launch, Scopes and Launch Context
• HL7 International: SMART App Launch, Backend Services
• HL7 International: FHIR R4 Provenance resource
• eCFR: 45 CFR 164.312 Technical safeguards
• eCFR: 45 CFR 164.514 Other requirements relating to uses and disclosures
• CMS: Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheet
• NHS England: Guidance on the use of AI-enabled ambient scribing products
• EU AI Act: Article 14 Human oversight

Related NHI Mgmt Group resources: AI Security in Healthcare Guide · SMART on FHIR Security Guide · Healthcare Identity Security Guide · Agent Identity and Access Guide · Human-in-the-Loop for AI Agents Guide