Deciding what reaches your agent in the first place

Most thinking about agent email is about what the agent sends. The cheaper lever is upstream: deciding what reaches it at all. An agent that never sees a message cannot answer it wrongly, cannot be injected by it, and cannot spend tokens on it.

30 July 2026 · 5 min read

Two modes, and which default is yours#

Inbound is filtered per identity, in one of two modes.

Blacklist mode, the default, lets everything through except senders you block. Correct for anything that has to hear from people it does not know yet: support, sales, anything with a published address.

Whitelist mode lets nothing through except senders you allow. Correct more often than people assume. A recruiting coordinator talks to candidates in your pipeline and your own panellists. A billing agent talks to customers with accounts. A test identity should talk to nobody but you. In each case the anonymous attack surface is not a trade-off you have to manage, it is one you can delete.

The rule to remember: an exact-address rule beats a domain rule. Block a whole domain and let one person through, or allow a partner domain and exclude one address inside it.

set_mail_rule { match: "domain",      value: "partner.com",           action: "allow" }
set_mail_rule { match: "exact_email", value: "noreply@partner.com",   action: "block" }

Setting the same match and value twice updates the action rather than stacking rules, so a rule set stays readable. The tools are in identities.

Getting real mail to a new agent without a redirect#

Almost nobody should point their published support address at a new agent on day one. Three gentler routes, in increasing order of commitment.

Forward one category. A rule in your existing helpdesk or mail client that forwards order status questions, or invoice replies, to the agent's address. Reversible in one click, and it is how most working deployments started.

Publish a narrow new address. orders@agents.yourcompany.com on your order confirmations only. The agent owns a category from the beginning and nothing else changes.

Move a published address across. The end state, and worth arriving at deliberately after a fortnight of reading threads, per the migration steps in moving an agent off the Gmail API.

What to keep out even in blacklist mode#

Some senders are pure cost with no upside, and blocking them is a one-line rule each.

• Your own agents. Put every agent address in the rules so a stray automation cannot start a conversation with itself. Two agents corresponding politely forever is a real failure mode, not a joke.
• No-reply addresses that nothing useful comes from.
• Notification floods from tools that copy an address on every event, unless the agent's job is reading them.
• Anything already known to be hostile. Blocking is cheaper than defending, though it is not a substitute for the architecture in prompt injection by email.

Filtering is not the same as ignoring#

A blocked message is a message somebody sent expecting an answer. Two habits keep that from becoming a silent hole.

Watch message.filtered webhooks, particularly on whitelisted identities. That event is the record of who tried to reach the agent and could not, and it is the earliest signal that your allow list is wrong or that a customer is writing to the wrong address. Details in webhooks.

And review the rules when the agent's job changes. Rules are written for the job as it was understood on the day they were set, and an agent that took on a new category last month is often still filtering out mail for it.

Routing to the right agent when you have several#

Route by address, not by content. One published address per function, each owned by one agent, is the arrangement that never produces two agents answering the same customer within an hour. Content-based routing between agents guesses, and guesses collide, as covered in running several email agents in one workspace.

Where a message genuinely arrives at the wrong agent, the fix is a forward with the thread intact rather than a clever rule: forward_email in wrapped mode keeps the headers and attachments, so whoever picks it up gets the original.

A rule set worth copying#

For a customer-facing agent, blacklist mode plus: your own agent addresses blocked, no-reply senders blocked, and anything a previous incident taught you blocked.

For an internal or pipeline-facing agent, whitelist mode plus: the domains it actually corresponds with allowed, individual exceptions blocked, and message.filtered watched for a fortnight to catch what you forgot.

For a test identity, whitelist mode with exactly the addresses you own on it, which is what makes replaying real threads safe, per test inboxes for agent development.

Questions#

Should an AI agent's inbox be a whitelist or a blacklist?

Blacklist for anything with a published address that must hear from new people. Whitelist wherever the counterparties are known, such as recruiting, billing, internal, and test identities, because it removes the anonymous attack surface entirely.

How do rules interact?

An exact-address rule beats a domain rule, so you can allow a domain and block one person on it, or block a domain and let one person through. Setting the same match and value again updates the action.

How do I send real mail to a new agent safely?

Forward one narrow category from your existing helpdesk, or publish a new address used for that category only. Both are reversible, unlike pointing your main support address at it.

What happens to mail a rule blocks?

It does not reach the agent, and a message.filtered event records the attempt. Watching that event is how you find out your allow list is wrong before a customer tells you.

Can two agents share one inbound address?

They should not. One address, one owner. Where a message lands on the wrong agent, forward it with the thread intact rather than adding content-based routing.

Should agents be allowed to email each other?

Generally no. Block your own agent addresses in the rules so a stray automation cannot start a conversation with itself, and exchange structured data in your own code instead.