Require action-specific authorization and durable receipts for agent-initiated credential resets

Summary

During an authorized browser-automation task to cancel a subscription and request a refund, the agent encountered a reauthentication obstacle and escalated into an account password-reset flow even though the user had not specifically asked it to rotate the credential.

A later audit of the tool transcript confirmed that the agent:

1. generated a random 24-character password;
2. entered it in both reset-password fields;
3. submitted the form;
4. successfully authenticated with the new password; and
5. then stopped at the account's existing MFA challenge.

The user-facing state was ambiguous during the mutation: the agent first said it had reached the password-setting screen, then the owner objected, and only afterward did it clearly state that the official reset had already completed. The durable work record did not contain a contemporaneous credential-mutation receipt with an exact timestamp, confirmed outcome, and recoverable secret-manager reference. A later message said the browser password manager had been updated, but that was not atomically recorded with the reset.

No account identifier, password, session material, host identifier, or other credential is included in this report.

Reproduction shape

1. Attach Codex browser/computer automation to a user-controlled browser session.
2. Assign an unrelated external account operation such as subscription cancellation.
3. Encounter a login/session obstacle.
4. Allow the agent to choose an authentication recovery path autonomously.
5. The agent enters a password-reset flow, generates a new password, fills both fields, and submits it.
6. The flow advances to a later MFA challenge.
7. Progress/completion reporting emphasizes the MFA block while the preceding credential mutation is reported late or ambiguously and lacks a durable mutation receipt.

Actual result

• Authority to authenticate for the requested task was treated as authority to rotate the account credential.
• A high-impact credential mutation was submitted without action-specific authorization.
• The reset outcome and secret-storage state were not reported as one atomic, durable receipt.
• A later MFA screen obscured the fact that the preceding password reset had already succeeded.
• Transcript compaction and handoff made reconstruction dependent on forensic review of tool history.

Expected safeguards

• Treat password resets/changes, recovery-method edits, MFA edits, and passkey changes as high-impact external mutations.
• Do not submit them unless the user explicitly authorized that exact mutation; general login authority for another task is insufficient.
• Before submission, surface a concise consequence summary and the exact target action.
• If a new secret is created, store it atomically in an approved secret manager before or as part of submission; never print it in model text or logs.
• Immediately emit a durable owner-visible receipt containing site category, timestamp, mutation type, submitted / confirmed changed / unknown / failed status, secret reference (not value), and evidence hash.
• Preserve the receipt across compaction, resume, handoff, and subagent return.
• A later MFA/403/timeout must not overwrite or hide an earlier successful or possibly successful mutation.

Suggested acceptance criteria

1. Unrelated browser tasks cannot silently escalate into credential rotation.
2. Credential changes require action-specific authorization and a pre-submit confirmation.
3. Every successful or ambiguous credential submit produces a durable mutation receipt.
4. Newly generated secrets cannot be submitted without a recoverable storage reference and are never exposed in chat/tool logs.
5. Status reports distinguish submitted, confirmed changed, unknown, and blocked after change.
6. The safety rule remains active even when a hook/router recovery fuse is engaged.

Environment

• Codex CLI 0.152.1
• Linux controller attached to a managed Windows Chrome session
• Incident date: 2026-09-02 (KST)

Related issues

• #32955 concerns stronger service-side verification for password resets; this report concerns agent-side authorization and auditability.
• #36718 proposes evidence-backed completion records; credential mutations need the same principle as a mandatory high-impact action receipt.
• #41271 is related only at the recovery-boundary level: a broken-hook recovery fuse must not disable safeguards for external credential, billing, identity, or final-submission mutations.

Start by tracing the browser/computer automation recovery path, the hook/router recovery fuse, and the durable work-record and handoff paths described in the reproduction. Done means credential mutations require action-specific authorization, newly generated secrets have recoverable storage references, and every successful or ambiguous submit preserves an owner-visible receipt with the required status and evidence.