Identity and Access for AI Systems

Executive Summary

Identity and access management for AI systems is more complex than for traditional applications because AI services operate in three distinct authorization contexts: as a client consuming LLM APIs (API key authentication), as a service exposing AI capabilities to internal applications (OAuth2 / mTLS), and as a data accessor reading PHI from EHRs and data warehouses (SMART on FHIR / enterprise SSO). Each context requires a different authentication mechanism, and the failure to implement any one of them correctly results in either unauthorized data access or service unavailability. This chapter covers the identity and access patterns required for enterprise clinical AI deployments.

Learning Objectives

  • Configure service-to-service authentication for AI platform components using mTLS and API keys
  • Implement SMART on FHIR authorization for AI-powered clinical applications accessing EHR data
  • Design OAuth2 client credential flows for AI services that access data warehouses and internal APIs
  • Apply least-privilege access control to AI service accounts and identify the failure modes of over-broad authorization

Business Problem

A Reference Healthcare Organization's AI platform team must navigate four authorization domains simultaneously: the LLM provider (Anthropic, Azure OpenAI) requires API key management with rotation policies; the EHR (Epic FHIR R4) requires SMART on FHIR authorization with patient-scoped access tokens; the clinical data warehouse requires service account authorization with row-level security policies; and internal AI platform consumers (clinical applications, CDS Hooks) require mTLS or API key authentication to the AI gateway.

Without a coherent identity architecture that spans these domains, teams implement ad-hoc credential management — hardcoded API keys, shared service accounts, persistent credentials without rotation — creating security vulnerabilities that are difficult to audit and impossible to remediate quickly in an incident.

Enterprise Considerations

Credential rotation policy: LLM API keys must be rotated on a schedule. For healthcare deployments, a 90-day rotation policy is a common baseline. AWS Secrets Manager and Azure Key Vault support automatic rotation triggers. The AI platform must handle rotation gracefully: fetching the new key from Secrets Manager on next use, without requiring a service restart.

SMART scope minimization: FHIR access scopes must be the minimum necessary for the specific AI use case. A CDS Hook service that reads patient context does not need system/DocumentReference.write. Quarterly scope audits should review all SMART client registrations and remove excess scopes.

Service account proliferation: Each AI service component (RAG service, CDS Hooks service, async workers, AI gateway) should have its own service account with scopes limited to that component's needs. Shared service accounts make it impossible to attribute access events to a specific component and impossible to revoke a single component's access without affecting others.

Audit logging of AI access: All FHIR access by AI services must be logged in the HIPAA audit log. The audit log entry must include: which AI service accessed the data (service account), which patient resource was accessed, the timestamp, and the clinical use case (CDS Hook, RAG query). This is required for HIPAA breach investigation.

Common Mistakes

1. Hardcoding API keys in application configuration. API keys in config files, environment variables, or code are committed to version control, appear in container images, and cannot be rotated without redeployment. Always retrieve credentials at runtime from a secrets management service.

2. Over-broad FHIR scopes. system/*.read grants the AI service read access to every FHIR resource type for every patient — a significant over-privilege. Specify individual resource types and verify minimum necessity with the privacy officer.

3. No token refresh for SMART tokens. SMART access tokens expire (typically in 1 hour for backend services). An AI service that obtains a token at startup and does not implement refresh will fail after the token expires. Always implement token cache with expiry tracking and automatic refresh.

4. Not logging AI-specific FHIR access in the HIPAA audit log. EHR access logs from Epic or Cerner track user-initiated access. AI service access (which is server-to-server) may not be automatically included in the clinical audit log. The AI platform must emit its own audit log entries for every FHIR access.

Best Practices

  • Store all credentials (LLM API keys, service account secrets) in a secrets management service; never in code or config files
  • Implement 90-day credential rotation for all LLM API keys
  • Use SMART on FHIR JWT assertion (client_credentials + JWT) for EHR access; avoid shared username/password
  • Request minimum-necessary FHIR scopes; audit quarterly and remove excess
  • Assign dedicated service accounts to each AI platform component (never shared)
  • Emit AI-specific FHIR access audit log entries for HIPAA compliance

Key Takeaways

  • AI systems operate in multiple authorization domains simultaneously; each requires a different credential pattern
  • SMART on FHIR client_credentials + JWT assertion is the standard for AI backend service EHR access
  • FHIR scopes must be minimum-necessary; system/*.read is never appropriate for a production AI service
  • All credentials must be stored in secrets management services and rotated on a defined schedule
  • PHI access by AI services must be logged in the HIPAA audit trail with the service account identity and use case

Further Reading