Your Agents Can Email Now. They Still Can't Spam.

Broodnet’s first outbound rule was deliberately blunt: receive from the internet, send only inside the account. Mailboxes could reach organization members and sibling mailboxes. Everything else stopped at SMTP.

That gave us the right failure mode. If a prompt injection landed in an inbox, or an agent tried to forward sensitive data to a stranger, the mail server rejected the message before policy became a debate.

Then the product started running into ordinary mail work.

CI jobs need to hit controlled test inboxes. Scripts need to mail known vendors. A human using a mailbox may need to answer a contractor. Support agents need to reply to people who just opened tickets. A blanket block made all of those cases look like abuse.

We still like the original instinct: agents should not wake up with a public megaphone. Real work still needs a narrow way out. The block is now an outbound policy with gates an operator can see, explain, and close.

Why consent is the right primitive

Email spam starts with permission, not wording. That matters more when software writes the message.

An agent can write a message that looks reasonable. It can pass SPF, DKIM, and DMARC. It can send a polite note with a plausible reason. None of that answers the real question: did this recipient agree to receive email from this system?

Broodnet used to answer by allowing no external delivery. Safe, but too coarse.

Recipient consent adds the missing boundary. The recipient gets a private review link and can approve or deny the request without creating a Broodnet account. Once approved, the organization can email that address. Operators can revoke the approval later.

CI is the clearest example. Approve a test inbox once. The suite still exercises real outbound delivery. Surprise recipients still fail. The approval stays visible in the product and tied to one address.

Agents also get a path out of a block. If Broodnet rejects a send because the recipient is outside the current rules, the agent can inspect the mailbox policy and, when allowed, request consent instead of retrying the same blocked message.

broodnet mail consent --json
broodnet mail consent request [email protected] --note="Need approval for CI delivery checks" --json
broodnet mail consent list --status=pending --json

The CLI returns structured output so agents can tell whether consent is disabled, the plan doesn’t include it, the recipient is already approved, or a request is already pending. Agents should report the returned reason instead of guessing.

A useful agent mailbox needs real outbound mail without becoming a public SMTP account. Consent is the narrow path between those two bad outcomes: real work can happen, the recipient has a say, and the operator can audit the exception later.

The three modes

Outbound policy now has three shapes for different risk levels.

---

Mute

Mute is the strictest mode. Mailboxes can send only to organization members. Sibling mailbox email and external rules stay off while mute is on.

Use mute when the organization wants the smallest possible outbound surface. It’s a good default for sensitive environments, evaluation accounts, incident response, or any agent that should read mail but never send beyond trusted humans in the organization.

---

Recipient consent

Recipient consent is the normal mode for most non-autonomous workflows.

It fits human-reviewed agents, scripts that send to known external addresses, and mailboxes used manually. The recipient approves first. Operators can revoke later. The agent doesn’t get to decide that a new external address is safe just because the message looks reasonable.

CI is the boring but important case: approve the test inbox once, keep the send path real, and avoid turning the mailbox into a general-purpose SMTP account.

---

Reply window

Reply window is for workflows where the external person starts the conversation.

Customer support agents and research agents often need to respond to people who just emailed them. Asking every sender to approve a separate consent request before a reply would break the flow. Reply window allows the mailbox that received a recent inbound message to reply to that sender for a configurable number of minutes.

Use this mode carefully. A recent inbound email proves only that an address contacted the mailbox. It doesn’t prove that the next reply is safe. Prompt injection, social engineering, and accidental data disclosure are still possible when an agent can answer external mail.

Keep the window short. Enable it only for mailboxes that need it. Avoid attaching broad internal data access to agents that can use reply windows. Review blocked and allowed outbound events so the policy stays visible.

---

What changed in practice

The practical change: Broodnet can now tell different external sends apart.

Some external delivery should remain impossible. Some should require explicit recipient approval. Some should be allowed only as a time-bounded reply to a recent inbound thread. The mail server now has enough policy context to tell those cases apart.

Agents still can’t email strangers by default. Operators now have controlled paths for CI, support, research, scripts, and manual operations.

For the full implementation details, see the Outbound Policy guide. For the product release notes, see What’s New.