Unsigned macOS credentials: user-authorized use without repeated confirmation

[SarthakWade]

Problem

Unsigned macOS builds currently require Touch ID, the macOS account password, or trusted native confirmation for every saved-credential use. Some users accept the additional risk and want to authorize password use once, then let an agent use a selected account alias without repeated operating-system prompts.

This is not automatic account selection and does not expose the password. It removes the per-use confirmation after an alias has been selected.

Proposed setting

Add an advanced native setting:

Credentials
[ ] Allow saved credentials without confirmation

Required behavior:

• Off by default.
• Readable and writable only through the native macOS Settings UI.
• Not readable or writable through CLI, MCP, protocol configuration commands, environment variables, defaults commands, or page content.
• Enabling requires successful Touch ID or macOS account-password authentication.
• Disabling is immediate and does not require authentication.
• Store the authorization policy as protected Keychain state, not ordinary UserDefaults.
• Explain that an agent may infer the setting from the absence of a confirmation prompt even though it cannot query or modify the value.
• Require reauthorization after reinstall, broker replacement, signing-identity change, or another executable-identity event defined by Credential security design: threat model and broker contract #154.
• Do not enable this setting during migration, upgrade, restore, or import.

The UI should call this Allow saved credentials without confirmation, not silent autofill, because Headless still requires account selection unless a separate default-account policy is designed later.

User flow when disabled

1. Headless returns AUTH_REQUIRED with aliases matching the exact authentication origin.
2. The agent asks the user which alias to use.
3. The user selects an alias.
4. The agent submits the alias and challenge ID.
5. macOS requests Touch ID or account-password authorization.
6. Headless fills and submits only after approval.

User flow when enabled

1. The user enables the setting in native Settings and passes Touch ID once.
2. Headless later returns AUTH_REQUIRED with origin-matching aliases.
3. The agent asks the user which alias to use.
4. The user selects an alias.
5. The agent submits the alias and challenge ID.
6. Headless fills and submits without another operating-system prompt.

Existing valid login cookies bypass both flows because no new credential use is required.

Security tradeoff

The password remains unavailable to the agent, page, logs, flows, snapshots, and command output. Origin, challenge, iframe, expiry, private-context, and redaction checks remain mandatory.

The compromise is authorization provenance: after confirmation is disabled, Headless cannot prove that an alias in a tool call originated from the human rather than the agent or prompt-injected content. Exact-origin binding limits the affected credential set but does not eliminate this risk.

An unsigned build also lacks stable Apple-verified identity. This feature must not be described as equivalent to a Developer ID build or as protection against malicious same-user processes, browser-process compromise, binary replacement, root, or administrator access.

Scope decision

The design must decide whether authorization applies globally or only to individually approved origin and alias pairs. Per-origin approval is recommended. If global authorization is supported, the UI must present a stronger warning and list every account that becomes usable without confirmation.

Acceptance criteria

• The setting cannot be queried or changed through any agent-facing surface.
• Enabling always invokes Local Authentication and fails closed on denial, cancellation, lockout, or unavailable authentication.
• Tests prove defaults, enable, disable, restart persistence, reauthorization, and executable-identity invalidation.
• Tests prove agents, pages, private contexts, defaults manipulation, environment variables, and malformed IPC cannot change the policy.
• Credential use retains exact-origin, challenge, iframe, expiry, audit, and redaction protections.
• The native UI explains the unsigned-build risk and the difference between account selection and credential confirmation.
• Capabilities report only whether user presence is currently required, without exposing or mutating the underlying setting.
• macOS E2E covers both user flows.

Blocked by #154, #156, #157, and #158.

[yashranaway]

Skip this.

We're not paying for Developer ID right now, and without a stable Apple-signed identity this toggle is how an agent or a prompt-injected page spends work or personal with no human in the loop. Per-use Touch ID is the product for unsigned builds, not a temporary inconvenience.

Revisit only after we actually sign with Developer ID. Notarization by itself should not turn this on.

[yashranaway]

Decision 24 excludes this from the unsigned product. Do not implement. Revisit only after a real Developer ID identity exists, in a new architecture decision. Notarization by itself does not turn this on.

[yashranaway]

Still skipped. Unsigned macOS builds keep per-use Touch ID or account-password confirmation. No silent fill, no agent-writable policy, no Apple Developer Program spend for this.