The argument, and who is making it
The case is straightforward. Signature-based antivirus, endpoint detection and the broader detection-and-response category all share a structural weakness: they identify ransomware by watching it behave, which means the software has already started executing before any alarm sounds. Modern crews have adapted to exactly that — fileless techniques, automation, telemetry tampering, encryption from safe mode, and intrusions through supply-chain vendors rather than the target’s own perimeter. Ransomware-as-a-service means the operator no longer has to be the author.
The newer claim is that employees running AI agents and tools without IT oversight — shadow AI — have become a delivery path that conventional stacks, built around files and network traffic, were never designed to watch.
The vendor making the argument sells a prevention product and backs it with a refund guarantee. It has published no independent test results, and a tool built to stop known execution patterns faces the same question the detection tools did: what about the technique that is not yet catalogued? All of that is fair. It is also beside the point, because the two observations stand on their own, and they apply with particular force to the system an organisation is about to connect AI to.
Detection is the wrong control for a data platform
For an endpoint, catching an attack a few seconds into execution may be acceptable. For a warehouse, it is not. By the time a detection tool notices an anomalous process on the platform, the encryption of the first tables has begun, or the exfiltration has started, and the question becomes recovery. The controls that matter for a data platform are the ones that make the action impossible rather than the ones that notice it.
- Least privilege at the data layer. Row- and column-level permissions, service accounts scoped to the tables they need, and no standing administrative access. An attacker — or an agent — with a compromised analyst credential should reach an analyst’s data, not the platform.
- Allow-listed paths in. A known, finite set of connectors and services may reach the warehouse; everything else is refused. This is the single control that most organisations lack and most would benefit from, because it converts “who has access?” from a research project into a list.
- Backups the platform cannot reach. Immutable, separately credentialled, restore-tested. Detection does nothing for the case where prevention failed; this does.
- Segregation of the platform from the estate. The warehouse should not trust the endpoint fleet. A compromised laptop should be a compromised laptop, not a route to the customer master.
Shadow AI is an access-path problem
The shadow-AI observation deserves translation out of security language. An employee running an unsanctioned AI tool that reads enterprise data has, from the data platform’s perspective, created a new access path: credentials, an integration, a copy of data leaving through a service nobody has reviewed. Whether the tool is a delivery mechanism for ransomware is one risk. That the tool exists at all, invisibly, is the underlying one.
The remedy is the same allow-list. If the only paths into the platform are the governed connectors — and the governed connector is precisely what a sanctioned AI programme needs anyway — then the unsanctioned tool cannot reach the data, and the question of whether it is malicious never arises. Prevention here is not a product. It is an architecture decision about how AI gets to data.
The order of work
This sets the sequence for an AI programme, and it is the sequence most organisations get backwards. The pilot wants data access now; the platform team is asked to open a path; the path is opened as an exception; the exception becomes permanent. Six months later the platform has a dozen such paths, some to tools nobody remembers approving, and the detection stack is the only thing watching them.
The alternative is foundations first: define the governed path — permissions inherited from the platform, logging, classification, an allow-list — and make it the only door. It takes longer to open the first pilot. It makes every subsequent pilot faster, and it means the AI programme and the security posture are the same piece of work rather than competing ones.
What to take from a vendor’s pitch
Keep the diagnosis. Decline the guarantee as evidence. And ask any prevention vendor the question that separates a claim from a control: how does the product perform against techniques that were not in the catalogue when it shipped? For the data platform, the honest answer is that the strongest prevention is not a product at all. It is the decision that only known paths reach the data — made once, before the first agent connects.
