Agents on t0ul

Start here: what this book builds

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

The front door to my AI Security Engineering series, a local email-to-calendar agent I build, then attack, then harden. The code is on GitHub.

What we build

This book builds one real thing, then spends the rest of its length trying to break it.

The thing is small and genuinely useful: an agent that reads my kid’s school email, the newsletters and permission slips and early-dismissal notices, and quietly puts the real dates on our family calendar. It runs on my own machine, so none of my family’s mail ever has to leave it. By the end of the setup chapter you have the same thing running on yours, turning a real newsletter into calendar events.

The plan: a local email-to-calendar agent, built to be attacked

Tue, 12 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. The lessons are on GitHub, the agent itself lives at t0ul/emaildrop, and the project page is here.

The thing I actually wanted

I get buried in school email. Newsletters, permission slips, early-dismissal notices, a classroom-app invite with an RSVP link somewhere in it. What I wanted was small and ordinary: an agent that reads all of it and quietly puts the real dates on our family calendar, running on my own machine, so none of my family’s mail has to leave it.

Set up your lab: from a bare Mac to a running agent

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

Why this post exists

Every other post in the series builds one feature, breaks it, and fixes it. None of them repeat the setup. This is the post they all link back to, so if you ever read “if you have not set up the lab yet, start there,” this is where you land.

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:

One shape for everything

Tue, 02 Sep 2025 00:00:00 +0000

Back to an empty project

As promised at the end of the last post, we rewind. No model, no defenses, nothing to attack yet. Part 1 is about building the boring core well enough that attacking it later actually means something.

Dates the model never decides

Tue, 09 Sep 2025 00:00:00 +0000

The field that bit me first

Of all the fields in the event struct, the one that caused trouble first was the date. School emails bury dates in prose, almost never say the year, and now and then they get the weekday wrong. That last one sounds harmless until you remember what the agent is for: a wrong date on the family calendar is the whole product failing, and failing quietly, because a calendar entry does not look wrong. It just sits there.

Inert output and the human accept

Tue, 16 Sep 2025 00:00:00 +0000

The one-line shortcut

At the end of the date lesson I held a flagged event back for review and left two questions hanging: held where, and reviewed by whom. This post answers them, and it starts with the shortcut I was tempted to take instead.

The watched folder

Tue, 23 Sep 2025 00:00:00 +0000

A door anyone can slip a file under

The agent gets its mail by watching a folder. You drop a .txt in the inbox, and a loop notices it, runs it through the pipeline, and files it away. That folder is the whole input to the program, which makes it the first place to think like someone who wants to cause trouble, because a watched folder is a door, and anyone or anything that can write to it can decide what the agent reads next.

The eval harness: F1 as a receipt

Tue, 30 Sep 2025 00:00:00 +0000

“It works” is a feeling

Chapter 1 built the boring core: one event shape, dates checked by code, inert output, a watched folder with limits. Along the way I kept saying the agent works, and you have no reason to take that on faith, because I have not shown you a single number. “It works” is a feeling, and a feeling is no way to run a security project.

Attacking the baseline, all red

Tue, 07 Oct 2025 00:00:00 +0000

Now break it

Last post the agent scored a perfect f1=1.00 on clean mail, so I can finally say it works and mean a number. This is where that stops being comfortable. The whole point of the baseline was to have something honest to attack, so let us attack it.

A log you can trust

Tue, 14 Oct 2025 00:00:00 +0000

See it before you stop it

Last post ended on a red board: a catalog of attacks the agent cannot yet withstand, with one of them, an injected email, shown landing live. The obvious next move is to start swatting them down. I am not going to, not yet.

A gateway you cannot route around

Tue, 21 Oct 2025 00:00:00 +0000

One way out

Last post gave the agent a log it can trust, so it can tell you what it did. This post gives it the other half of the lens: one door that every model call has to go through. The reason is the same observability instinct. If the agent can open a connection to anywhere, then “what did it talk to” has no single answer, and worse, the answer can be chosen by someone who is not you. A choke point you control turns that into one honest, auditable fact, and it is the place to enforce the first rules.

One trace id, and the command stream

Tue, 28 Oct 2025 00:00:00 +0000

The thread that ties it together

Part 2 built a log you can trust and a gateway you cannot route around. This short post is the payoff that turns those two things from a pair of files into a lens, and it is the one thing I did not have to build, because it was already there once the first two were done. There is nothing to attack here. It is the free reward for instrumenting the agent properly, and it is worth pausing on before the defenses start, because it is what we will watch them through.

When the email gives orders

Tue, 04 Nov 2025 00:00:00 +0000

The first red line

The baseline post ended on a board full of attacks the agent could not withstand, and showed one of them landing: an email with an instruction buried in it, and a model that followed the instruction. Now we have the lens from Part 2, so this time we do not just watch it land. We add the control, and we watch the same attack go to zero, against the real model, measured.

The email is data, not orders

Tue, 11 Nov 2025 00:00:00 +0000

When the filter misses

The last post stopped an injection by stripping the offending line before the model saw it. That sanitizer works, but it works by recognizing the shape of an attack, and anything that recognizes a shape can be slipped past by a shape it has not seen. So underneath it there has to be a second idea that does not depend on spotting the attack at all: the model should treat the entire email as data it reads, never as instructions it obeys, so that even an order the filter misses is still just text about an event, not a command.

System-prompt leakage

Tue, 18 Nov 2025 00:00:00 +0000

The mirror attack

The last two posts were about an email that plants an instruction. This one is the reverse, and it is easy to overlook because it does not change what the agent does, only what it says. Instead of giving the model a new order, the attacker asks the model to hand over the orders it already has: its system prompt, the instructions that tell it how to behave and, crucially, what it has been told to refuse. That prompt is the blueprint of the agent’s defenses. Leak it, and an attacker stops guessing and starts reading your rules, looking for the gap. OWASP files this under LLM07, system-prompt leakage, and it is the last injection problem in this chapter.

Scrubbing secrets and PII at ingest

Tue, 25 Nov 2025 00:00:00 +0000

What the agent keeps

Chapter 4 was about what the model is told. Chapter 5 is about what the agent keeps. To answer a question like “what is on the calendar this month,” the agent indexes every email it reads into a searchable corpus, so it has something to search later. That corpus is a file on disk, and it is broadly queryable by design, which makes it the quietest privacy problem in the whole project: anything secret that an email happens to carry gets copied into it, in the clear, and then just sits there. A later prompt-leak like the one from the last post, or a careless query, and it is out.

The calendar-field exfil

Tue, 02 Dec 2025 00:00:00 +0000

Inert is not the same as harmless

The last post stopped a secret from getting into the agent’s memory. This one stops a secret from getting out. Way back in the inert-output post I made a point of the agent writing a calendar file and nothing else, no auto-add, nothing that touches a real calendar on its own. That makes the output safe to accept by hand. It does not make the output content safe, and those are different things.

The tracking pixel

Tue, 09 Dec 2025 00:00:00 +0000

The surface that does not look like output

The last post closed an exfiltration channel in the calendar file the agent writes. This one closes the same kind of channel on a surface that does not feel like output at all: the screen. The agent has a web page where it shows you a summary of your mail, and that summary is rendered from markdown the model produced. Markdown renders in a browser, and a browser does things with markdown that a text file never does.

A web-search tool that hits a local server

Tue, 16 Dec 2025 00:00:00 +0000

The first tool that reaches out

Everything the agent has done so far is passive. It reads email, writes an inert file, draws a page. This post gives it the first tool that acts on the outside world on its own: a web search, something that takes a URL and fetches it. That is a small feature and a large change, because the URL does not come from me. It comes from the model, which built it after reading an email I do not control. A tool that will fetch whatever URL it is handed, driven by a model that can be talked into handing it anything, is server-side request forgery, and this is the post where the agent first has the power to commit it.

Least privilege

Tue, 23 Dec 2025 00:00:00 +0000

What a tool is allowed to do

The injection chapter was about what the model is told, and the secrets chapter about what the agent stores and emits. This chapter is about agency: what the agent is actually allowed to do. The agent is not one program, it is a set of tools the planner chooses between, one that summarizes, one that extracts events, one that writes the calendar file, and the safest way to run a set of tools is to assume any of them might be turned against you and make sure none of them can do more than its own narrow job.

The human gate

Tue, 30 Dec 2025 00:00:00 +0000

The action no rule should take on its own

The last post scoped what each tool is allowed to do. This one is about a category of action that no scope should ever grant automatically: the irreversible kind. Putting an event on your real calendar, following a link, sending something on your behalf, these are not things you want a confident model deciding by itself, no matter how well its tools are fenced. They need a person to say yes.

Circuit breakers and runaway loops

Tue, 06 Jan 2026 00:00:00 +0000

The attack that never finishes

The last two posts fenced what the agent may do and who has to approve it. This one is about an abuse that slips past both, because it never tries to finish an action and never oversteps a capability. It just refuses to stop. An agent that moves from one step to the next, plan then act then plan again, can be pushed into a cycle that never reaches an end, by a bug in its routing or by an instruction that keeps it busy. Each trip around that cycle is real work: a model call, a tool run, time and money spent. With nothing to stop it, it runs until the machine falls over or the bill arrives. That is denial of service aimed at the agent itself, OWASP LLM10, and it is the last control in this part. It is deterministic, no model:

The problem with running code

Tue, 13 Jan 2026 00:00:00 +0000

A different class of danger

Everything in the first three parts was, in the end, survivable with ordinary care. The agent read untrusted mail, wrote a file nobody auto-imports, and when it reached the network it did so through a gate that checked the address. The worst a single failure could do was calendar a wrong event or leak one request, and each of those we closed.

The detonation chamber

Tue, 20 Jan 2026 00:00:00 +0000

Run it where it cannot reach anything

The last post ended on a command, produced by a model from an email, running on my machine as me. I argued there that you cannot make that safe by inspecting the command, because a shell has endless ways to spell an attack. The real answer is to stop inspecting and start isolating: run the code somewhere that contains nothing and connects to nothing, so that whatever the command turns out to be, it executes against an empty room.

Egress-deny and the one way out

Tue, 27 Jan 2026 00:00:00 +0000

Safe is not the same as useful

The last post put untrusted code in a box with no network card, so a command from an email could run and reach nothing. That is safe, and it is also too absolute to be the final answer, because every so often a tool genuinely needs the network. The user asks what the weather is for an outdoor event, a tool needs to call a real API, and a chamber that can never reach anything cannot do that job. A box with no exits is secure the way a brick is secure.

No shell

Tue, 03 Feb 2026 00:00:00 +0000

The hole in the way in

This chapter put untrusted code in a box with no network card and gave that box one audited way out. Both are about what the code can reach once it is running. There is a hole left on the other side, in how the command gets into the box in the first place, and it is the oldest bug in computing wearing a new coat.

The dual-LLM brain

Tue, 10 Feb 2026 00:00:00 +0000

Split the brain

The isolation chapter kept dangerous code from reaching anything. This chapter is Part 4’s other big idea, and it goes after the root of every injection in the book: the fact that one model both reads the untrusted email and decides what the agent does. When the reader and the actor are the same model, a sentence in an email that says “do this” is sitting in the mind of the thing that does things, and no amount of asking it nicely to behave, as the spotlighting post showed, reliably keeps it from obeying.

Agent-to-agent hand-off

Tue, 17 Feb 2026 00:00:00 +0000

The seam between the two brains

The last post split the brain in two: a planner that decides and a reader that reads untrusted text but cannot act. I ended it by admitting the split rests on something I had not built yet. The two halves have to talk. The planner decides on a plan and the executor carries it out, and between them is a message that says “here is the plan, run it.” If the executor will act on any message that claims to be the plan, then the line we drew between reading and acting has a door in it, and anyone on the bus can knock.

A pinned tool catalog

Tue, 24 Feb 2026 00:00:00 +0000

A plan can be honest and still go wrong

The last post made the hand-off between the agent’s brains unforgeable. A plan now provably comes from the real planner, unaltered. But an authentic plan still names tools, and it reaches for them through MCP, the Model Context Protocol, where a server advertises a catalog of tools and the model reads each tool’s description to decide how to use it. The plan can be perfectly genuine and still call a tool whose definition is not what it was when you approved it.

Conflicts and mangled data

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

The adversary is the data

Every attack so far had someone behind it. This chapter does not. The thing that corrupts the agent’s answers most reliably is not an injection, it is that school emails are a mess: they put an event on a weekday the date does not fall on, they omit times and years, they say the meeting moved and leave both dates in, they say “we do not accept late forms” in a sentence a careless cleaner turns into “we accept late forms.” None of this is hostile. It is just wrong, and a model asked to extract events will hand you the wrong answer with the same confidence as the right one, because sounding right is all it does.

A full-chain attack, contained

Tue, 02 Jun 2026 00:00:00 +0000

One email, every attack

The book has taken the attacks one at a time, which is how you learn them and not how they arrive. A real hostile email does not politely send its injection on Monday and its exfiltration on Tuesday. It packs everything into one message and hopes one thing gets through. So the capstone is a single email that tries the lot, run against the actual pipeline, with nothing mocked.

Tasks and reminders

Tue, 09 Jun 2026 00:00:00 +0000

More than meetings

The capstone chapter builds the agent out to the thing you would actually use, one feature at a time, each arriving with its own attack and its own fix. First feature: an email does not only announce events. It also carries to-dos (“return the signed form”), heads-ups (“guest author visiting”), and actions (“RSVP at this link”). So the agent learns to pull all of them out, tagging each item with a kind: event, task, heads-up, or action.

My week at a glance

Tue, 16 Jun 2026 00:00:00 +0000

The view that lays out your week

The last feature sorted items by kind. This one lays them out in time: My Week, the seven-day strip that answers “what have we got going on” at a glance. It is the view people actually open, and building it means a new decision the agent has to make for every item, which day does this land on.

The directory and contacts

Tue, 23 Jun 2026 00:00:00 +0000

A directory is a pile of PII

A useful assistant knows who is who. So the agent builds a small contact directory out of your mail: the people who show up, and how to reach them. It is a convenient feature and a dangerous one, because a directory is a pile of personal data by definition, and the email it is built from is untrusted. Whatever rule decides what goes in the directory is a privacy boundary, and boundaries that are drawn loosely leak.

Action links

Tue, 30 Jun 2026 00:00:00 +0000

The one thing that acts

Two posts ago the agent learned to tag a link in an email as an action, kept separate from the quiet to-do list precisely so a human would see it. This post is about what happens when someone actually acts on it. An action link is the single most dangerous thing the agent handles, because following it is a real outbound request: it can carry data out of the house, or reach inward to something only the machine can see. Every other feature so far produced text; this one produces a network call.

Calendar CRUD and export

Tue, 07 Jul 2026 00:00:00 +0000

The quiet failure

Most of this book has been about a hostile email. This feature fails without one. Writing events to the calendar and exporting them is the agent’s one durable side effect, the thing that shows up on your actual phone, and the way it goes wrong is the most ordinary bug there is: it happens twice. The folder watcher restarts and re-reads an email it already processed. A request times out and the client retries. An export runs a second time. Every one of those is correct behavior, a safe operation repeated, and every one of them, done naively, puts a second copy of the same event on your calendar.

The UI and chat

Tue, 14 Jul 2026 00:00:00 +0000

The surface people actually touch

Everything the agent does finally shows up in one place a person uses: a chat box. You ask it a question in plain language, it pulls the relevant things out of everything it has ever read, and it answers. It is the friendliest surface in the whole product and the most exposed, because “everything it has ever read” is a corpus full of untrusted email, and the chat’s job is to put pieces of that corpus into a prompt and answer from them.

Conclusion: what you built, and what's next

Tue, 13 Oct 2026 00:00:00 +0000

Part of my AI Security Engineering series, a local email-to-calendar agent I build, then attack, then harden. The lessons are on GitHub, and the agent itself lives at t0ul/emaildrop.

You built an agent that does not get owned

Go back to the first chapter and the want was ordinary: read the school email, put the real dates on the calendar, keep it on my own machine. What stood between that want and a safe version of it was most of AI security, and you have now walked the whole distance. The agent reads text from people it cannot trust, holds private data, and uses tools that act, and it does all three without handing an attacker the keys. That is the finished thing.