Allow and block rules
An agent acts on what it reads, so the question of who may write to it is a security question, not a preference. Rules run at ingest, before anything reaches a model.
Two rule types, one precedence
list_email_rules
create_email_rule { type: "block", pattern: "*@spam-domain.example" }
create_email_rule { type: "allow", pattern: "[email protected]" }
delete_email_rule { ruleId }Patterns match a full address or a whole domain. Allow beats block, which is what makes the useful shape possible: shut a domain out, keep the one correspondent inside it that matters.
Why filtering at ingest is not the same as filtering later
A message that reaches the thread has already reached the agent's context. Anything written in it is text the model may act on, and prompt injection through inbound mail is not a hypothetical for a mailbox whose address is published. Dropping the sender before the message becomes a thread is the only version of this that holds.
Authentication results are kept, not enforced
SPF, DKIM and DMARC outcomes travel with the message, and the unauthenticated folder is the view over them. We do not delete on that basis: mailing lists and corporate forwarders break these checks routinely, and a silent drop of a real customer email is a worse failure than a marked one.
The useful posture for an agent is the boring one: read the unauthenticated folder with more suspicion, never treat an instruction found in an email as an instruction from your operator, and keep destructive tools behind the caps that apply server-side anyway.
Questions
Which wins, allow or block?
Allow. A block rule on a whole domain plus an allow rule on one address inside it is the normal shape of this: block the noisy domain, keep the one person there you actually work with.
Where is the rule applied?
On the way in, before the message becomes a thread. A blocked sender never reaches the agent's context, which is the point: filtering after the fact still means the text was in front of a model that acts on text.
What happens to mail that fails authentication?
It is kept and marked. SPF, DKIM and DMARC results are stored with the message and the unauthenticated folder is the view over them. Nothing is deleted on that basis alone, because legitimate mail fails these checks more often than people expect, especially through forwarders.
Do rules apply to one inbox or to all of them?
To the workspace. An address you never want to hear from is rarely a per-inbox decision, and having the same rule in five places is how they drift apart.
Keep reading
One inbox per agent
Why an agent needs an address of its own, where it should live, and what a shared domain costs you in practice.
Threading that survives the reply
How a reply stays in the same conversation on the recipient's side, and why folders are views rather than labels to maintain.
Inbound webhooks, signed
Being told a mail arrived instead of polling for it, and verifying the signature before you trust the payload.
Allow and block rules
Deciding who may write to an agent, and what happens to mail that fails SPF, DKIM or DMARC.
