In healthcare, every security decision ultimately comes back to patient safety. That is the lens I apply to any new technology, and it is the reason I have been slow to adopt many of them.
AI agents are the exception. I trust the agents running in my environment more than most tools I have deployed in the last decade, and the reason has nothing to do with the capability of the underlying model. The intent behind the work is mine. I determine what matters, where the agent looks, and what constitutes a finished investigation. The agent executes. It does not set the objective. AI execution is human-driven. Two things make it work, and both have to be true.
What human-driven actually requires
Human-driven does not mean I need to approve every action. An agent that pauses for authorization at each step is a slower version of the analyst I was trying to free, and in an environment where an intrusion can reach clinical operations within minutes, slower is not a neutral tradeoff. Autonomy is not something I tolerate in these systems. It is the reason to run them.
What remains human is narrower than approval and considerably more important. I set the objective. I define the boundaries. I determine what a finished piece of work looks like. Inside those constraints, the agents operate at machine speed, and I do not need to watch them constantly.
My team stays on the loop rather than in it. No analyst is reading raw logs to validate a conclusion, and no one has surrendered judgment either. What makes that safe is not supervision. It is everything that gets decided before the agent starts working.
The first condition: a well-informed instruction
Lior Div published a piece making the case that transparency of reasoning, more than raw capability, decides how quickly a defender comes to trust an agent. Transparency of reasoning is what we should require of the agent. Shared responsibility means something is required of us in return, and our part comes first.
Recently, I gave one of our hunting agents a specific instruction: look for a specific high-level threat actor, their known affiliates, and their TTPs in our environment. The work that came back was thorough and well-reasoned, and it found nothing. In threat hunting, nothing found is the correct outcome far more than practitioners like to admit.
Consider what was already contained in that instruction before the agent began. A judgement that this actor warranted our attention. Knowledge of which sectors they have been targeting, and why a health system should care. A decision to include affiliates rather than a named group alone. An understanding of which behaviors would plausibly surface in our environment if they were present.
None of that came from the agent. It couldn’t have. That was threat intelligence, institutional context, and a working theory of our own risk, in one prompt.
The second condition: an agent built for the job
A well-informed instruction is not sufficient on its own. Hand the same instruction to an agent holding credentials to everything and operating with no defined scope, and what you have built is an efficient path to an expensive mistake. The failure in that scenario is not the model’s reasoning. It is that no one established the boundaries before granting access.
Security leaders already know how to think about this. We segment networks to limit the blast radius of a breach. The same principle applies to agents we deploy: each one should be built for a defined job, with its scope established at design time rather than negotiated while it runs. The agents in my environment handle investigation, detection, response, and threat hunting as separate functions. Each one knows what it is for, what it can reach, and where it stops.
That narrowness is frequently mistaken for a limitation. It is the opposite. An agent scoped to hunt cannot wander into altering a network configuration, because that capability was never inside its harness. Constraint at design time is what makes autonomy at run time something I am willing to grant.
Neither half works alone
The two conditions are not independent. A well-informed instruction handed to an unbounded agent is dangerous. A carefully built agent handed a vague objective is merely useless. What works is both at once: someone who knows precisely what they are asking for, and an agent constructed to do that and little else.
Getting there is why I evaluate the people building these agents as partners rather than vendors. Where the boundaries sit is a design conversation, not a line item on a feature list, and it is not a conversation you can have after deployment.
What the arrangement returns is the work that is worth doing. I spent early years in this field reading logs by hand and correlating events on a whiteboard. That work is ending, and it should. What remains is the theory, the framing, and the judgement about which risks actually threaten the people we are responsible for.
What healthcare leaders have to consider today is how to integrate AI agents in a way that balances the high stakes of healthcare, the speed required to keep pace with attackers, and the trust required to give agents meaningful autonomy.
.jpg)