AI Agents in Hospitals & Pharma: Security Risks and Practical Controls

01Where AI agents touch the patient record

In a typical hospital, agents are deployed to draft clinical documentation, fill prior‑authorization forms, scan research datasets and even generate scripts for laboratory information systems. Each of those tasks writes to an electronic health record or a regulated trial database, meaning the underlying data is PHI that falls under HIPAA, GDPR and GxP expectations.

The agent’s workspace often lives on a shared server where other services run. If the agent can reach beyond its intended folder, it may read or write files belonging to unrelated patients, corrupt audit trails, or leak keys that grant access to downstream APIs.

02A plausible failure: unchecked network egress

Imagine an agent that pulls a public model for language generation, then contacts a third‑party code‑completion service to speed up a research script. Without a network allow‑list, the request traverses the hospital’s internet gateway, exposing a PHI snippet in the URL query string. The external service logs that request, creating an unsecured copy of protected data.

Similarly, a rogue script could attempt to download a ransomware payload. If the host’s firewall is not restricted to known endpoints, the agent can silently fetch the payload, store it in the workspace and later execute it during a routine batch job.

03Control points that turn a risk into a manageable process

Isolate each agent in its own sealed microVM so the kernel, file system and network stack are separate from the host. The microVM only sees a single folder that you explicitly mount as the workspace, eliminating accidental cross‑tenant reads.

Apply a strict allow‑list for outbound connections. Any destination not on the list is refused, which blocks accidental data exfiltration and limits calls to vetted services such as the hospital’s internal FHIR gateway.

Keep API secrets on the host, not inside the sandbox. An egress broker injects the real key when a request is allowed, while the sandbox only holds a placeholder. This prevents a compromised agent from stealing the secret.

Use checkpoint and rewind to capture a full machine snapshot before a risky operation—such as executing a new data‑analysis library. If the operation misbehaves, rewind restores the environment in about 0.7 seconds, preserving the original state.

• Seal each agent in its own microVM (kernel isolation).
• Mount only the designated workspace folder (bind‑mount with explicit read/write flags).
• Enforce outbound allow‑list (no internet by default).
• Store API keys on host; inject via egress broker.
• Checkpoint before risky steps; rewind on failure.

04How kosa8 builds the guardrails

kosa8 provides the sealed microVM model described above, giving every agent its own kernel and a single visible folder. Network traffic is blocked unless you add an allow rule with kosa8 sandbox create sealed --egress-allow api.anthropic.com. The platform’s egress broker holds real API keys on the host, so the sandbox never sees them, matching the need for secret protection.

A checkpoint can be taken with kosa8 checkpoint sealed --label "before the risky bit" and reversed with kosa8 rewind sealed. Forking (kosa8 fork api -n 8) lets you explore multiple analysis approaches in parallel, keeping only the successful fork, while the original remains untouched. Every action—whether a file write or a network request—is logged to a hash‑chained audit trail that can be verified with kosa8 audit verify.

05Monday‑morning actions for the CISO

Review each AI‑agent deployment and map its intended workspace. Create a sealed sandbox for it with a single bind‑mount, using the kosa8 sandbox create sealed command and specifying the folder path.

Compile an outbound allow‑list that includes only internal FHIR endpoints and the approved model vendor. Add the rule to the sandbox configuration and reject all other destinations.

Before any agent runs a new library or script, take a checkpoint. Label the snapshot so you can trace which version introduced an issue, then test the change in an 8‑fork experiment. If something goes wrong, invoke rewind and verify the audit log.

Schedule a weekly run of kosa8 audit verify across all agent sandboxes. Review the tamper‑evident log for any unexpected human‑marked actions and enforce the two‑person rule for any operation that modifies patient‑record schemas.