Attack-Driven-Design on t0ul

Attack-Driven Design, shown once

Tue, 26 Aug 2025 00:00:00 +0000

Part of my AI Security Engineering series, a local email-to-calendar agent I build, then attack, then harden. If you have not set up the lab yet, start with Set up your lab. The lessons are on GitHub, and the agent itself lives at t0ul/emaildrop.

A model changes the problem

In the last post the agent read an email with a set of hand-written rules, no AI involved. That version is predictable: the same email gives the same answer every time, which is exactly what you want from a baseline. Now that your lab has a model running, you can point the agent at it instead. With modeld up in one terminal, run this in another, from the emaildrop checkout you built in the setup post:

The one-command scorecard

Tue, 28 Apr 2026 00:00:00 +0000

From a pile of tests to one command

Five parts in, the agent is covered by dozens of before/after tests, each one an attack that lands without a control and is blocked with it. That is a lot of green, and green that nobody runs is just a feeling again. Part 6 is about the flywheel: the machinery that keeps all of this true as the agent grows, starting with the simplest piece, a single command that scores every control at once and fails loudly the moment one regresses.

From pattern to library

Tue, 05 May 2026 00:00:00 +0000

The same shape, written out too many times

By now you have read the same test two dozen times. Fire an attack at the control removed, confirm it lands. Fire it at the real control, confirm it is blocked. Read the result with an oracle. The only part that ever changes is the control and the attack; everything else is ceremony, and ceremony repeated by hand drifts, which is how you end up with a test that quietly stopped being able to fail.

ADD on an app that is not this one

Tue, 26 May 2026 00:00:00 +0000

The claim under the whole book

Thirty-odd lessons have attacked one agent. That is a good way to learn, and a bad way to end, because the thing worth taking away is not how emaildrop is secured, it is the method: build it, attack the real thing, resolve, re-attack live, keep every row wired. If that method only works on the app it was invented for, it is a story. If it drops onto an app it has never seen, it is a tool.