Look at what a web service actually does with an email address and it turns out to be four jobs at once. The address is the account's unique key, since most sign-up forms refuse an address that is already registered. It is proof of control, because the service sends a code or link and waits for it to come back. It is the recovery channel that password resets go to, and the place receipts, security alerts and policy notices are sent.
An API key or OAuth token identifies a program to a service that was built for programs. Most of the web was built for people and identifies them by email. An agent that has to use that web needs an address that can do all four jobs, and each one has consequences for how you create, keep and retire agent inboxes.
One address, one account
Because the address is the unique key, ten agents sharing one address can create one account between them. The second sign-up fails with "email already in use", or worse, the second agent resets the first one's password. Plus-addressing tricks depend on each service treating name+1@ and name+2@ as different people, which not all of them do.
Separate inboxes solve it directly. In Lumbox, POST /v1/inboxes returns a new, deliverable address in one call, so an agent that needs an identity creates one rather than borrowing one. The same call answers the proof-of-control job: the inbox receives the verification email and parses the code or link out of it on arrival, and GET /v1/inboxes/:id/otp hands the code back.
Whoever reads the inbox owns the accounts
The recovery job has a consequence that is easy to miss. Every account registered with an address can be taken over by anyone who can read that address's mail, because a password reset is one email away. Read access to an agent's inbox is therefore equivalent to the credentials of every account the agent created.
Treat the API key that reads the inbox accordingly. A Lumbox organization key can read every inbox in the organization. A project key can only reach the inboxes in its project and is refused on organization-level routes, so a component that should see one agent's mail should get a project key for that agent's project, not the organization key.
The account passwords themselves can live next to the address. POST /v1/credentials stores a secret under a service and identifier (typically the agent's address) with envelope encryption: a per-organization data key, wrapped by a master key, AES-256-GCM. POST /v1/credentials/use returns the plaintext to a key with the credentials:read scope, and for a stored TOTP secret, POST /v1/credentials/totp returns the current six-digit code and its expires_in. That means the key with that scope can read every stored secret, which is one more reason to hand narrow keys to anything that does not need the vault.
An identity has to outlive the task
Accounts do not end when a task ends. If an agent signs up for a data provider on Monday and uses it for six months, its address has to keep working for six months, because the provider will send a new-device code, a billing notice or a reset to it at some point. Lumbox inboxes never expire on their own; they last until you call DELETE /v1/inboxes/:id.
Deletion needs more care than it looks. Deleting the inbox does not delete the accounts registered with it. They stay at each service, and you lose the ability to recover them. On the shared trylumbox.com domain, an address becomes available again once its inbox is deleted, so a stranger who later creates the same address would start receiving that account's resets.
Two habits close that gap. Give account-holding agents addresses that nobody would guess: omit name and local_part and Lumbox generates one, or add a random suffix to a readable name. For agents whose accounts matter, use a custom domain. An inbox on a custom domain can only be created by an organization that has added that domain and verified it to ACTIVE status, so a deleted address on your domain cannot be claimed by another Lumbox customer.
The sending half of identity
When the agent writes to a person, the recipient decides who it is from the From domain and from whether the message passes SPF, DKIM and DMARC. On trylumbox.com, the agent shares a domain, and the domain's reputation, with every other Lumbox user; that mail goes out through Amazon SES. On your own domain, the agent sends as your company and the reputation is yours to build or lose. POST /v1/domains returns the verification TXT record plus the MX, SPF, DKIM and DMARC records to create, and POST /v1/domains/:id/verify checks them. Shared vs dedicated sending domains covers that trade in more detail.
A record of what the identity did
An agent with its own address leaves an audit trail on both sides. Each service holds a record of an account tied to that agent, not hidden behind a developer's personal address. On the Lumbox side, the inbox keeps every message received and every message sent through the API (stored with category outbound), and nothing expires. GET /v1/inboxes/:id/emails?category=verification is a close approximation of "every service this agent has signed up for". The inbox's metadata object, set on create or with PATCH /v1/inboxes/:id, can record who owns the agent and what it is for, and labels on individual messages can mark what the agent did with them.
What an email identity does not prove
An address proves that someone controls a mailbox. It says nothing about who operates the agent or whether a person is behind it, and services know that. Many add phone verification or CAPTCHAs on top of email, and some refuse shared or disposable domains at sign-up. Lumbox flags part of this: parsed.requires_browser is true when a verification link points at a CAPTCHA or challenge page. The agent still has to get through it. Why AI agents can't sign up goes through the other obstacles.
For agents that will hold long-lived accounts, the custom domain setup in the domains docs is the step to do first, and the credentials docs cover storing the passwords that go with each address.