I built an email agent to triage bogus security reports – OpenComputer

Contents<br>What are we building?<br>What's a security report?<br>Getting the mail<br>Note on dev process<br>Keeping secrets secure<br>Who sends the email?<br>A valid-by-mistake report<br>Conclusion<br>← Back to blog<br>I built an email agent to triage bogus security reports

Written by Igor Zalutski · June 4, 2026

A customer shared a problem that at first sounded odd: they wanted to build an agent specifically to automatically review security reports they were getting on email. My initial reaction was: would you want something like that? Don't you want to review those reports yourself, it's security after all? Turns out, most of them were AI-generated and mostly noise; but they had to review each one because, well, it's security.<br>Now, we aren't in the business of building agents. We're building OpenComputer, an infrastructure primitive that agents use. But the question got me curious enough to want to actually build something. My thinking was: perhaps by building an agent I could discover something that I could improve in OpenComputer?<br>Disclaimer: "I built" means mostly "Claude built". I didn't write much code by hand, but the decisions while driving it felt worth sharing anyways. The result lives in the demo-agent-triage repo.

What are we building?

The first thing to clarify was the rough shape of the thing we want to end up with. No matter how good the coding agent is, it is not of much use if you don't know what to ask.<br>I wanted it to be as simple as possible, meaning as little moving parts as possible. The customer's problem originated in email and they wanted the result to land back in the email, so we can skip the UI. The agent would just:<br>get the email with a security report<br>analyze it against the actual codebase<br>send an email with a result

What's a security report?

How would it know which emails to process?<br>One way to solve it would be to spin up a sandbox with an agent for every email, and just do nothing if it's not a security report. But that would be obviously wasteful. So we'd need some way to only launch a "full" agent for the right emails.<br>We could build a "hierarchy" of agents: one simple one-shot LLM loop for every email and another in-depth for stuff that looks like a security report. But that felt like overengineering.<br>The approach I went with (I swear it was me, not Claude, who came up with this!): use labels as signal for the agent. So when the user receives something that looks like a security report, they'd just label it, and after a few minutes they receive a review in the same thread. Neat!

A mock inbox holds four emails: a vendor newsletter, a CVSS 9.8 RCE report from alex.sec.research@gmail.com, a domain invoice, and a recruiter intro. Applying the security-report label to the RCE email kicks off the pipeline: a cron job polls IMAP, finds the label, boots an OpenComputer sandbox, Claude reads the actual codebase, and a reply lands in the same thread with the verdict 'not a vulnerability'. The other three emails are never seen by the agent and no sandbox is spun up for them.

How will the agent get mail?

There are two very different ways to approach this, resulting in two very different agents.<br>One way is to give the agent its own inbox, so it'd only ever see the mail that's intended for it. Another is to have it access the full inbox, get notified of all messages (or pull via IMAP), but only process the labeled ones.<br>The first option is obviously better security / privacy. But I decided to go with the second one (against Claude's recommendation), mainly because I wanted to have less moving parts.<br>Pulling via IMAP was the simplest option: just need to have some sort of a cron job.<br>So at this point the solution shape is very clear, and I just told "let's build it" to Claude and stepped away for a few minutes.

Note on dev process

This has nothing to do with an email agent, but I want to share this anyways because someone might find this approach useful too.<br>Both Claude and Codex have a tendency to encourage you to stay in the thread and jump into building right away; I'm not sure why, perhaps engagement metrics look better this way. But I'm finding that this doesn't translate into the best or fastest outcomes.<br>An approach that I'm finding more useful is to iterate on a working / design markdown doc before shipping any code. You have to actively push it to do so: write an explicit instruction in AGENTS.md and also regularly tell it to write a working doc first. I keep them under .agents/work in the repo, and move to /done with final notes when done. Bigger pieces sometimes benefit from 2 or more levels: make a doc in /design first that's only about system design, iterate on it for a while, and then extract one or more working docs from it.<br>This agent though was small enough to fit into just one working doc. Here's the repo btw.

Keeping secrets secure

When Claude finished building, we ended up with just 2 moving parts:<br>A...