A growing class of medical devices now trusts an algorithm to keep patients alive. A cybersecurity researcher has spent two years studying what happens when that algorithm is the part that fails.
At three in the morning, an insulin delivery system makes a decision. A sensor reading comes in slightly low, the algorithm calculates a dose, and the pump acts. The patient is asleep. No nurse is in the room. If the reading was wrong, nothing in the device will say so. There is no error code, no flashing light, no alarm. The machine simply does the wrong thing quietly and keeps going.
This is the failure mode that occupies Abhinav Piratla. "When an artificial pancreas device fails, it doesn't send an error message," he says. "It delivers the wrong insulin dose." He has spent the past two years studying the security of AI-powered medical devices, and his central finding is uncomfortable for an industry that has built its reputation on physical safety. The old engineering playbook, the redundant sensors and fail-safe valves and mechanical backups, assumed the danger was a part breaking. In a device where an algorithm makes the safety decision, the danger is the algorithm being wrong, or being made to be wrong, while every physical component keeps working perfectly.
The distinction matters because the consequences do not undo themselves. A breached database can be restored from backup. "A data breach is recoverable," Piratla says. "A missed hypoglycemic episode at 3am is not." That asymmetry is what separates medical device security from securing enterprise software, and it is the reason he treats the AI model itself as the attack surface rather than the firewall around it.
Most of his work sits in a gap that regulators opened and manufacturers were left to fill. Through 2025, federal guidance raised the bar sharply for AI-enabled device submissions, introducing obligations around adversarial robustness testing, software bills of materials, and lifecycle security management. What the guidance did not supply was the engineering. It described what a secure device should achieve and left every development team to figure out how. Most teams, Piratla argues, lack the mix of skills to bridge that distance, and the gap creates two kinds of risk at once: a patient who can be harmed and a submission that can be rejected before it reaches the market.
His response has been to build the missing translations one at a time. He developed AP-GUARD, an anomaly detection framework that watches a closed-loop insulin system for
the failures that do not trip conventional alarms. A sensor that drifts looks like a slow glucose trend. A frozen sensor looks like stable readings. A communication dropout looks like a quiet stretch. AP-GUARD learns what normal device behavior looks like and flags departures from it, and across more than three hundred thousand data samples it reached a detection score above the threshold researchers consider clinically usable. The model file is roughly ninety-five kilobytes, small enough to run on the pump hardware itself rather than depending on a cloud connection a patient may not have.
Detection was only one front. Piratla co-authored a review that synthesized more than two hundred and fifty studies into one of the most comprehensive maps of artificial pancreas threats, spanning control algorithms, software, hardware, and the wireless links between them. He then built a security framework for AI-enabled continuous glucose monitors that takes the regulatory language head on, mapping twenty-seven specific threats to thirty-eight federal requirements so a manufacturer can move from a rule on paper to a control in code. A fourth piece of work catalogues more than thirty adversarial machine learning attacks aimed at medical device controllers and weighs twenty-five possible defenses against a brutal constraint: the hardware running these models often has as little as a quarter of a megabyte of memory and a hard real-time deadline. Standard defenses assume a data center. These devices are the opposite of a data center.
Two of those papers are published, two are under peer review, and a fifth is extending the same methods to implantable cardiac devices, where a wrong call by the algorithm can mean an arrhythmia rather than a blood-sugar swing. The throughline is that the protection has to be designed in early, not bolted on at the end. Alongside the research he runs the security function for a Connecticut-based educational organization, where he has trained more than a hundred and twenty students, lifted hands-on completion rates from sixty to eighty-five percent, and kept thousands of protected records free of a major incident on a non-profit budget. The point he draws from that work is that rigor does not require a corporate war chest.
He is watching three things move. Regulators are tightening faster than most development teams can adapt, which means rejection rather than delay for products that have not absorbed the new expectations. The adversarial attacks that today live in research papers will, he believes, show up in real incident reports, and the only responsible move is to build the defenses before that happens. And the architecture that solves both privacy and robustness, training models across many clinical sites without pooling patient data, is the one he expects to define the next generation of safe device intelligence.
His advice to the manufacturers he studies is blunt. Do not treat security as a pre-submission checklist. Model the threats from the first design review, build anomaly detection as a parallel safety layer rather than an afterthought, and "test your AI models against adversarial inputs before they are tested by an attacker." The machine at three in the morning is not going to ask for help. Someone has to teach it when to.
This article has been prepared by our editorial team based on the information provided. The final published version may be subject to editorial changes at the discretion of the journalist and publication.