.png)
Two log lines describe the same event: a medication list updated in an EHR.
The first reads actor: svc-agent-prod. The second reads actor: Dr. Chen, via delegated authorization, scope patient/MedicationRequest.write.
The write is identical. The clinical outcome is identical. In a healthcare security review, the first one fails and the second one passes, and the difference decides whether an AI agent product gets deployed.
The HIPAA Security Rule's audit controls standard (45 CFR 164.312(b)) requires systems containing electronic PHI to record and examine activity. The operational meaning: for any access or change, a reviewer must be able to establish whose authority was behind it. Related requirements point the same direction. The minimum-necessary principle asks whether each actor's access matches what their role requires, which is only answerable when actors are people with roles, not a bot with blanket permissions.
A service account defeats both. Every agent action, for every user, across every workflow, collapses into one identity. The reviewer cannot distinguish the nurse's chart access from the billing agent's, cannot verify scope against role, and cannot trace an incident to an authorizing person. The system works and the review stalls.
Service accounts are how integrations have always been built, and at prototype stage they are the fastest path: one API key, no per-user consent flow, no token lifecycle. The agent demos beautifully. The problem only surfaces when the first enterprise healthcare customer sends the security questionnaire, and by then the identity model is load-bearing.
The most common deferral is human-in-the-loop: a person approves every write today, so shared credentials feel safe enough. That holds right up until the roadmap does what every agent roadmap does and removes the approval step. The moment agents write without a human gate, the attribution debt comes due, and it comes due at rewrite cost, because per-user credential isolation is architectural, not a feature flag.
Security reviews are not abstract. The same questions appear on nearly every healthcare vendor assessment, and each one is a trap for a service-account architecture.
Can you attribute every data access to an individual user? The service account answers no by construction. Every action, every user, one identity.
Does each identity hold only the minimum access its role requires? A shared credential holds the union of every permission any workflow needs, which is the opposite of minimum. The reviewer does not need to find a misuse; the standing over-grant is itself the finding.
What happens to access when a user leaves? This one ends evaluations. When a clinician departs, their per-user tokens die with their account. A service account outlives everyone; it keeps its access through every offboarding, and nobody's departure checklist mentions it. Orphaned standing access to PHI is a finding in every audit framework that touches healthcare.
Can you produce an audit log for a specific incident? With per-user delegation the log answers who authorized, which agent, which tool, which scope, in one query. With a service account the log answers that the bot did it, which the reviewer already knew.
Teams tend to discover these four questions one enterprise deal too late. The architecture that answers them cleanly has to exist before the questionnaire arrives, because retrofitting per-user identity into a shipped agent is a rewrite, not a patch.
The alternative is delegated authentication: each user authorizes the agent once, and from then on the agent acts with short-lived tokens scoped to exactly what that user approved. In SMART on FHIR flows the fhirUser claim ties the token to the actual clinician or patient. Every tool call carries the full delegation chain: who authorized, which agent, which tool, which scope, what came back.
That chain is the artifact the reviewer wanted all along. An action attributed to Dr. Chen, with the scope she granted and a metadata-only log entry, answers the audit question by construction. This is how Scalekit's SMART on FHIR support runs every EHR tool call: as the authorizing user, never a service account, with credentials in an encrypted per-customer vault and payloads never written to disk.
Passing review is an event; proving control is ongoing. Healthcare customers increasingly require that agent activity stream into their own monitoring: the delegation chain exported to Datadog, Splunk, or whatever SIEM the security team lives in. Two properties make that stream useful rather than dangerous.
First, it has to carry identity. A stream of bot-attributed events gives the security team volume without meaning; a stream of user-attributed, scope-tagged events lets them alert on the patterns that matter, like an agent suddenly acting outside a user's usual resources.
Second, the log itself must not become a PHI store. If audit entries carry request and response payloads, the monitoring pipeline just became another system containing patient data, with all the obligations that follow. Metadata-only logging, who authorized, which agent, which tool, which scope, status, latency, and never the payload, satisfies the audit requirement without expanding the compliance surface. This is how Scalekit logs every EHR tool call, and it is worth demanding from any infrastructure you evaluate.
The HIPAA Security Rule's audit controls standard (45 CFR 164.312(b)) requires mechanisms that record and examine activity in systems containing electronic PHI. In practice, reviewers need to establish which person's authority was behind each access or change. A log that attributes every action to one shared bot account cannot answer that question.
Technically a service account works: the API accepts the call and the write lands. What fails is everything built on attribution: approval workflows fire on the wrong actor, the minimum-necessary principle cannot be evaluated for a credential with blanket permissions, and the audit trail shows a bot where a reviewer needs a person.
Delegated per-user authorization. Each user authorizes the agent once, the agent acts with short-lived tokens scoped to what that user approved, and every action carries the delegation chain: who authorized, which agent, which tool, which scope. In SMART on FHIR flows, the identity claim ties the token to the actual clinician or patient.
If your agent touches PHI, the security review will ask who acted, and a service account has no good answer. The cheaper time to adopt per-user delegation is before the audit, not after. If that review is on your calendar, talk to us.
