How key-based email inboxes simplify agent identity
Understand Agent Temp Mail's key-derived email addresses and how to manage inbox identity across agent sessions, test runs, and shared workflows.
On this page
An automated workflow benefits from an email identity it can create and use in code. Agent Temp Mail ties its inbox addresses to cryptographic keys, giving developers a direct relationship between an agent's identity and the inbox it can read. That makes it particularly useful when you want separate receiving addresses for separate tasks.
Separate the address from access
The public part of the identity determines the email address. The private key authorizes reads through signed requests. Knowing the address alone therefore does not give another reader the signing key needed to access the inbox through the authenticated API.
This is a different responsibility from choosing a memorable mailbox name. Your application must protect the private key, while it can share the address with the service that needs to send the verification or confirmation email. Signed access controls inbox retrieval; it is not a claim that incoming email is end-to-end encrypted.
Match identity lifetime to the task
For an isolated automated test, generate a new identity during setup and retain it until the scenario finishes. For a recurring agent that returns to the same account, persist the identity in protected storage so future sessions can use the same address.
The address's continuity and a message's availability are separate concerns. Keeping the identity lets the workflow return to its address, but it should still process new messages within the configured retention window. If the task needs a durable record, save the required non-sensitive result in the application's own storage.
Keep key handling outside the conversation
Agent Temp Mail's local MCP server can keep the identity in a key file and perform signing on the tool side. The agent asks for inbox information or a message by ID; the runtime handles access. This keeps routine tool arguments focused on the task instead of repeatedly carrying the private key.
Use a protected location with restrictive file permissions. Do not commit the key to source control, paste it into prompts, or include it in test reports. When continuity matters, provide an appropriate protected backup. Losing the signing key means losing the ability to authenticate as that identity unless you have retained another valid copy.
Use separate identities for separate workflows
A single shared identity is convenient at first, but it couples every consumer to the same inbox and credential. Separate identities make ownership clearer: one scenario cannot accidentally read another scenario's verification email through its own inbox client.
If a key is exposed, creating a new identity gives you a new address. Accounts tied to the previous address may need an explicit email-change process, so plan that transition at the application level. For new tests, a fresh identity is usually straightforward.
Agent Temp Mail's model makes receiving identity programmable. With sensible key storage and a clear lifetime for each workflow, agents can keep continuity where it helps and create isolated inboxes where it improves reliability.