The case for zero-trust architecture in clinical AI deployments

The traditional security model for a hospital network assumed a hard perimeter: firewall the outside world out, trust everything inside. That model was already showing its age before AI agents entered the picture. An agent that can query multiple internal systems on a clinician's behalf is exactly the kind of component that breaks the "trust everything inside the perimeter" assumption completely.

Why the perimeter model fails for an agent

A perimeter-based network trusts a request because of where it came from — inside the hospital's firewall. An AI agent, by design, makes requests to multiple internal systems in the course of doing its job: the EHR, a scheduling system, a lab results database. If the agent's credentials or the agent itself is compromised, a perimeter model gives it the same broad internal access any other "trusted" internal system would have — which is precisely the scenario that turns a contained problem into a hospital-wide breach.

Zero trust, in practice, means verifying every request

Zero-trust architecture doesn't trust a request because of its network location. It verifies identity and authorization on every single request, regardless of whether it's coming from inside or outside the network. For an agent, this means:

• The agent authenticates as itself (or as the specific user it's acting on behalf of) on every call, not once at session start.
• Each internal system independently checks whether that identity is authorized for that specific action, rather than assuming "it's on our network, so it's fine."
• Access is scoped as narrowly as the task requires — an agent answering a billing question doesn't get the same access as one pulling a full clinical history.

The performance argument against zero trust doesn't hold up anymore

The historical objection to zero trust was latency: checking authorization on every request instead of once per session adds overhead. That overhead is real but small with modern token-based authentication, and it's a trade a hospital should make without much hesitation given what's on the other side of the ledger — a compromised agent with unrestricted internal access versus one whose blast radius is contained by design.

What this looks like for an agent vendor, not just a hospital IT department

Zero trust isn't purely an infrastructure decision the hospital makes independently of the software it runs. An agent vendor building for healthcare needs to design the agent itself to work within this model: short-lived credentials instead of long-lived API keys, scoped tool access instead of one broad service account, and full logging of every request the agent makes, so a compromised credential is contained and immediately visible rather than a silent, unlimited foothold.