Why this publication is called POISONED

Every system you ship is assembled from things you did not build. Base images, packages, model weights, datasets, prompts, tools an agent is allowed to call. You trust each of them because someone else checked, or because it worked yesterday.

Poisoning is what happens when that trust is spent without anyone noticing. A dependency gains a new maintainer. A training set gains a few thousand quiet examples. A pipeline gains a step that runs on a pull request from a fork. An agent reads a document that tells it to do something else.

None of these look like an attack from the inside. They look like a normal build. The tests pass, the deploy is green, and the dashboards stay quiet.

The trust boundary moved

For most of the last decade, supply chain security meant packages and build systems. The industry learned, slowly, to pin versions, generate SBOMs, sign artifacts and isolate CI runners. AI moved the boundary again. Now the supply chain also includes:

• Data that shapes behaviour without ever being executed.
• Weights that are opaque binaries, often loaded with formats that can run code.
• Agents that turn text they read into actions they take, with whatever credentials you gave them.

The controls that exist for code rarely cover these. That gap is where the next incidents are coming from.

What you’ll find here

Real incidents. Reproducible attacks. Practical defenses. POISONED investigates how trusted AI inputs become attack surfaces, and shows engineers exactly what happened, how to detect it, and what to change. Every report follows the same three steps:

1. Find what you trusted. The input, who vouched for it, and the boundary it was allowed to cross.
2. Prove how it was poisoned. The chain, step by step, with versions, logs and sources for every claim.
3. Fix the boundary. The detection query that would have caught it, and the guardrail to ship as code you can review.

The articles are aggressively technical and written for developers and security engineers. They assume you already know AI security matters. If a piece can’t show the commands, configs or code behind its claims, it doesn’t get published here.

Findings are mapped to SLSA, NIST SSDF, the OWASP Top 10 for LLM Applications and MITRE ATLAS, so they can go straight into a backlog or a risk register. Articles that follow one incident are grouped into case files.

Verify, don’t trust

Every article lists its sources, records corrections in public, and carries a SHA-256 hash of its own source text. You can check it:

curl -s https://poisoned.dev/articles/why-poisoned.md | sha256sum

If the hash on the page and the hash you compute don’t match, something between the source and your screen has been poisoned.

curl -s https://poisoned.dev/articles/why-poisoned.md | sha256sum