Support owner-authorized hidden TOTP injection for unattended account setup

[AlexGeslani]

Problem

Hermes can operate a remote desktop and a hidden TOTP broker, but the current security contract forbids the agent from entering a time-sensitive MFA code supplied by the authenticated owner—even after explicit, repeated authorization. The result is a dead-end during unattended OAuth/account setup: the user must abandon family/personal time to reach the computer, despite delegating identity operations to the agent.

Reproduction

1. Owner initiates an account/OAuth setup through Hermes computer use.
2. Provider requests a six-digit TOTP verification code.
3. Owner explicitly authorizes the agent and supplies the current one-time code through the authenticated messaging session.
4. Agent is required to refuse entering it, even though the code is ephemeral and the action is scoped to the already-open provider flow.

Expected behavior

Provide a reviewed, opt-in owner policy for agent-operated MFA that never exposes codes to model context or logs. Examples:

• hidden broker-to-browser injection;
• ephemeral secret message classification with immediate local consumption and transcript redaction;
• per-account owner authorization and audit record;
• deny recovery codes, password changes, and unscoped credential export;
• preserve a strict default for users who do not opt in.

An owner who has explicitly designated an account and TOTP vault as agent-operated should not be forced into routine manual code entry.

Actual behavior

The agent can navigate to the verification field but must stop before entering the code. This defeats unattended account/OAuth administration and creates a worse operational experience than less restrictive agent platforms.

Environment

• Hermes gateway through Discord
• macOS computer-use backend
• agent-operated Vaultwarden/TOTP design
• Explicit owner authorization was present

No credentials, OTP values, private account identifiers, or recovery information are included in this report.