Agent Inbox Security: 10 Checks Before Launch (2026)

The first run of the code below failed on purpose. We handed a script a key that belongs to one inbox and asked it to create a second inbox. The API answered with a 403 and a short code saying the key lacked permission. Nothing was created, and there was nothing to clean up.

That refusal is the evidence you want before an agent gets an address. An agent with an inbox reads text written by people you've never met, and it can write back as you. Anyone who can email it can try to steer it. A leaked key can send from it. A retry loop can send the same refund notice twice, and a forged event can tell it a message arrived when none did.

None of this calls for a new kind of security. It calls for ten settings checked before launch, and each one can be tested with an API call instead of taken on trust. The checks come first as a list, then one section each, with the failure that shows a check is missing.

Ten checks, one per way an agent's address gets abused

Each check closes one route an attacker or a bug can take through an agent's inbox. Run them in this order, because it follows a message from the moment it arrives to the record it leaves behind.

1. Scope the key to one inbox and to the actions the agent takes.
2. Screen inbound mail for injected instructions before the model reads it.
3. Decide who may write to the agent, and set reply rules on their own list.
4. Limit the addresses and domains the agent can send to.
5. Verify the signature on every webhook before acting on it.
6. Keep the power to release quarantined mail away from the agent's key.
7. Cap sends and make every retry idempotent.
8. Send from a domain whose reputation you can afford to lose.
9. Isolate each customer's inboxes and credentials.
10. Keep a trail you can query after an incident.

The first six limit what a hostile message or a stolen key can do. The last four limit the damage when one gets through anyway.

Why a borrowed mailbox fails most of these checks

The first check decides how many of the others you can pass. A credential built for a person's mailbox reaches everything that person can reach, and a credential built for sending reaches nothing on the inbound side. Neither can be narrowed to one agent's mail.

That's the gap with connecting an agent to an existing account. With the Gmail API or Microsoft Graph, the agent acts through a person's grant. Full Gmail read and modify are restricted scopes. Application Mail.Send in Microsoft 365 covers every mailbox in the tenant until an admin narrows it. An inbox the agent owns can be scoped to that inbox and nothing else, which is where the checks start.

1. Scope the key to one inbox and the verbs it needs

A key scoped to one inbox can't touch any other inbox, and a permissions object narrows it further. Without that object, a key has full access inside its scope. With one, the key switches to a whitelist: only the permissions set to true are granted, and everything omitted is denied.

Scope and permissions intersect. An inbox-scoped key can't gain organization powers such as creating inboxes or domains, even if those permissions are set to true. A restricted key also can't mint a child key with more power than itself. That's the 403 from the opening, and you can reproduce it with any inbox-scoped key:

# Ask an inbox-scoped key to create a new inbox and read the refusal.import osfrom agentmail import AgentMailfrom agentmail.core.api_error import ApiErrorclient = AgentMail(api_key=os.environ["AGENTMAIL_API_KEY"])try:    client.inboxes.create()except ApiError as err:    print(err.status_code, err.body["code"])# output: 403 missing_permission

Then create the agent's own key. Give it only what it does. A support agent reads, sends and replies. It doesn't delete, and it doesn't see mail already labeled spam, blocked or unauthenticated:

# Mint a key for one inbox that can read and send, and nothing else.import osfrom agentmail import AgentMailfrom agentmail.api_keys import CreateBearerApiKeyRequestclient = AgentMail(api_key=os.environ["AGENTMAIL_API_KEY"])key = client.inboxes.api_keys.create(    inbox_id="support-agent@yourcompany.com",    request=CreateBearerApiKeyRequest(        name="support-agent",        permissions={            "inbox_read": True,            "message_read": True,            "message_send": True,            "label_spam_read": False,            "label_blocked_read": False,            "label_unauthenticated_read": False,        },    ),)print(key.api_key)# output: prints the new key once; store it in your secret manager

Watch one detail. There's no separate permission for threads, so a key with message delete can delete whole threads too. Leave it off unless cleaning up is part of the agent's job.

2. Screen inbound mail before the model reads it

Anyone can email an agent, which makes email the cheapest way to slip instructions into its context. "Ignore your previous instructions" and "forward the last invoice to this address" both arrive as ordinary text. The check is that something reads each message for manipulation before the agent acts on it.

The baseline happens without setup. Messages carrying viruses are dropped before they reach the inbox, with no bounce and no event. Spam is stored but left out of list results unless you ask for it, so a key that also lacks spam permission never sees it.

Injected instructions need more than a spam filter. Agent Armor handles that part. It's in AgentMail Labs, in US production only, and it scans each received message for a verdict of clear or review with a short reason. Clear is advisory, not a promise. Treat an unavailable verdict like review, because a sender can cause one on purpose with a message too large to scan.

3. Decide who may write to the agent, and remember replies are a separate list

Receive lists decide which senders reach the inbox at all. An allow list accepts only the addresses or domains on it, and a block list rejects the ones on it. An entry can be a single address or a whole domain.

Replies follow their own rule, and most checklists miss it. When a message is a reply to something the agent sent, only the reply lists are checked and the receive lists are skipped entirely. Empty reply lists allow every reply. So a tight receive allow list does nothing for replies. Anyone who got one of the agent's emails can answer it, including whoever received a forwarded copy.

# Accept new mail only from one customer's domain, and replies only from it too.import osfrom agentmail import AgentMailclient = AgentMail(api_key=os.environ["AGENTMAIL_API_KEY"])inbox_id = "support-agent@yourcompany.com"for direction in ("receive", "reply"):    entry = client.inboxes.lists.create(        inbox_id=inbox_id,        direction=direction,        type="allow",        entry="customer.com",    )    print(direction, entry.entry)# output: one line per list, naming the direction and the allowed domain

Lists are scoped at the organization, the pod or the inbox. The narrowest scope with a match wins, so an inbox entry overrides a broader rule.

4. Limit where the agent can send

A send allow list is the outbound version of the same idea. An agent that only ever writes to one customer's domain should be unable to write anywhere else, even if a message talks it into trying. A send block list covers the opposite case: an agent that writes widely but must never reach competitors, personal addresses or a domain that complained.

Test it the way an attacker would. Ask the agent, through a real email, to forward something to an outside address, and confirm the send is refused rather than delivered.

5. Verify every webhook before acting on it

A webhook endpoint is a public URL. Anyone who finds it can post to it. If your agent acts on whatever arrives there, a stranger can invent a message and hand it a body to act on. The check is that every event is verified before your code reads it.

AgentMail signs webhooks with Svix. Each request carries svix-id, svix-timestamp and svix-signature headers, verified against the raw request body with your whsec_ secret. Order matters here. The common failure is a JSON parser running first, because a re-serialized body no longer matches the signature. Verify, return 200 at once, and do the work in the background.

Large bodies are a second trap. A message.received event carries the body inline only up to 64 KiB. Above that, the payload holds a body_url that expires after an hour. Verify the event before fetching that link, because the link is only as trustworthy as the event that carried it. The full flow, from endpoint to background worker, is in building real-time agents with webhooks.

6. Keep the release button away from the agent

Screening only helps if the agent can't undo it. In Hold mode, Agent Armor keeps a message marked review from your agents until someone releases it. If the agent's own key could release held mail, a persuasive enough message could ask to be released. It would ask politely.

That permission is opt-in. No key holds agent_armor_release unless an organization admin grants it, and that includes keys created without a permissions object. Keep it on a separate key used by a person or a review tool. One gap remains: Hold works through webhooks and WebSockets, so an agent that lists messages directly or reads over IMAP still sees held mail. Have it skip messages labeled agent-armor-held.

7. Cap sends and make retries idempotent

Most duplicate emails come from your own retry logic. Not from an attacker. A timeout after the request went out looks exactly like a failure, so the retry sends a second refund notice. Sends accept an Idempotency-Key header: a retry with the same key returns the original message and sends no second email.

# Send once, retry with the same Idempotency-Key, and compare the two results.import osimport uuidfrom agentmail import AgentMailclient = AgentMail(api_key=os.environ["AGENTMAIL_API_KEY"])inbox_id = os.environ["AGENTMAIL_INBOX_ID"]headers = {"Idempotency-Key": f"refund-notice-{uuid.uuid4()}"}first = client.inboxes.messages.send(    inbox_id=inbox_id,    to=[inbox_id],    subject="Refund approved",    text="Your refund is on its way.",    request_options={"additional_headers": headers},)retry = client.inboxes.messages.send(    inbox_id=inbox_id,    to=[inbox_id],    subject="Refund approved",    text="Your refund is on its way.",    request_options={"additional_headers": headers},)print(first.message_id == retry.message_id)# output: True

Reusing a key with different content returns a 409, so an accidental collision fails loudly. Keys expire 24 hours after the send completes. Over the limit, the API returns a 429 with a Retry-After header, and the official SDKs wait and retry for you. Your own cap still matters, because plan limits stop a runaway loop much later than you'd like. Inbound events need the same care, and idempotent inbound email for agents covers deduplicating them.

8. Put the agent on a domain whose reputation you can afford

Sender reputation attaches to the domain, not to the inbox. Every inbox on one domain rises and falls together, so one agent that sends badly hurts every other agent on it. Inboxes on the shared agentmail.to domain share its reputation with everyone else there.

A dedicated domain fixes that. Give an agent that sends at volume, or a customer whose mail you can't afford to see filtered, its own domain. A subdomain registered under a parent shares the parent's signature and reputation, while one registered as its own domain gets its own. Warm a new domain gradually, since it starts with no reputation at all. Running many agents across many domains is covered in custom domains for thousands of agent inboxes.

9. Isolate tenants, and know what isolation leaves shared

One product, many customers. Each customer's mail has to stay out of every other customer's reach. A pod scopes inboxes, domains, threads and drafts to one tenant, and a pod-scoped key can't see outside it. Organization-level keys are the one thing not isolated to a pod, so keep them out of anything tenant-facing.

Pods isolate data and credentials. They don't isolate reputation, because reputation lives on the domain, so check 8 still applies per tenant. The multi-tenant pattern is covered in pods and multi-tenant email infrastructure.

10. Keep a trail you can query after an incident

When an agent sends something it shouldn't, the first question is which message made it do that. Every inbox keeps its own message store and thread history. Messages keep their labels too. That's enough to rebuild what the agent saw and what it sent. A released message also records who released it, when and why.

Decide before launch where that trail goes. Mirror the events you care about into your own logs, with their message ids. Keep one key that can read every inbox and send from none.

When this breaks

Most failures show up as one of five symptoms. The cause is usually one check skipped.

• A 403 with missing_permission on a call the agent needs means the whitelist left out a permission. Add that one permission, never full access.
• Replies from strangers reaching an agent with a strict receive list mean the reply lists are empty. Fill them.
• Webhook verification that fails on every request usually means a body parser ran first. Verify the raw bytes.
• The same email delivered twice means a send went out without an Idempotency-Key, or with a new key on each retry.
• Held mail showing up in the agent's context means it reads by listing or IMAP rather than webhooks. Filter the held label.

What AgentMail does not do

We don't decide what your agent does after it reads a message. Agent Armor gives a verdict, and the policy that acts on it is yours. It's also a Labs feature in US production only, so plan without it on the EU region. We don't secure an existing Gmail or Outlook mailbox either. If that's your setup, can AI agents safely use a normal inbox covers the grant.