Why Nobody Is Talking About What Happens When the AI Stack Gets Compromised

The conversation around AI in business has been dominated by capability: what models can do, how fast they're improving, which workflows they can automate. That's a useful conversation. But in the final week of March 2026, two significant security incidents quietly reminded us that the infrastructure holding all of this AI capability together is still fragile, still under attack, and still being built with too much implicit trust. Neither incident made the front page. Both should have.

This is not a post about fear. It is about clarity — about what these two incidents actually reveal, why they matter to every business integrating AI, and what the organisations that will emerge from this era with their reputations intact are doing differently.

---

1. The Productivity Conversation We Are Not Having

Spend twenty minutes reading about AI in business, and you will find the same story running through almost everything: capability, speed, automation, competitive advantage. These are real. The productivity gains from AI-assisted development, LLM integration, and agent-powered workflows are not theoretical; they are measurable, and the companies moving quickly on them are pulling ahead in ways that are already becoming difficult to catch up to.

But there is a second conversation that is happening much more quietly, and it matters just as much. It is the conversation about what happens when the infrastructure underpinning all of this AI capability is itself the target. About what it means to build on a stack that is evolving faster than most security teams can track. About the gap, widening every quarter, between the pace at which businesses are adopting AI tools and the pace at which they are governing them.

In the final week of March 2026, that conversation became unavoidable for anyone paying close attention. Two security incidents, within forty-eight hours of each other, made the case more clearly than any threat report or conference keynote could. One hit developers at the infrastructure level. The other hit patients at the data level. Together, they are not two bad weeks for two unlucky companies. They are a signal about where the threat landscape is moving, and who it is moving toward.

The organisations racing fastest to adopt AI are, in many cases, the same ones with the least visibility into what their AI infrastructure can actually access — and what happens when that access is abused.

Understanding that signal, and what to do about it, is the purpose of this post.

---

2. Two Incidents That Reveal a Pattern, Not Just Bad Luck

By now, you may have already seen the headlines: a backdoored Python library, a breached healthcare platform, credentials stolen at scale. The news moved fast. What the news coverage largely missed was the thread connecting the two incidents — the structural failure that sits underneath both of them and that will keep producing incidents like these until organisations address it directly.

Both attacks succeeded not because of technically sophisticated exploits or nation-state-grade zero-days. They succeeded because of trust that was assumed rather than examined. In the first case, a developer ecosystem that trusted package registries, trusted CI/CD pipelines, and trusted upstream security tools without verifying any of it. In the second, a healthcare architecture that trusted a perimeter, trusted that a single environment breach would be detected quickly, and trusted that the monitoring in place was adequate for the sensitivity of what it was protecting.

That is the pattern. Not two companies with bad security teams. Two organisations that made the same category of error that most organisations are currently making: treating trust as a given rather than as something that has to be earned, verified, and maintained at every layer of the stack.

The most dangerous assumption in modern software infrastructure is not "this will never be attacked." It is "this is probably fine." That quiet confidence, unexamined and unverified, is what both of these incidents exploited.

It is also worth noting the timing. This week saw OpenAI close a record $122 billion funding round at an $852 billion valuation. Frontier models are dropping faster than ever. Agentic AI has moved from demonstration to production. The industry is moving at a pace that has never been seen before, and that pace is making the governance gap wider, not narrower, for most businesses. The incidents of March 2026 are what that gap looks like when it is found and exploited.

---

3. Breach #1: The LiteLLM Supply Chain Attack

What LiteLLM Actually Is

To understand why this attack matters, you need to understand what LiteLLM does. It is a universal routing layer for large language model APIs — a single interface that lets developers call models from OpenAI, Anthropic, Google, AWS Bedrock, and over a hundred other providers without rewriting their integration logic for each one. It handles authentication. It manages retries. It tracks costs across providers. In most modern AI stacks, it sits directly between your application and every LLM API call you make. It had approximately 97 million monthly downloads and was used by companies including Stripe, Netflix, and Google.

That position — that concentrated, trusted access to API credentials across every AI service an organisation uses — is precisely what made it an attractive target. Compromise LiteLLM on a developer machine, and you do not just steal one credential. You potentially harvest the keys to every AI service that organisation is running and paying for.

How the Attack Unfolded

The attacker group, known as TeamPCP, did not start with LiteLLM. They started in late February by exploiting a misconfigured GitHub Actions workflow in Aqua Security's Trivy scanner, a widely trusted open-source vulnerability tool. They then used the access harvested from Trivy to attack Checkmarx KICS on March 21. By March 24, they had used the same infrastructure to exfiltrate PyPI publishing credentials from LiteLLM's own CI/CD pipeline, which was itself using Trivy as part of its build process.

The progression is not accidental. Security tools. Infrastructure libraries. AI proxies. TeamPCP is specifically targeting the tools developers trust most deeply, because that trust translates directly into the highest-value access. Every step of their campaign used the trust established in the previous one.

What the Malware Did

Version 1.82.8 contained a .pth file that Python executes automatically on every interpreter startup, with no import statement needed. Opening a terminal triggered it. Running tests triggered it. Starting a server triggered it. Spinning up a CI runner triggered it.

The payload harvested SSH private keys, .env files containing API keys and secrets, cloud credentials across AWS, GCP, and Azure, Kubernetes service account tokens and cluster configs, and database passwords — everything encrypted and exfiltrated to a domain crafted to look like legitimate LiteLLM infrastructure. On Kubernetes environments, the attack escalated further: deploying privileged pods and reading cluster-wide secrets.

A bug in the malware — a recursive fork bomb caused by the .pth launcher — spawned child processes that re-triggered themselves, causing some machines to crash from RAM exhaustion. That crash is how the breach was first noticed. A developer at FutureSearch saw the anomaly, used Claude Code to trace it, and identified the backdoor. Without that accidental signal, the credential theft would have continued silently.

The Structural Lesson

The LiteLLM attack is a case study in cascading trust failure. LiteLLM trusted Trivy. Trivy had been compromised. Developers trusted PyPI. Teams trusted unpinned builds to pull a safe version. Every assumption in that chain was reasonable in isolation. None of them were verified. One upstream compromise collapsed them all.

Over 74% of malicious packages reach production through transitive dependencies — packages that your packages install, not packages you consciously chose. Most teams audit their direct dependencies. Almost none audit the full chain. The LiteLLM attack is a live demonstration of what that gap costs.

---

4. Breach #2: The CareCloud EHR Hack

Who CareCloud Is

CareCloud is a publicly traded healthcare technology company serving over 40,000 medical practices, clinics, and hospitals across all 50 US states. Its platform handles electronic health records, practice management, billing, revenue cycle management, and clinical analytics across more than 70 medical specialties. It is, in practical terms, the software infrastructure for a significant slice of American healthcare delivery.

What Happened

On March 16, 2026, an attacker gained unauthorised access to one of CareCloud's six electronic health record environments. The company restored full functionality the same day. But by then, the attacker had been inside a live healthcare data environment for approximately eight hours, undetected.

CareCloud did not publicly disclose the incident until March 30 — fourteen days after the breach — after determining it was legally material enough to require SEC notification. Within 24 hours of the public disclosure, multiple law firms had opened class action investigations. The forensic investigation into what was accessed or exfiltrated remains ongoing.

Why Eight Hours Matters

A typical electronic health record contains a patient's full name, date of birth, address, Social Security number, diagnoses, prescription history, insurance details, and clinical notes from every appointment. In illicit data markets, healthcare records consistently command higher prices than financial credentials — harder to change than a password, more comprehensive as an identity document, and more useful for a wider range of fraud.

The eight-hour window is only part of the concern. The architecture that allowed a single environment breach to potentially threaten records across 40,000 providers raises deeper questions that the breach itself did not create — only exposed. What data minimisation had been applied? How long had records been retained? Was the environment segmented in a way that limited blast radius, or only in a way that limited entry points?

Healthcare as a Proxy for What Comes Next

Healthcare is the most attacked sector in the United States, and it is worth understanding why. It sits at the intersection of three conditions: extraordinarily sensitive data, operational systems that cannot afford downtime, and chronic underinvestment in security relative to the value of what is being protected. Those conditions exist, in varying degrees, across every industry that is now integrating AI at speed. Healthcare is simply further along the exposure curve. What is happening there now is a preview of what will happen elsewhere as AI integration deepens and the data held by AI-adjacent systems grows.

---

5. The Distinction Most Organisations Are Missing

One of the most persistent sources of confusion in organisational security is the conflation of data privacy and data security. They are related. They are not the same thing. And treating them as interchangeable produces systems that satisfy neither.

Data security is about preventing unauthorised access. It asks: can someone get in who should not be able to? Encryption, access controls, vulnerability management, patch cycles, anomaly detection, and incident response. Security is largely a technical discipline with clear best practices and measurable outcomes.

Data privacy is about appropriate use. It asks: even if you can access this data, should you? For what purpose? For how long? Shared with whom? Under what legal basis? Privacy is partly legal, partly ethical, and largely architectural. It asks not just who can reach the data, but whether the data should exist in the form and volume it currently does.

A system can be entirely secure and still be a privacy disaster. A system can have excellent privacy policies and still be trivially breached.

Most organisations are navigating both dimensions simultaneously, with gaps in each that they have never properly mapped.

The LiteLLM attack is, at its core, a security failure. Dependencies unpinned. Build pipelines unverified. CI/CD credentials unrotated after a known upstream compromise. None of those failures has anything to do with the privacy policy.

The CareCloud situation is more instructive. Even if forensics ultimately confirms no data was exfiltrated — still unknown at the time of writing — the architecture that allowed a single environment breach to threaten records across 40,000 providers raises privacy questions that predated the breach entirely. How long were records retained? Was data minimisation applied? Was the system designed to limit blast radius, or only to limit entry points? These are not security questions. They are data governance questions. And most organisations cannot answer them confidently.

The honest audit most businesses need to run is not just "who can get in?" but "why does that much data exist in that form, in that place, with that level of access attached to it?" Those are different questions, and they require different answers.

---

6. Why the Tools You Choose Are a Security Decision

Tools embody values. The decisions built into any tool — what it can access, what it transmits, what requires explicit permission, and what it refuses to do by default — reflect a position on what the tool's creators believe matters. In the current environment, that means tool choice is a security decision as much as a productivity one.

It is worth noting that the LiteLLM attack was first identified by a developer using Claude Code. The engineer noticed the anomaly caused by the fork bomb, used Claude Code to trace it, and identified the backdoor. That is a small detail. But it speaks to something real about what it looks like when an AI tool is designed to operate within appropriate boundaries rather than reaching beyond them.

Architecture, not marketing

Claude Code runs locally on your machine and communicates directly with the Anthropic API. Your codebase is not indexed on an intermediate server. There is no cloud-side storage of your proprietary code sitting in a third-party dependency chain, waiting to become the next breach target. That is an architectural choice with direct security implications.

Anthropic has implemented OS-level sandboxing using Linux bubblewrap and macOS Seatbelt. The sandbox enforces filesystem isolation: Claude Code can read and write within your working directory, but cannot reach your SSH keys, credential stores, or anything outside the defined boundary. Network traffic routes through a controlled proxy enforcing domain restrictions, with user confirmation required for any new external domain.

Consider what that means against the LiteLLM attack specifically. The malware relied on two capabilities: reading files from anywhere on the filesystem, and making silent outbound connections to an attacker-controlled domain. Both are architecturally prevented in a properly configured Claude Code environment. The sandbox cannot reach ~/.ssh. The network proxy does not allow connections to unrecognised domains without user approval. The attack vector, as documented, does not work.

The data policy matters as much as the technical controls

Anthropic does not train its models on code processed through Claude Code. Feedback transcripts are retained for a limited period with restricted internal access. For teams working on proprietary systems, client projects under NDA, or regulated environments, this is as important as the sandboxing. It determines whether the AI tool increasing your productivity is simultaneously creating an ongoing IP exposure.

Approval gates and credential isolation

Every tool in Claude Code that makes a network request requires explicit user approval. When using Claude Code on the web, git operations route through a secure proxy. Signing keys and authentication tokens never enter the sandbox. Even a compromised session cannot harvest git credentials or push to repositories it has not been explicitly authorised to touch — a form of architectural separation that the CareCloud breach illustrates the value of in stark terms.

The best AI tools are not just capable. They are trustworthy by design, built to earn access rather than assume it.

In an environment where the AI stack itself has become a primary attack surface, that distinction is no longer marginal. It is the point.

None of this removes all risk. Prompt injection remains an active challenge. Third-party MCP server integrations require the same vetting as any dependency. Developers can misconfigure permissions in ways that undermine secure defaults. But the defaults themselves — local execution, sandboxed filesystem, network approval gates, no cloud indexing, credential-isolated git access — represent a fundamentally different starting position from the implicit trust model both of these incidents exploited.

---

7. The Question Every Business Leader Needs to Answer Now

The productivity conversation about AI is not going to slow down. Nor should it. The organisations that treat AI adoption as optional are already falling behind in ways that will be difficult to recover from.

But the conversation needs to expand. Not to slow adoption — to make it more durable. The businesses that will be in the strongest position in three years are not the ones that moved fastest in 2025 and 2026. They are the ones that moved thoughtfully: with visibility into their AI stack, governance over their AI tool permissions, and security architectures designed to contain failures rather than merely prevent them.

The question every business leader should be actively asking right now is not "how do we adopt AI faster?" It is: do we understand what our AI infrastructure can actually access, and are we confident that access is appropriately scoped, monitored, and governed?

Both incidents from March 2026 were preventable. Not with exotic tooling or unlimited budgets. With practices and architectural decisions that exist today, available to any organisation willing to make them deliberately rather than by default.

The LiteLLM attack was preventable with pinned dependencies, atomic credential rotation, and supply chain scanning in CI/CD. The CareCloud breach was containable with better segmentation, tighter data retention, and monitoring robust enough to surface eight hours of anomalous access in minutes rather than days.

The controls existed. The practices were known. What was missing was the decision to apply them. That decision is still available — proactively, before an incident forces it. The question is whether organisations will use it.