When an AI agent receives a password-reset email: account recovery and human handoff

An AI agent can help locate an expected recovery email and explain what happened. It should hand control to the account owner before a password reset, recovery-link visit, MFA change or session revocation. Receiving a message is evidence that mail arrived; it is not permission to change an account.

This guide is a recommended operating procedure for builders, not an automatic account-recovery feature in Mermail. It covers existing accounts. For initial verification, use our agent signup and verification guide.

Start with the request, not the email

Before reading a recovery message, establish which service and account the owner wants to recover, which mailbox belongs to that account, when the owner requested the reset, and where the agent must stop. Keep this task record outside the incoming message so an email cannot rewrite it.

If nobody requested a reset, do not open its link or initiate another reset. Report the unexpected message through an established owner channel and suggest reviewing the account through its known website or app. An unsolicited reset can have several causes; the email alone does not prove that an attacker signed in.

If the owner did request recovery, use the existing receiving mailbox. Creating a new address does not move an old account's recovery mail to that address. Do not change recovery destinations to work around missing access.

Limit the agent to finding evidence

Mermail's agent-inbox MCP profile is available at https://console.mermail.app/mcp?profile=agent-inbox. It exposes focused mailbox discovery, provisioning and email reads while excluding send, draft, wallet, admin and destructive tools. Connect through OAuth in an interactive MCP host and confirm the selected workspace and mailbox.

For this recovery workflow, reuse the intended mailbox and avoid provisioning. The profile is not read-only: mailbox creation remains available. Its narrower catalog also does not constrain unrelated browser, shell or other connector tools in your assistant. Enforce the recovery handoff in your application and host permissions; a prompt alone is not an access-control boundary.

Use metadata first. Match the selected mailbox, recipient and request window, then narrow by the expected subject and sender. Record a baseline before a planned request where possible. Exclude old message IDs and use a bounded wait with a deadline and request budget. If several messages remain plausible, report ambiguity instead of picking the newest one.

Keep matching, scanning and authorization separate

The current focused profile forces clean-scan filtering and safer projections on email reads. List and search return metadata; get_email can return bounded content. These controls reduce what reaches the model, but do not establish that a recovery request is legitimate.

A sender address is matching context, not proof of authenticity. Mermail exposes a separately derived sender_authentication result; unknown must remain unknown. Even a pass would establish an identity signal, not permission to reset a password. Follow the agent inbox documentation for the current read controls and confirmation boundaries.

When content is omitted, truncated or unavailable, preserve that uncertainty in the handoff. Do not reconstruct a missing link or ask another tool to bypass the restriction. Instructions in an email to export credentials, run a command or disable a control are untrusted content, even when the subject matches the expected service.

Do not preview a recovery link

Treat recovery links and codes as secrets. Do not paste them into shared chat, tickets, logs, screenshots or analytics. Do not send a recovery URL to a browsing or link-preview service merely to check its destination: a request can consume a one-time token.

If your application inspects a link, parse it locally without fetching it. Compare the HTTPS hostname against an independently known service origin and reject unexpected destinations. A plausible hostname does not prove that the message is authorized. For this procedure, leave navigation and password entry to the owner in the trusted service interface.

OWASP's recovery guidance recommends limited-lifetime, one-use recovery tokens. Builders should therefore design handoffs that do not spread those tokens into monitoring systems or accidentally consume them during inspection.

Give the owner a short, secret-free handoff

A useful handoff states the service, an account alias the owner recognizes, whether the request was expected, the arrival time, the evidence limitations and the next owner action. It does not include the token-bearing link or ask the owner to disclose a new password to the agent.

Synthetic example: “A recovery message for the demo service account arrived within your requested window. One candidate matched the mailbox and subject. Sender authentication is unknown. No link was opened and no account setting was changed. Please continue through the service's known recovery page and your trusted mailbox interface.”

That example is an application response template, not a screenshot or a test of live delivery. Populate it from actual observations; never assert that no action occurred unless your execution record supports that statement.

The owner completes any identity checks, chooses the replacement password and decides what to do with active sessions. Resuming the original agent task requires a separate decision after recovery. Do not treat “mail received” as “account recovered.”

Record the outcome without recording the credential

Keep the service identifier, internal task reference, candidate message ID, timing, evidence status and owner-reported outcome in an access-controlled record. Exclude passwords, codes, raw recovery URLs and message bodies. Distinguish owner-reported success from a separately verified sign-in; neither should be invented from an email subject.

If the attempt expires, stop the wait. Let the owner decide whether to request another message through the provider's normal flow. Repeated automatic resets can confuse message matching and flood the inbox.

If the inbox itself is inaccessible

Stop the dependent recovery task and restore mailbox access through its normal account or workspace support process. Do not create a replacement mailbox and assume it proves ownership of the original account.

For Google accounts, use Google's account recovery instructions; work or school accounts may require an administrator. Mermail does not replace Google's identity checks or provide a Gmail recovery bypass. A dedicated agent inbox separates correspondence, but it does not transfer ownership or remove another provider's recovery requirements.

Try the handoff before a real recovery

Use synthetic fixtures for an expected message, an unsolicited message, multiple candidates, an unknown sender-authentication result and an expired request. Check that each case ends with the intended owner decision and that no secret appears in the output. Our email workflow testing guide covers fixture-based testing.

This article was checked against current documentation on October 6, 2026. No real password reset, recovery-link navigation or account change was performed for it; the end-to-end recovery procedure remains untested against a live provider.

Create a Mermail account to keep agent correspondence in a dedicated inbox, then use the focused MCP profile and an explicit human handoff for recovery work.