Romain Sestier · · 8 min read 
Healthcare organizations: the reality of connecting AI agents to business systems
Table of Contents
Healthcare organizations approve AI agents to read and refuse to let them write. The blocker is not model quality. It is that the systems holding clinical, quality and trial data cannot grant one agent a narrow, identity-bound, logged write, so nobody will sign the review. IBM and the Ponemon Institute studied 602 organizations breached between March 2025 and February 2026, and among those that suffered an AI-related breach, 92% lacked proper AI access controls.
Facts in this post were verified on 2 September 2026.
What does it cost when nobody controls the access?
Four findings from IBM’s Cost of a Data Breach Report 2026 are the reason this matters more in healthcare than anywhere else.
92% of organizations that suffered an AI-related breach lacked proper AI access controls. IBM names the controls it means: role-based access and multifactor authentication. Not exotic requirements.
Only 40% of organizations use access controls on AI models and data at all. Four in ten. Identity and access management was one of the most effective cost reducers across every breach in the study, and six in ten organizations have not applied it to the AI layer.
Shadow AI incidents more than doubled to 43% of security incidents, up from 20% last year. Those breaches averaged $5.39 million against $4.63 million the year before, and roughly one in five drew a regulatory fine. Shadow AI is what happens after a security team says no to a governed agent. The work does not stop. It moves somewhere nobody is watching.
Healthcare remains the most expensive industry to be breached, at $6.64 million. Thirteenth consecutive year at the top, and that is after a 10.5% drop from $7.42 million. Attackers keep coming back for patient PII because it converts into identity theft and insurance fraud.
Read those together. The security teams refusing agent write access are right about the risk. They are refusing the wrong thing.
Why does read access get approved and write access refused?
Most healthcare organizations we talk to have already built the agent. What they do not have is anyone willing to let it write.
A read is reversible. If an agent pulls the wrong quality record, the worst case is a bad answer in a chat window. A write commits. It changes a batch record, a deviation, a subject status, a supplier qualification. So the review is different, and it comes down to four questions.
Which system does the write touch. Which fields does it change. Whose identity does the call carry. What does the audit log say afterwards.
The agent is not what fails that review. The integration layer underneath it is. Most integrations authenticate as one service account with tenant-wide reach, because that is how they were built for nightly syncs. Ask to revoke the agent’s access to one object and the answer is that revoking anything breaks the payroll job too. Pull one write out of the log and it reads svc_integration wrote a record, which tells a compliance reviewer nothing.
Same agent, same task, both times. The difference is entirely what the layer underneath can prove.
Which healthcare systems does this block?
Not the CRM. The systems where agent write access would save real hours are the regulated ones, and they are the ones nobody will open.
| System | What the agent would do | Why the write gets refused |
|---|---|---|
| LIMS | File results, flag out-of-spec samples, chase a batch | Sample records carry subject identifiers, and lab systems rarely scope an API credential below the whole instance |
| QMS | Open a deviation, route a CAPA, attach evidence | Quality records are audited artifacts, so an unattributable write is a finding on its own |
| CTMS | Update site status, reconcile enrollment, track monitoring visits | Trial data is the highest-sensitivity object in the estate and access is tied to delegated authority |
| eTMF | File a document to the right zone with the right metadata | Misfiling is an inspection risk, and the credential that can file can usually also delete |
| MES | Log a production event, release a batch, record a downtime reason | Validated systems, where any uncontrolled write is a validation question |
| Claims platform | Correct a coding error, resubmit, chase a denial | Money moves, and the write is visible to a payer |
Every row has the same shape. There is real value in the write, and the credential available is far wider than the task. So the answer is no, and the agent stays a read-only assistant that nobody uses twice.
What has to be true before a write clears review?
Three things, and none of them are model features.
The payload has to be stripped before the model sees it. Field-level redaction at the connector means the identifiers the agent does not need for the task never enter the context window. This is categorically stronger than instructing a model to ignore a field, because the data is gone by the time there is a prompt. It is also the single most common customization we build in healthcare: removing identifiers from a list-employees or list-subjects response so the same agent can run against a system it would otherwise never be allowed near.
The call has to carry a person’s identity, not a shared one. Permission inheritance means the agent acting for a coordinator gets exactly what that coordinator has, and the agent acting for a lab tech gets exactly what the lab tech has. Nobody gets a step up by going through the agent. The corollary matters just as much: an administrator of the integration platform must not be able to grant themselves access the underlying system never gave them.
The grant has to be per action, and the log has to name it. Not per system, not per connector. One named action, approved once, revocable on its own, with a log line that reads agent, action, object and principal.
This is the layer StackOne works on. An agent calls a single named action across 520+ connectors and 32,000+ actions, the grant is scoped to that action for that agent, fields are stripped at the connector before anything reaches the model, and every call is logged against the requesting user’s own principal. For the systems with no off-the-shelf connector, and in this sector that is usually the in-house LIMS or an MES nobody has documented since 2019, the AI connector builder generates one from the provider’s API documentation. On the compliance side: SOC 2 Type II, GDPR compliant, HIPAA compliant, with a Business Associate Agreement available on Enterprise plans where PHI is in scope. None of that makes the agent smarter. It makes the write reviewable, which is the step that blocks approval.
What does this look like when it works?
A US medical research organization came to us with exactly this problem, and with a security lead who had already worked out that per-user permission inheritance was the requirement rather than a nice-to-have.
Their first connector was live on the day the contract was signed. Nine business systems were connected inside two weeks, spanning identity, device management, ticketing, finance and procurement. What made that possible was not integration speed. It was that granular per-account access control existed, so each new system could be connected without widening anyone’s blast radius. Their words, roughly: once the granular access is there, you can be confident about connecting everything.
That runs the opposite way to how governance is usually pitched. Tighter control did not slow the rollout down. It is the only reason the rollout got past the first system.
How do you get an agent write access approved in healthcare?
Take the five questions your security team will ask and answer them before the meeting.
- List the systems the agent writes to and name the field it changes. One line each. If the team that built the pilot cannot produce this list in a minute, the pilot has not been scoped and the review will end there.
- Name the principal on every write. If it is a service account shared with other jobs, the answer is no regardless of how well the agent performs. Inherit the requesting user’s identity instead.
- Test whether a single grant can be revoked alone. Ask what else breaks if you cut the agent’s access to one object. If the answer is the nightly sync, the grant is tenant-wide and you are asking for tenant-wide approval.
- Write down which fields never leave the source system. Identifiers the task does not need should be stripped at the connector, not filtered in a prompt. Bring the field list, not the intention.
- Pull one log line and read it aloud. It should name the agent, the action, the object and the person. If it names a service account, adding real logging after approval becomes a second project and the first one does not ship.
Four of those five are properties of the integration layer, not of the agent. That is the whole point. Teams spend months on model selection and evaluation, then fail the review on a credential decision made years earlier by whoever wired up the first nightly sync.
Shadow AI at 43% of incidents is what a refusal buys you. The people who need the write will find a way to get it, and it will not be through the reviewed path. The alternative is to make the reviewed path narrow enough to say yes to.
We are running a live stream on this: Connecting AI Agents Securely in Healthcare. Jacob and Alex strip a field out of a live HR connector, run an agent against it, and show what comes back.