Skip to main content
Say “log into GitHub” and the agent signs in for you. The first time it reaches a sign-in page it has no login for, it asks you, right there, in a masked prompt. After that it just works. Passwords are encrypted on this machine and injected straight into the page; the model never sees them. There is nothing to set up.

​
What it looks like

CLI / TUI
Desktop — a “Save your github.com login?” card with an identifier field and a masked password field. Save & sign in stores it and continues; Don’t save tells the agent to stop asking for this turn. From then on the agent lists your saved logins, types the identifier itself and fills the password through Mibyan. The tool result it sees is {filled_fields: 1, origin: "https://github.com"}; the password is also registered with the redactor so a later page read cannot echo it back.

​
Two-factor codes

Sites that ask for a code after the password are handled the same way:
  • Authenticator key saved with the login (the “setup key” or otpauth:// link a site shows when you enable 2FA; 1Password and Bitwarden items that hold a TOTP seed count too): Mibyan generates the current code and enters it. Nobody is asked. Add the key in Settings → Passwords & Logins → Add or mibyan vault add; the item shows a 2FA auto badge.
  • Code sent to your phone or email: a small prompt appears in your surface (“Verification code for github.com”), you type the code, Mibyan enters it into the page. The code never enters the conversation either.
  • Passkeys, hardware keys, app approvals (“tap Approve in Duo”): nothing to type. The agent tells you to complete it on your device and waits for the page to move on.

​
Already using 1Password or Bitwarden?

Nothing to enable. If the op or bw command-line tool is installed and signed in, Mibyan picks it up automatically and its website logins become fillable alongside the local ones. The first time the agent needs one of those logins it asks you to unlock the manager with your master password (masked prompt; once per session, 30 minutes idle). Mibyan hands the master password to the manager’s CLI through its non-interactive channel (op signin on stdin, bw unlock --passwordenv in the child’s environment) and keeps only the session token in memory. The agent never sees the master password, the token, or any login. A manager item that lists several websites (say amazon.co.uk, www.amazon.co.uk and eu.account.amazon.com) fills on each of those exact origins; nothing is inferred beyond the URLs saved on the item. Prefer not to use a detected manager? mibyan vault sources --disable bitwarden, or the switch in Settings → Passwords & Logins.

​
Paying and filling addresses

Cards and addresses work the same way as logins: saved once (Settings → Passwords & Logins → Add, or mibyan vault add), bound to the checkout site, and filled by the agent on that site only. Every card fill asks you first, with the same approval prompt as a dangerous command; declining writes nothing. Headless sessions (cron, webhooks, the API server) cannot confirm and are refused, so a prompt injection that reaches a checkout page can ask, but it cannot spend. Address fills need no confirmation.

​
Managing what’s saved

  • Desktop → Settings → Passwords & Logins: everything saved, the detected password managers with Unlock/Lock, Add, Remove.
  • CLI: mibyan vault list, mibyan vault add, mibyan vault rm <handle>, mibyan vault sources.
Items live encrypted under ~/.mibyan/vault/ (Fernet key + vault file, both 0600), scoped to the profile. Labels, site origins and login identifiers are visible metadata; passwords and card values never leave the vault except into the page.

​
Headless sessions

Cron jobs, webhooks, the API server and mibyan chat -q have nobody to answer a prompt. Saved local logins keep working there; a locked password manager reports unavailable_in_this_session and a missing login reports prompt_unavailable. Unlock or save from an interactive session first, or give 1Password a service account token (OP_SERVICE_ACCOUNT_TOKEN).

​
What this does and does not guarantee

Does: the password never enters the model’s context through Mibyan: not in tool results, logs, the session database, or the CLI arguments of any process. Fills happen over the supervised browser session’s direct CDP socket and are refused unless the page origin exactly matches the saved origin, checked again inside the page immediately before the write. Does not: protect against the page itself. Once a password is typed into a site, that site (and any script it runs) has it, exactly as when you type it yourself. On a cloud browser backend the vendor’s browser sees the page like any other. The origin binding is the guard against filling on the wrong site, not against a compromised right one.