Should an AI agent ever see your passwords?
No. An AI agent should not read, store, or be pasted a password. Sign in yourself in the browser or app that owns the session. Let the assistant work only inside that session, with limits you can see and a stop you control. If a product needs the secret in the prompt, do not use it for that job.
Should you ever type a password into a chat?
A password in a message is a secret in a log. Chat histories are copied, summarised, indexed, and sometimes trained on. Even if a vendor says the turn is private, you have already given the model text it can repeat, leak in a later reply, or expose if the account is shared. The same applies to one-time codes, recovery phrases, API keys, and the answers to security questions.
The safer pattern is the one you already use with a browser: you type the password into the site’s own form. The assistant never sees the characters. If a workflow cannot start until you paste a secret into the model, that workflow is asking you to treat the model as a password manager. It is not one. Use a dedicated manager, or sign in by hand and only then ask for help.
What is the difference between a session you started and a stored secret?
A session is a short-lived proof that you already authenticated. Cookies, device tokens, and OAuth grants live in the client you control. You can end them by signing out, revoking the app, or closing the device. A stored secret is the password itself, a refresh token with no expiry you understand, or a dump of cookies copied into a file the model can read.
Handing over the secret lets anyone with that text impersonate you on every device until you rotate it. Lending a session you started keeps the proof on your machine and lets you cut it without changing the password. Prefer the second. If an assistant needs ongoing access, use a connector or OAuth app you can revoke from the service’s own security page, not a password sitting in chat memory.
- Session you started
- You signed in on a device you hold. The assistant may act only while that login lasts, and you can end it without rotating the password.
- Named-site grant
- A login scoped to one service, issued by that service, which the model uses as a token it does not display or quote back.
- Password in the prompt
- The secret itself is in the conversation. Treat it as compromised and change it.
- Stop you control
- A sentence, a button, or a revoked grant that immediately ends further actions, including queued ones.
How can an assistant act on a site without reading the password?
The usual design is: you authenticate in a window the vendor does not scrape for keystrokes. The site issues a token bound to one named app. Tools then call APIs with that token. The model sees tool results (inbox subject lines, calendar slots), not the password field. That is still powerful, so the token should be least privilege: send mail, not change recovery email; post a draft, not delete the account.
GROX describes connectors that act inside tools you already use, such as email, chat, social, and calendars, from one conversational surface. That still does not require the password in the chat. If a product cannot explain which grant it holds, which site it is for, and how you revoke it, do not connect it. A simpler path is often better: stay signed in yourself and copy the finished text across by hand.
| Method | What the model can see | What you should do |
|---|---|---|
| You paste the password | The secret and anything later in the thread | Do not; rotate if you already did |
| You sign in; it uses the open tab | Page content you already loaded | Watch the tab; sign out when done |
| OAuth or connector to one named site | Tool outputs, not the password form | Revoke from the site’s app list |
| Shared mailbox or bot user | Whatever that identity can read | Prefer a role with no billing access |
What should you check before letting any assistant act while you are signed in?
Check the identity it is using: yours, a bot user, or a connector. Check the scope: read, send, spend, deploy. Check confirmation: does it ask before a send, a payment, or a public post? Check the stop: can you pause with a sentence or a click, and does a stop apply to work already queued? Check the log: can you read what it did in ordinary language, not only a raw API dump?
Also check memory. Persistent memory is useful for tone and unfinished tasks; it is dangerous if it keeps secrets, private thread titles, or recovery codes. Tell the assistant, in plain words, never to store credentials. Prefer tools that keep keys on their side of a sandbox and never in the workspace files. GROX Code, for example, is described as routing model calls through GROX so a single-use sandbox never holds a provider key — that is a pattern to look for, not a reason to paste passwords into chat.
When the job is a one-off email or a single spreadsheet, a simpler tool is the better choice: the site itself, a password manager’s autofill, and you at the keyboard. Reach for an agent when the work spans several tools and you can still see every confirmation.
- Never paste passwords, seed phrases, or one-time codes into chat.
- Sign in yourself; revoke grants from the service, not only from the assistant.
- Require a confirm before send, spend, or publish.
- Keep a stop that does not wait for the model to finish a thought.
- Read the action log; if you cannot, do not leave it unattended.
Common questions
Is it safe to paste a password into an AI chat if I delete the message afterwards?
No. Deleting the bubble does not reliably erase copies in logs, backups, or model context. Treat anything typed into chat as durable. Sign in on the real site instead, then delete nothing because nothing secret was there. If you already pasted a password, change it on that service and enable a second factor you do not keep in chat.
Can an AI agent use a login on one named site without ever reading the password?
Yes, if you authenticate in the site’s own form or an OAuth screen and the agent only receives a scoped token. The model should not echo that token. You should be able to revoke the app from the site’s security settings. If the product instead asks you to type the password into the conversation, that is not this pattern and you should refuse.
What should I review before an assistant acts in a session I already started?
Confirm which account is signed in, what the assistant is allowed to send or change, and whether it must ask before irreversible steps. Confirm you can end the session without help. Watch the first few actions yourself. Prefer a dedicated bot user with no billing rights over your primary login. If you cannot see a log in plain language, do the task by hand.
When is a simpler tool better than an agent for signed-in work?
When the task is one message, one file, or one transfer you can finish in a minute. The site’s own compose box, a password manager, and your eyes beat an agent that might over-share context. Use an agent when work crosses several apps and every spend or send still needs your say-so. Convenience is not a reason to put a password in a prompt.
Read how GROX routes work through connectors on Home and the Help Centre; keep passwords out of the chat either way.