The AI Stuxnet Was Twenty Years Old. Your Building's Math Should Stay In The Basement.

SentinelOne published a teardown this week of a Windows kernel driver called fast16.sys. Import AI #457 covered it under the heading "AI Stuxnet." The framing earned the headline.

The driver does not steal data. It does not crash the host. It does not ransom anything. It sits resident in memory and quietly patches the high-precision math libraries used by engineering and physics simulation software. The list of targeted programs includes LS-DYNA, PKPM, and MOHID, which are the workhorse tools for crash modeling, structural analysis, and hydrodynamic simulation. The result of the patch is that the targeted simulations still run, still finish, still produce reports, and quietly produce answers that are slightly wrong.

The targeting list overlaps with software cited in the JCPOA Section T reporting on Iran's nuclear program. The binary predates the public Stuxnet by approximately five years.

That is the story. Twenty years ago, somebody figured out that the highest-leverage attack on a physical system was not to break it. It was to corrupt the math feeding the decision about whether to build it.

Why this is a building monitoring story

A small commercial building is not running LS-DYNA. Nobody is going to nation-state attack a 4,200 sqft strip mall HVAC system. The point of the AI Stuxnet teardown is not that the same binary will hit a sump pump. The point is the class of attack.

Take the model threat seriously for a minute. A building monitoring service that runs in the cloud has the following surface:

• Sensor data leaves the building over the internet.
• It lands in a vendor's pipeline. Some piece of software in that pipeline runs a model and decides what to alert on.
• That model is updated periodically. The update mechanism is somebody's CI/CD pipeline.
• Alerts come back to the building owner over the same internet.

The threat the AI Stuxnet teardown exposes is not "someone DDoSes that pipeline." A DDoS is loud. The owner sees red on a dashboard. They call somebody. The system gets fixed within a day.

The threat is the quiet one. Somebody pushes a model weight that biases the anomaly threshold a few percent in the wrong direction. The dashboard stays green. The HVAC compressor that was about to fail gets six more weeks of "normal" readings, until it actually fails on a Saturday at 2 AM in August, and the building owner is left wondering why the monitoring service did not flag it. The vendor gets a chargeback request. The vendor's incident review never finds the bias because the input data did look normal under the published model. The published model just had a different threshold last quarter.

That is the fast16.sys threat model, scaled down to a strip mall.

The defense is architectural, not contractual

Service-level agreements do not defend against this attack. SOC 2 audits do not defend against this attack. Contractual indemnification for "service availability" does not even address it, because availability stays at 100%. The system is up. It is producing readings. It is just producing readings against a model whose math has drifted.

The defense is to put the model on hardware the building owner can see, with weights the building owner can hash, on a network segment the building owner controls.

That is the architecture we already ship.

That architecture has properties the cloud architecture cannot replicate:

The cost of the local-first version is real. Somebody has to put a small computer in the building. Somebody has to maintain it. The hashes have to actually get checked. None of that is free. But the cost is paid in setup hours and rack space, not in trust extended to a vendor whose model weights you will never see.

The sump pump is already this system

The edge AI sump pump system has been running for over a year. The model that decides whether the pump is operating in a normal cycle, or starting to show the vibration signature of a failing bearing, runs entirely on a Mac Studio in the same basement as the pump. The sensors are an ESP32. The signal path is twenty feet of Ethernet and a single MQTT topic. There is no cloud round-trip. There is no model update that comes from an external pipeline. When the model on disk changes, it is because I personally replaced the file.

That was not an explicit defense against fast16.sys. It was a defense against latency, against bandwidth cost, against the half-dozen times my home internet has dropped in the past year. It happens to also be a defense against the AI Stuxnet attack class, because if the model never leaves the building, no vendor pipeline can quietly corrupt it.

The smart building project we extended this architecture to has the same property at the scale of 40 devices. The lights, the doors, the temperature sensors, the soil moisture, the water leak detectors, all publish to a Home Assistant instance whose database is on hardware in the building. The model that decides whether a reading is anomalous runs on the same hardware. If the upstream Home Assistant project shipped a bad release tomorrow, the building owner could pin to last week's version and verify the hash. The system would keep running, on the correct math, on the correct weights, until they personally decided to update it.

What this changes for the buying conversation

The argument for cloud-based building monitoring has always been ease of deployment. The vendor handles the model, the vendor handles the updates, the vendor handles the alerts. The building owner does not have to think about it. For a long time that was a strong argument, and for many use cases it still is.

What the fast16.sys teardown changes is the conversation about what the vendor is taking responsibility for. The vendor is taking responsibility for availability. They are taking responsibility for response time. They are not, in any contractual sense, taking responsibility for "the model returned a correct answer." Nobody contractually does. The cloud monitoring vendor will pay you back for downtime. They will not pay you back for a quietly biased threshold that missed a compressor failure for six weeks.

Local-first does not solve that problem either, in the absolute sense. The model still has to be correct on day one. But it removes the attack surface where the model silently becomes less correct between day one and day six hundred. The weights on disk are the weights on disk. If they change, it is because somebody with physical access to the building changed them. The trust boundary is the room you are standing in.

That is a different sales conversation than "we have SOC 2." It is the conversation that, for any building owner who has ever asked the question "what is actually running in there?", lands differently.

The takeaway, written out

The fast16.sys teardown is a security story, and you can read it as a security story and stop there. The deeper read is that the most important property of an edge AI system, for a small building or any physical system, is not how powerful the model is. It is whether the model is on hardware the owner can see.

Twenty years ago, somebody figured out that the highest-leverage attack on Iran's nuclear program was to corrupt the math feeding the simulations, not the centrifuges themselves. The cloud-routed building monitoring stack of 2026 has the same exposure, at a smaller scale and a lower stakes table. The defense is the same defense. Run the math where you can see it.

That is the architecture we ship.

Sources: SentinelOne fast16.sys teardown via Import AI #457 (substack.com/redirect/5d0dff09); Weekly Robotics #360; The Intersecto field deployments at the Watertown and Northampton sites.