The direct answer
Treat a recovery request as initiation, not permission to change or lock an account. A validated reset proof may authorize only the intended account’s password-reset workflow; require normal login afterward and handle existing sessions through an explicit supported policy. Neither a reset nor a new login automatically authorizes a queued AI action.
Choose a narrow recovery problem
A fictional AI console supports locally managed password accounts. Someone requests recovery for account AC-A while an old browser session and an approved export remain active. A single green “recovered” status would hide several different questions: was recovery merely requested, did a password change commit, what happened to existing sessions, and can that export still run?
This original worksheet addresses routine forgotten-password recovery only. It excludes federation, social login, MFA recovery and suspected compromise, which need separate assurance and recovery decisions. It selects no identity provider, password library or token format. All labels and decisions below are PROPOSED_UNRUN; no account, password, reset link or message was created.
Make unauthenticated initiation deliberately limited
The OWASP Forgot Password Cheat Sheet recommends consistent responses and timing for existing and nonexistent accounts, protection against excessive submissions, and no account change before valid proof. It warns against account lockout caused by forgotten-password abuse.
For this proposed console, the outward acknowledgement describes only acceptance of a recovery request. It does not confirm that an account exists, that instructions were sent, or that delivery occurred. Keep those operational outcomes separate. A generic sentence alone does not establish equivalent timing or eliminate enumeration through other behavior; those properties remain unverified.
Apply separately designed limits to request handling and possible recovery notifications. Limits must not become an unauthenticated password change, account disablement or login lockout. Exhausting a recovery allowance should constrain that recovery path, not grant a caller authority over AC-A. Exact thresholds, timing implementation and delivery controls need evidence for the selected system before deployment.
Bind reset-only permission to the intended account
OWASP calls for reset identifiers to be securely generated and stored, user-associated, expiring and single-use. It also describes restricted sessions that permit only password reset. This worksheet supplies no construction, storage or cryptographic recipe.
Invent a protected recovery record R-A associated with AC-A, purpose password_reset, recovery revision 5 and an explicit expiry. R-A is an inert reference to a future validated proof, not that proof itself. Account, purpose and revision come from trusted recovery state. Caller fields cannot reassign R-A to AC-B or convert it into an administrative login, connector enrollment or AI tool approval.
Before any password operation, require actual supported proof validation, the intended unused and unexpired association, and the application’s approved password policy. A plausible-looking identifier, a recovery-page visit or a familiar account label does not satisfy those prerequisites. Keep normal application access unavailable inside the reset-only context.
Define password commitment and session disposition separately
OWASP advises normal login after reset rather than automatic login. It allows either asking about invalidating existing sessions or invalidating them automatically. Those documented choices do not prove how any particular application terminates sessions.
For this fictional profile, choose automatic invalidation of the application-managed browser sessions after a confirmed password replacement. Record that as a required separate disposition, pending until the selected identity system supplies evidence. Do not expand it into a claim about OAuth grants, API keys, other devices’ credential types or already completed external actions.
The proposed local commit must coordinate R-A’s consumption, AC-A’s password replacement and its recovery-revision update through a supported mechanism. A separate “unused?” check followed by an unprotected update can race another submission. No database, identity SDK, password handling or atomic implementation is selected here; this is a design requirement, not proof of single-use enforcement.
If the commit response is unavailable, retain an unknown outcome. Do not mark R-A unused, roll back to an old password or automatically repeat the reset. Reconciliation must use the eventual identity system’s supported workflow. A notification about a confirmed change is also separate from proof that the password or session transition succeeded.
Review eight inert recovery cards
| Inert condition | Proposed disposition |
|---|---|
| Valid R-A for AC-A/revision 5; confirmed supported password commit and proof consumption | Report password reset; track required session invalidation separately; use normal login next |
| Initiation names an existing account versus an absent one | Use the same outward acknowledgement plan; claim neither existence nor notification delivery |
| Repeated recovery initiation exhausts its allowance | Limit recovery work/notifications without changing or locking the account |
| R-A is paired with AC-B or a login/admin/connector purpose | Deny substitution; no new identity or authority |
| R-A repeats, expires or no longer matches the current recovery revision | No new reset admission; consult its recorded disposition rather than arrival order |
| Password commit or credential persistence outcome is uncertain | Hold unknown; no automatic replay or unsupported completion claim |
| Password reset is confirmed but required browser-session invalidation is pending | Report the two outcomes separately; do not say all sessions ended |
| Normal login succeeds but the old export’s current permission is absent | Deny that AI action despite the new session |
The first card preserves a useful recovery path. It does not assume a valid reset restores a compromised account, proves mailbox ownership forever or confirms that every earlier credential stopped working.
Resume AI work through its own current boundary
After normal authentication, resolve the current account and workspace through trusted application state. Re-evaluate the exact pending operation, target, significant arguments and approval status. Do not transfer an earlier approval into the reset context or silently rebind old jobs to whichever account is now signed in.
For the export example, a confirmed password reset can coexist with revoked export permission. Conversely, a retained business approval does not demonstrate that an old browser session remains valid. Keep recovery, session state and exact-action authority as separate records with distinct evidence.
A future review should trace initiation, validated reset-only context, confirmed password change, session disposition and separately authorized continuation. Record minimized case and decision labels, not proof values, passwords or raw recovery requests. Uniform timing, secure credential handling and race behavior require separate authorized verification; this worksheet establishes none.
No reset, login, session invalidation, mail, provider/API or runtime fixture was performed for these cases. Boundary is prelaunch and does not claim a shipped authentication or recovery service. Its eight historical mock policy checks and separate synthetic JSON-export checks concern different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.