It is 4 pm on a Friday. Dev, an ML engineer, wants to try a model from Hugging Face before the weekend. The model card has one line of setup: add trust_remote_code=True. He pastes it into a notebook on the team’s GPU box and hits run. The model loads. It answers his test prompt. He closes the laptop and goes home. On Monday, the cloud bill shows GPU hours nobody scheduled. The API keys that sat in that notebook’s environment were used from an address the team does not recognize. Dev’s code had no bug. The model’s output looked fine. The cause was a Python file he never opened. Dev is made up. The setup is not. Loading a model looks like downloading data. With trust_remote_code=True, you also download code and run it on your machine. This post covers how that works, where the code lands on disk, and how to reduce the risk.

In recent months, we saw a run of software supply chain attacks against the npm ecosystem. Packages used by millions of projects were replaced with versions that stole credentials, drained crypto wallets, or installed remote access trojans. This post lists the main incidents, explains the SLSA framework, and works through which attacks SLSA could have stopped and at which level.

SLSA stands for Supply-chain Levels for Software Artifacts. It is pronounced “salsa”. It is a specification for software supply chain security, maintained by industry consensus under the Linux Foundation. This post explains what SLSA is, how it works, where it applies, and the checks required at each level. It covers version 1.2 of the specification. Official specification: slsa.dev/spec/v1.2

In the last post, we went through the static threats that live inside AI models before they ever see a user. Training data poisoning, model backdoors, serialization exploits, weight tampering, hardcoded behavior, weight theft, and compression artifacts. These are not theoretical. They are real, documented, and growing as a concern as more organizations build and deploy models at speed. This post is about what you can do about them. Not in theory. In practice, today, with tools that exist.

Everyone in the AI space knows about prompt injection. Someone slips a bad instruction into a model’s input at runtime, and the model does something it shouldn’t. It’s the kind of attack that gets blog posts, conference talks, and CVEs. But there is a whole category of threats that get almost no attention, and they are arguably harder to detect and fix. These are static threats: vulnerabilities that live inside the model itself, before it ever sees a single user input. This post is about those threats.