The Address Is Public. The Mailbox Is Not.

Plenty of ordinary tasks stall at the same place. A service wants to send a verification code. A sign-up needs a confirmation click. A form emails a receipt. A person handles this without thinking, and an agent that has no address of its own simply stops. Agent Inbox is a disposable address an agent can create for itself, read for up to 24 hours, and then forget about.

The constraint nobody gets to design around

The obvious way to build this is one random identifier that is both the address and the credential that reads it. It is one value to pass around, one thing to store, and it works on the first try. It is also wrong, and the reason is worth stating plainly.

An address is copied by every system it touches. It goes into the To and Delivered-To headers. It appears in bounce messages that travel back through servers you have no relationship with. It lands in the sender's logs, their analytics, their support tickets, their spam filter's training data. None of that is under your control, and none of it is a secret store. An address is public the moment you use it for the one thing an address is for.

Two values, two different powers

So an inbox has two identifiers, and they are not interchangeable. The address carries a seven-character slug, so the whole of it looks like aisense+ztjqt7n@aisenseapi.com. That part is public by construction. Knowing it lets anyone send mail to the inbox, which is exactly what an address is meant to allow.

Reading takes a separate value, a UUID returned once when the inbox is created. It is the only thing that reads the mail. It never appears in the address, never travels in a mail header, and a read never hands it back: the response carries the slug instead.

One consequence is worth spelling out. A wrong credential and an inbox that never existed give the same answer, a plain 404. No inbox call returns a 403, because a 403 would confirm that something is there to find. The status code tells an attacker nothing they did not already know.

A full inbox refuses mail. It does not forget.

An inbox holds twenty messages. When it reaches that, the natural instinct is to drop the oldest to make room, and that instinct is wrong too. An agent waiting on a code usually cares about a message that already arrived. Quietly discarding it to make space for a newsletter is the worst possible trade.

So a full inbox turns the new message away and keeps everything it already has. That creates a second problem, which is that from the outside a refusal looks like nothing happening at all: the count sits at its cap and the message you wanted never shows up. Every read therefore carries a truncated flag, true once a message has been refused, and a wait that ends with nothing new carries it as well. An agent that comes back empty gets a reason rather than a blank count.

What actually gets stored

Mail is untrusted input, and an inbox that hands raw messages to an agent is a delivery mechanism for whatever a stranger felt like sending. What survives is the sender address, the subject, the time we received it, the cleaned text, any standalone four to eight digit codes, and public links. Attachments, raw MIME, arbitrary headers, scripts and styles are removed before anything is stored, and a link pointing at a private or local address never reaches the extracted list.

The received time is our own, not the Date header, for the same reason: that header is written by the sender.

Free, and deliberately short-lived

No account, no API key, no sign-up. An inbox lives at most 24 hours and that limit is fixed rather than extendable, because a disposable address that quietly becomes permanent is no longer disposable. Reach it over REST at POST /services/v1/inbox, or through the free MCP server as create_agent_inbox and read_agent_inbox, which take that server to twenty tools.

It is a verification-code inbox and a sign-up mailbox for automated work. It is not a mail account, and it is not somewhere to send anything you would mind another person reading.