I publish my security product's failures on purpose. Here's the bet.

After 18 years building software, I shipped my first solo product this week: Postfleet, email infrastructure for AI agents. Quick why, then the decision I keep second-guessing.

The problem: people are giving AI agents their own email inboxes. But an agent reading its inbox is a security hole — anyone who can email it can put instructions into its context. A well-worded email can tell the agent to ignore its rules or leak data, and it looks like normal mail. Postfleet sits in front of the agent: it screens for prompt injection, strips hidden text, and hands over structured data instead of raw prose.

Here's the part I want to talk about. Security products almost never show their failures. The incentive is to publish one big catch-rate number and bury the rest. I went the other way. I red-team my own filter with attacks written by Grok, Codex, and public datasets, and I publish the whole board: what it caught, what it missed, and the legit emails it wrongly flagged. "Screened, never immune" is the actual claim.

The bet is that for a security tool, transparency earns more trust than a clean number nobody believes. But it has a real cost. The page literally lists every time my product got beaten, and a skeptic can screenshot that. I go back and forth on whether it reads as rigor or as a liability.

So, a question for the IH crowd: when your product's credibility depends on honesty, how far do you take it? Have you ever published something unflattering on purpose, and did it help or hurt?

Free tier if you want to throw attacks at it: postfleet.ai. The scoreboard is at postfleet.ai/security.