Security

A few weeks ago I wrote that defense in depth for AI agents means layers, not walls: screen untrusted content before the model acts on it, sanitize what comes back out, and never trust the data flowing through. Clean theory. Then I went back and read the code in Herald that was supposed to implement those layers.

Several of them didn’t hold.

Herald is my feed reader. It pulls RSS and Atom from across the internet, runs each article through a local security model before anything else touches it, scores the survivors for relevance, and announces the interesting ones. Every feed item is untrusted content aimed at a model. That’s the whole premise of the defense-in-depth piece, and it’s exactly the threat I built Herald to study. What follows is the v0.2.0 hardening pass – the bugs the theory missed, and a couple of ideas that worked.

On March 24, 2026, the LiteLLM PyPI package was compromised. Versions 1.82.7 and 1.82.8, published by an account labeled TeamPCP, contained malicious code. I had LiteLLM running in my homelab as a routing layer between local AI clients and several model backends. This post is the postmortem: what I was running, what the exposure actually was, why I removed LiteLLM rather than just upgrading, and what the incident clarified about supply chain risk in homelab AI infrastructure.

The security conversation around AI agents has mostly focused on two things: keeping agents from hurting the host system, and keeping malicious tools out of the supply chain. These are real problems. Cisco documented how OpenClaw leaks credentials and executes arbitrary shell commands. Projects like NanoClaw respond by running agents in containers where bash commands can’t reach the host. Zencoder’s MCP survival guide catalogs supply chain attacks against MCP servers and recommends pinning git tags and auditing source.

Persistent memory for AI agents solves a real problem (the goldfish-with-a-PhD problem) but it introduces a new one: a high-trust, cross-session, cross-agent data store sitting inside the LLM’s context loop. Every recall is content that flows into a prompt. Every store is content that came from somewhere – sometimes the user, sometimes the model, sometimes a tool result that originated externally.

That’s a threat model worth writing down before the data store grows up. This post is the threat model for memstore – the persistent memory system I built for Claude Code – and the controls I’m applying or planning.