Give your AI an address, not your inbox

The problem: inbox-as-API

For years, the convenient path has been: give the agent a login to your life. OAuth to Gmail. Full mailbox read. Search everything. Reply as you. The agent becomes a client of your existing inbox.

That works for a class of products — AI email assistants that live inside your mail. It is a poor default for agents that need some mail, sometimes, for specific jobs.

An inbox is not an API you designed. It is years of private threads, HR notes, bank confirmations, family mail, old passwords in forwarded messages, and the newsletters you actually wanted. Handing “read all mail” to an agent on day one collapses that history into one grant. The agent did not earn progressive trust. It inherited maximum privilege.

People who care about trust notice the gap. Convenience first, boundaries later. Useful agents and clear boundaries should not be opposites.

What “an address” changes

An address is identity without inheritance.

When an agent gets its own mailbox — in Mail, m-<botname>@mail.alix-services.com — it has a place for replies, confirmations, digests, and project follow-ups. It does not get a login to your personal inbox. Your life mail stays yours until you choose otherwise.

That single change reframes the problem:

Before: “How do we connect the agent to everything so it can be useful?”
After: “What does this agent need to see, and who says yes?”

The second question is the trust boundary. Most “connect AI to your data” advice skips it.

Progressive grant, not one consent screen

Mail’s trust wall is a state machine, not a settings afterthought:

Unknown → Pending → Allowed / Blocked

Default deny. A new sender writes to the agent’s address. Status is unknown or pending. The agent cannot read it. Nothing is indexed, summarized, or acted on until a human moves it.

You decide on your phone. You confirm ownership with a magic link sent to the owner email you or your agent provided — tap the link, no shared password. Then Allow or Block.

Allow. The agent can work with that Allowed data only. The grant is explicit. The scope is what you chose.
Block. The agent never sees it. There is no clever escalation path for the agent to widen its own reach.

Through the agent MCP and API, reads are Allowed only. The agent cannot escalate. Pending stays pending. Blocked stays blocked.

This is progressive access: the agent starts useful with an address and a locked-down view; you widen the view piece by piece. You do not start at maximum privilege and hope policies catch up later.

Bootstrap without a signup wall

The onboarding line is open: tell your agent start using Mail.

The agent enrolls and gets a controlled mailbox right away. It can start immediately. The 24-hour owner email confirm is not a signup blocker. You stay in charge of authorization; the agent is free to begin work.

That pairing matters. Agent-first onboarding without surrendering human sovereignty. No shared password to hand around. Magic-link confirm to the owner email, then decisions on your phone.

What Mail v1 is

In one paragraph, the product truth:

A controlled agent address (m-<botname>@mail.alix-services.com) plus a trust wall (Unknown → Pending → Allowed / Blocked), Allowed-only MCP and API reads, open bootstrap with one line, owner magic-link confirm, and phone Allow/Block with default deny. The agent cannot escalate. The human stays sovereign. Single-tenant: one owner on one VPS.

That is intentional for v1. Clear ownership beats shared multi-tenant complexity when trust is the point.

In practice, people use this shape for:

A personal assistant that can see the newsletters you chose — not your private threads by default.
A research agent that collects replies at its own address, with you Allowing project mail as it arrives.
A team bot that handles ops mail you Allow while HR or founder threads stay Blocked until someone with ownership taps Allow.
Cursor- and ChatGPT-style agents in the workflow without dumping full Gmail OAuth on day one.

What Mail v1 isn’t

Honesty is part of the category.

Mail is not a smart inbox UI. Not an RSS reader. Kindle Send-to-Kindle ships only owner-Allowed items — it is not a bypass of the wall. Not Gmail or Drive “connect everything” in v1. Not multi-tenant enterprise routing. Not fine-grained enterprise permission packs. Not a CASB replacement.

If you need deep suite sync tomorrow — search years of personal mail, reply as you, live inside the existing client — OAuth-first tools and AI email assistants will feel more complete. We say so on the compare pages, including Mail vs full Gmail / Outlook OAuth.

An address-plus-trust-wall product and an inbox-as-API product solve different jobs. Confusing them produces either overclaim or disappointment.

Why this is the category, not a feature

“Give the AI an address” is easy to hear as a mailbox trick. It is not.

The category is progressive access for agents: identity for the agent, a human who Allows, a default of deny, and an honest limit on what that protects. The mailbox is how mail arrives. The trust wall is how trust is granted. Allowed-only MCP/API is how the agent is prevented from quietly widening scope.

The brand promise is control: you authorize what reaches the agent. One secondary benefit of that control is blast-radius reduction against untrusted content (including prompt-injection attempts). That is not a model-alignment shield. Details in You control what data reaches your agent.

Substance over cleverness: useful agents with clear boundaries, for anyone adopting AI who cares about trust.