Protecting an AI agent's inbox from spam floods and prompt injection

0:00Cold open: the flood

This is a flood. Fifteen hundred letters, fired at a show's own mailbox by its own agent, on purpose. The show reads its mail with AI models, and every letter a model reads costs money. So there's a circuit breaker built into the front door, and this is the test that proves it trips. Watch for two words on the screen: storm mode. Here is how that front door got built, and how we tried to break it, in the words I said while it was happening.

0:32The question I deferred

To see why the front door matters, start with what's behind it. The system is a debate show. Four AI models argue over a letter from the public, a fifth one rules, and the episode renders and publishes itself. So it takes input from the outside world: a form on its website, a mailbox, and later, comments. During planning I raised a security question and deferred it until the machine was built. Anything coming in from outside, I want to be very, very cautious with. Scrub it for prompt injection, for spam, and validate it before the system takes it for something it can work with. The question was whether that called for two virtual machines: one to take in the public's input, and one for the show and the back office. We chose one, for now. The machine runs its services in containers, and the containers sit on separate networks, so the ones that handle the public's input are walled off from the ones that make the show. And we didn't want to double the cost of our machines just yet.

1:40The door, and the deck

With that settled, the next working session built the door itself. Several agents worked in parallel, each with one job and a fence around it. The one that matters here built the blank ticket on the site, and the scanner behind it, with a deck of hostile letters to catch. The point is plain: when a message arrives from someone in the outside world who is trying to do harm, we have a way to deal with it. The mailbox is opened by code, not by a model. Everything from outside, whether it came through the website or the mail, gets the sanitation treatment, so it's safe, and we won't hurt anybody if we pass it along. One thing you won't see in this video: the deck itself, or the scanner's rules. The design is fine to show. The detection logic is the answer key, and you don't publish the answer key.

2:38The first real letter

Before any flood, the simple case: one real letter. Late one night, with every container finally up, the agent filled in the form on the live site, to see how far a ticket got through the plumbing. The first try that night, ticket number two, went nowhere. The agent called the missing ticket a failure and went to the logs. The form had no permission to publish into the pipeline. That was granted. Ticket number three got through, and the scanner read it: a real model call, and a verdict of cleared. Then the scanner couldn't hand its result to the next stage, because it needed the same publishing permission. The pipeline is a message bus. A message goes into a topic, and every process subscribed to that topic gets a copy. It's a bit like multicast: in one port, out to many. If a process doesn't hold the role to publish or subscribe, it can't take part. Ticket number four ran the whole chain clean: form, scanner, next stage. And the receipts service, looking at the same traffic, declined to send a receipt, because the sender wasn't authenticated by its own mail provider. A rule, working on real data.

4:00A lock on the door

A working door is not a locked one. Two days later, the lock went on. The plan called for a CAPTCHA, the are-you-human check, switched on automatically when a lot of tickets arrive from the same origin. Somebody trying to stuff the bag. The console had moved on since the plan was written: the older version of that check was deprecated, so the agent switched to the enterprise version, and caught a mismatch in the site's own code that would have failed silently. Then proving it landed was harder than building it. A content distribution network sits in front of the site, and it kept reporting a cache hit, handing back the old copy after the new one was live. If a deploy seems not to have worked, rule out the cache before you touch the code. A hard reload helps. On Windows, in a browser, that's Control, Shift, R.

4:55Why flood yourself

With the lock on, it was time to lean on the door. The agent's plan was ten thousand pieces of mail and five thousand form posts. It's a rehearsal of a denial of service: an automated script, run by someone out in the world, flooding the mailbox or pushing too many tickets through at once. If the team had to process all of that, it would cost a lot of money and tokens, and it might grind everything to a halt. When you're dealing with public assets, a website, or anything that takes input from the outside world, you have to think through everything the people on the other side of that surface could do to it, and put measures in place to keep it from being misused. Our industry has a name for one of those people: the script kiddie. They don't exactly know what they're doing. They just want to send a flood of email, or click submit on a pile of random tickets, because they think it might be funny.

5:53Scaled down

The flood didn't go to plan, and that was a finding too. The test puts its letters straight into the mailbox through Gmail's interface, and Gmail limits how fast one account can take them in. The test hit that ceiling, and at a safe pace the full run would have taken most of an hour. So the agent asked to scale down to a smaller count that would still prove the defenses work as intended. We approved fifteen hundred. About half of them landed. That was plenty.

6:25Storm mode

Plenty, because within seconds, the line we were waiting for came up. Storm mode triggered. Inbound volume crossed a line the system was never meant to carry, and intake flagged it as a storm. The agent read that state back from the database itself, rather than taking the test script's word for it. Then we let the rest of the test run in the background, on its own.

6:50Defense in depth

While it ran, I went back to that CAPTCHA, because no one mitigation is sufficient. A front door with a CAPTCHA on it might make you feel secure. But agents are smart enough to solve those now. They look at the pictures and decide which tiles hold the requested item, and they add a little jitter to their timing so they seem human. So behind the front door sits the circuit breaker, for when the front line isn't effective. It cuts off access for everyone. Yes, that's a form of denial of service, one we chose. It also spares us the expense of processing all that bogus mail until we're back on track. Now imagine you put nothing in place, and a runaway ten thousand, or a hundred thousand, pieces of mail came through. That's an exponentially worse disaster than cutting off access for a little while, until the storm clears. That's defense in depth: layers, like an onion, each doing a different job as an attacker gets further in.

7:59The results, and the restore

Then the results came in, and they were good. Looking at each part in turn, starting with intake: none of the flood made it through to where it would cost anything. None of the flood traffic touched a model at all. Intake is plain code, so sorting and holding letters costs nothing. Letters from senders nobody could authenticate were held, with no reply and no model call. One more finding: intake reads the mailbox in pages, a bounded batch each cycle, so a big backlog drains over several cycles, not in one pass. The agent offered to stop watching identical cycles and call the test proven. That sounded good. Then the restore: a dry run first, to preview exactly what would change, then the real thing. Mode back to normal, the day's counters reset. Once the storm is over, we go back to production operations, but keep those controls ready to bring to bear in real time. Last, the cleanup: every test letter trashed from the mailbox.

9:08Inspect what you expect

That's the front door, from the first letter to the flood. Around it sit a few more layers. Records in the domain's DNS mean nobody can send mail as the show from somewhere else. But there's no perfect scenario. It's an arms race, between the people doing bad things and the people protecting their assets. You mitigate as much risk as you can, then you monitor in real time, and when a new vulnerability turns up, you work on it then. Even when the team handles the whole workflow on its own, tickets in and episodes out, it isn't set it and forget it. Somebody checks in, every day, that the works are working as designed. Inspect what you expect.