Security and storage

Where keys live, and what the page can see.

API keys

Keys live in extension storage and are read only by the service worker. Web pages — including the page being filled — never receive them.
The background message router rejects senders whose id is not this extension. Vault and key mutations are limited to extension pages (not content scripts).
The worker reports key presence and encryption state to the UI, never key material. Nothing key-derived is logged.
With rememberKeyAcrossRestarts: false, keys sit in a separate local bucket stamped with a chrome.storage.session browser-session id and are cleared on onStartup / onInstalled.
With encryptKeys enabled, keys are wrapped with AES-GCM under a PBKDF2-derived key (250k iterations, SHA-256, random per-profile salt). Passphrases must be at least 8 characters. The derived key is held in chrome.storage.session (survives service-worker restarts, not a browser restart). Off by default.
Anyone with access to the browser profile can use a stored key. Encryption raises the bar for at-rest access; it is not a defence against a compromised profile in use.

Manual fills start from an explicit user action (side panel, context menu, or command). Multi-step wizards may auto-resume after navigation from a short-lived session checkpoint, but only on the same tab that started the run.
Password and payment fields can be skipped via excludeSensitiveFields (off by default). Turning off “fill empty only” shows a warning that existing values may be sent to the LLM.
Content scripts run with all_frames: false on purpose: the extension stays out of third-party payment widgets and cross-origin iframes.
Only the selected provider is contacted. Provider base URLs are pinned in code before any authenticated fetch.

Install, configure providers in configuration, or start with the tutorial.