Secure project-scoped credential profiles for preview-browser test logins

[jpden81]

T3 Code agents can drive the collaborative preview browser, but authenticated development testing stops when a fresh session requires a password or private deployment-bypass URL.

Today preview_type accepts literal text. Supplying a credential would therefore expose it across the model/tool boundary. Reusing browser cookies is useful but does not provide autonomous recovery after logout, expiry, or profile reset.

Would the maintainers be open to a provider-neutral Browser Credential Profiles capability for development and test environments?

Proposed smallest useful scope

• Desktop-only and experimental initially.
• A host-local setup dialog stores a test login once.
• Non-secret metadata contains the profile label, project, environment classification, login route, allowed origins, and available field names.
• Secret values are protected by the operating system's secure-storage facilities.
• Agent-visible tools receive only an opaque profile ID and named field.
• The server derives the requesting environment, project, thread, and browser host; the agent cannot supply or override that authorization context.
• The Electron main process on the browser-host machine resolves the secret and performs the sensitive operation.
• Production-classified profiles are unsupported in version one.
• Older desktop hosts fail closed through the existing preview-operation capability handshake.

For a password, the sensitive operation must be atomic: lock the target tab, revalidate the live top-level origin and frame, suspend recording/snapshots/evaluation, resolve the secret locally, fill it, immediately submit or clear it, and only then release the tab. Returning while the password remains readable in the DOM would allow another browser operation to extract it.

A possible agent-visible shape is:

browser_credential_list()
preview_use_credential(profileId, field, locator, submit)

The result would contain only a coarse state such as succeeded, credential-invalid, origin-not-allowed, profile-expired, vault-locked, or unsupported-host.

Private deployment-bypass URLs need a distinct operation. They must not be sent through ordinary preview_navigate, the renderer, the visible address bar, snapshots, network diagnostics, action history, or browser history. If Chromium/Electron cannot provide that guarantee, secret navigation should remain out of scope rather than fall back to literal navigation.

Security invariants

• Secret values never enter model context, MCP payloads, RPC contracts, server logs, telemetry, crash reports, screenshots, recordings, snapshots, action history, clipboard history, or tool results.
• Profiles are bound to a stable T3 project identity and exact normalized origins.
• Identity-provider origins are separately approved.
• No wildcards, iframe injection, production override, or fallback to literal typing in version one.
• A per-tab lease prevents redirects, parallel agents, snapshots, evaluation, or recording from racing the sensitive operation.
• Audit events contain only profile ID, project, origin, operation, time, and coarse result.
• External providers such as Infisical, 1Password, or Bitwarden would be future adapters behind an internal provider interface—not dependencies of preview automation.

The current architecture appears to offer useful seams:

• PreviewAutomationBroker already pins a provider session to one physical desktop runtime.
• Preview hosts already advertise supported operations for version-skew handling.
• Desktop already has an ElectronSafeStorage abstraction and protected Linux-backend selection.
• PR #7083 established a user-controlled global gate for agent browser access.

Before proposing code, guidance would be appreciated on:

1. Does a development/test-only Browser Credential Profiles capability fit T3 Code's direction?
2. Should resolution and protected execution live entirely in Electron's main process on the selected preview host?
3. Should the first implementation extend the existing Electron safe-storage abstraction or introduce a dedicated credential-vault interface?
4. Should the first slice support password fill-and-submit only, with secret navigation considered separately?
5. Would maintainers prefer one narrow desktop end-to-end slice or staged contract, vault, browser-operation, and UI changes?
6. Which maintainers should approve the threat model and browser-host trust boundary?

I have a concrete non-production use case and would be willing to contribute after the maintainers choose the boundary. Any implementation would use sentinel test credentials and include negative leakage, malicious-redirect, origin, concurrency, locked-vault, and version-skew tests.

[jpden81]

Exploratory implementation report

I built the complete vertical slice in a contribution-only fork to test the boundary before asking maintainers to review a PR. This is deliberately not an upstream PR and uses no real credentials.

• Branch: https://github.com/jpden81/t3code/tree/feat/secure-browser-credentials
• Commit: jpden81@9b196ff
• Threat model and limitations: https://github.com/jpden81/t3code/blob/9b196ff0756a103fe3226438a7a97bddb39cd6ef/docs/internals/browser-credential-profiles.md
• Size: 32 files, 2,495 insertions, 34 deletions

What the prototype implements

• New typed credential metadata/write/delete contracts and three opaque-reference browser operations: list profiles, fill a named credential, and consume a secret URL.
• The server mints the canonical environment/project binding into the MCP preview session. The agent cannot provide or override the project authorization context.
• Electron main owns a dedicated credential registry backed by safeStorage. The registry refuses Linux basic_text, writes mode 0600, returns metadata only, and redacts secret-bearing schema/provider errors.
• Profiles are bound to the canonical project, development or staging classification, exact normalized origins, expiry, and consent. Production profiles are rejected.
• Password use enters protected browser state before resolution, acquires a global credential lease plus the target-tab lock, blocks screenshots/recording/PiP/evaluation/console/network diagnostics and parallel automation, revalidates the live top-level origin immediately before fill, rejects iframes/non-password fields, fills and optionally submits, clears the password, then releases protection.
• Secret URLs use a separate operation. Electron consumes the URL through the browser session fetch path and loads only the public login URL into the webview; redirects are checked against exact approved origins. The secret URL is never returned to the renderer, server, MCP result, or visible browser history.
• Settings > Integrations > Browser contains an Electron-only experimental profile manager with create, edit, rotate, and confirmed-delete paths. Secret inputs go from the local renderer directly to Electron main over IPC and never through the T3 server.
• Older or non-desktop hosts fail closed through the existing preview-operation capability handshake. There is no literal-text fallback.

Proof completed

• 137 focused tests pass across 8 contract/server/web/desktop test files, including project spoofing, unsupported-host behavior, exact-origin enforcement, malicious redirect rejection, iframe rejection, protected-state suppression, concurrency, locked/insecure vault behavior, redacted errors, secret clearing, and deletion.
• Focused typechecks pass for contracts, server, web, and desktop.
• Web production build and server bundle build pass.
• I launched the desktop app against a disposable T3 home and created a profile using obvious sentinel values. The saved card exposed only the label, environment, public login URL, field purposes, and origin count. The vault registry was mode 0600, neither sentinel appeared anywhere under the isolated T3 home, metadata could be edited without re-entering secrets, and confirmed deletion removed the profile.
• The branch contains no Nexus usernames, routes, provider keys, passwords, or private URLs.

Pitfalls the implementation exposed

1. Fill alone is unsafe. Returning control while the password remains in the DOM lets a later evaluate/snapshot operation recover it. The protected interval must extend through immediate submit or cleanup.
2. Project scope cannot be an agent argument. The project binding has to come from the provider-session/runtime binding and survive session recovery; older sessions without that binding must fail closed until restarted.
3. Tab locking is not enough. Recording, screenshots, DevTools-style diagnostics, evaluation, and a second tab/agent can race the operation, so the prototype adds a host-wide credential semaphore plus per-tab protection.
4. Secret navigation is not normal navigation. Loading the private URL in the webview would leak it to history and UI. The fetch-and-sanitize approach is promising, but cookie persistence through session.fetch still needs a packaged Electron integration test against a disposable fixture before it should ship.
5. JavaScript cannot guarantee memory zeroization. The value can be kept out of serializable contracts and discarded quickly, but immutable JS strings make a strong zeroization claim dishonest.
6. OS vault behavior is platform-specific. macOS was exercised. Windows Credential Manager and Linux Secret Service, including locked/unavailable/corrupt states, still need real-host validation. Linux basic_text is intentionally unsupported.
7. Production detection cannot be inferred from naming. The prototype structurally disallows the production environment classification, but origin classification remains an explicit owner responsibility.
8. Remote routing needs host identity, not server locality. Resolution belongs on the exact desktop runtime selected by the preview broker. Web/mobile may request use later, but should not receive or configure secret values without host-local confirmation.
9. Audit and consent need an explicit product decision. This slice implements coarse last-use metadata and operational support only for always-for-project; ask-each-time and once fail closed. A durable local audit ledger and trusted prompts are not yet implemented.
10. Absence of leakage needs packaged assurance. Unit/integration tests cover captured channels, but crash reporting, delayed diagnostics, telemetry hooks, and packaged browser artifacts need sentinel-based end-to-end assertions.

Suggested upstream shape

My current recommendation is a smaller first upstream slice than this exploration branch:

1. desktop-only experimental password fill-and-immediate-submit;
2. dedicated internal vault/provider seam, not a public plugin API yet;
3. canonical project binding and exact-origin policy;
4. protected host operation with fail-closed capability negotiation;
5. profile UI plus negative leakage tests;
6. defer secret navigation until the packaged cookie/history behavior is proven.

If this direction fits T3, could a maintainer confirm the preferred ownership boundary and PR shape? I can then split or reduce the exploratory branch to match that direction rather than sending the full prototype unsolicited.