Give your browser agent its own email inbox

Browser agents fill forms the company already has a right to fill: a vendor console you are provisioning, a trial on a product you are evaluating, a sandbox the customer asked you to configure. Those flows send one-time codes and verification links to email. If the agent is using a person’s inbox, you have created a shared secret and an audit mess.

Give the browser agent its own Agent Inbox. Isolate inboxes per session or tenant. The agent reads mail that belongs to that signup. A human still confirms high-risk actions: password changes, payment, production DNS, deletion. This is vendor verification the company owns — not a playbook for evading anyone’s terms of service, not a recipe for bulk signups, not a way to hide identity.

Inbox per session or tenant

Create the mailbox when the browser session starts, or reuse a stable inbox per tenant if the vendor account is long-lived:

from agentinbox import AgentInbox
client = AgentInbox()
inbox = client.inboxes.create(username="browser-acme-trial", domain="agentinbox.space")

Name usernames so you can delete them when the session ends. Do not recycle an inbox across two customers. OTP mail is credential-adjacent. Treat it like a secret with a short TTL.

Wire MCP or the SDK into the browser agent the same way you would for a coding agent. The browser runtime clicks; the mailbox runtime reads. Keep those permissions separate. A browser tool that can also send mail is a confused deputy.

Read codes, do not improvise identity

When a vendor the company is actually signing up for sends a code, the agent lists recent threads, finds the matching sender, extracts the code, and types it into the form it already has open. Prefer copying a verification link only when the vendor requires a click-through and the link is clearly bound to that signup.

Do not use this pattern to create accounts you are not authorized to create. Do not use it to bypass rate limits, phone checks, or abuse controls. Do not write steps for phishing, credential stuffing, or scraping inboxes you do not own. The legitimate case is enough: your cloud, your SaaS, your customer sandbox, your evaluation.

If the message is unexpected — a bank, a government portal, a password reset you did not start — stop. Forward into Neuro OS. A person decides.

Humans confirm high-risk actions

Even on an owned signup, the agent should pause before: adding a payment method, inviting other users, changing an owner’s email, enabling production webhooks, or granting OAuth scopes. Those are Ask gates in Neuro OS, or a blocking confirm in the browser runner.

Sends from the agent inbox default to Ask. Browser agents should rarely send mail at all. Their job is to receive verification and continue the owned form. If they must ask a vendor a question, draft it.

Isolation and cleanup

Destroy or freeze session inboxes when the evaluation ends. Revoke MCP access for that run. Do not leave OTP history attached to a shared “qa@” mailbox. Log which role requested which vendor signup, with a ticket or change record.

Forwarding into Neuro OS is the escape hatch when the page is confusing, the mail is ambiguous, or the vendor requires a legal click. The browser agent is a pair of hands. The mailbox is a scoped address. Authority stays with a person.

That is the whole integration: one inbox, one session, owned vendors, Ask on anything that spends money or changes identity.

Agent Inbox gives each role a mailbox people can reply to, with forwarding into Neuro OS when a human must see the thread. Outbound mail defaults to Ask. Run the role on Neuro OS. To scope the first inbox, get started.

Explore Neuro OS →