Who gets your password? What AI agents ask you to hand over

Of the 65 agents in this directory, 19 say what they are actually given when you connect an account. Thirty-three publish a privacy policy and never answer the question, and the thirteen that connect nothing at all are the only ones with a good excuse.

The answers that do exist are not variations on a theme. They are six different arrangements, and the gap between the loosest and the tightest is the difference between handing somebody your house keys and letting them in while you watch.

The problem has a specification, and it is fourteen years old

This was solved, on paper, in October 2012. RFC 6749 defines OAuth 2.0, and its first page is a list of what goes wrong when a third party holds your password rather than a token. Read it with an agent in mind:

Third-party applications are required to store the resource owner's credentials for future use, typically a password in clear-text.

Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.

Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party's password.

Compromise of any third-party application results in compromise of the end-user's password and all of the data protected by that password.

Every one of those is a description of what a personal agent is. The fix is a token: scoped to a subset, limited in duration, revocable from the provider's side without touching the password, and useless outside the scope it was issued for.

So the first question for anything on this site is whether it has read the standard, and 13 of 65 have. That is the largest single answer and it is the floor rather than the ceiling.

Six answers, loosest first

The password. One listing states it may be handed the real thing. Instinct's policy says you may provide "your username and password for third-party accounts so that the personal assistant can sign into these accounts on your behalf". That is the arrangement RFC 6749 was written to end, running inside a product valued at $2.5B. What else Instinct publishes about itself is counted separately.

A one-time code. Shuffle takes the verification code when a task needs one, keeps it only as long as the task runs, and states it is never used for training. Better than a password, because it expires. Worse than it looks, because a code handed to software is a second factor that has stopped being a second factor.

A session you opened yourself. Two listings never touch the password at all. Flip texts a link, you sign in on your own phone with whatever two-factor or passkey the site uses, and only the session comes back: "Your password, passkey and one-time codes stay between you and the website." Pally says the same in different words and adds the part Flip leaves implicit, that the browsing provider is what holds the session afterwards.

This is a real improvement and a session is still not a token. A session cookie is a bearer credential, and RFC 6750 is blunt about what that means: "Any party in possession of a bearer token (a 'bearer') can use it to get access to the associated resources."

Two things follow. It was issued after the login succeeded, so it is already past the two-factor step the design was so careful to preserve. And revoking it means ending a session on a settings page most people never find.

A scoped token. Thirteen listings use OAuth and say so. The best of them describe the shape instead of the acronym: Dunnit puts "we never see your password" on its front page next to a note that you can remove access from Google in one tap, and Orchid states that deleting your account revokes the tokens within 72 hours.

A surrogate, never the secret. Muse keeps its credentials inside the per-user virtual machine, not in central Meta infrastructure, and describes a component whose job is "credential surrogation so your main agent never sees sensitive credentials". Kernel, the browser infrastructure two listings here already name, shipped the same idea for cards on the day this piece went up: the agent works with an alias and the real credential is substituted only as the request leaves the sandbox.

A vault you hold. OpenInstinct is an iMessage assistant and a password vault in one repository, running in your own Vercel account, with secrets encrypted before they touch the database and an instruction to verify that by reading the code. It is the strongest answer available and the only one that costs a Sunday to set up.

Why a token is not the end of it

The interesting part is that the two organisations that thought hardest about this both went past OAuth rather than stopping at it, and they did it separately.

Meta says why in the same document. Muse, it writes, "provides fine-grained control over exactly which actions the agent can take on behalf of the user beyond the coarse groups that are usually exposed as OAuth scopes". That is an argument about the standard, and it is unusual to see one in a security write-up.

OAuth scopes were designed for an application whose behaviour a reviewer can read. An agent's behaviour is decided at runtime by whatever it is told, including by a web page it visits. A scope that says read and send mail covers the message you wanted and the one it was talked into.

Instinct's own policy names that risk out loud, in the section about security: it warns of "interactions with third parties who may include misleading instructions intended to influence autonomous agents". It is the only privacy policy here that mentions prompt injection, and it belongs to the one listing that says it may be holding your password when it happens.

What is not known

Nobody has published what an agent did with a credential after something went wrong. On 10 September a named founder and former investor reported giving Instinct a Verizon login and then receiving an authentication request from Tehran, posted the screenshot, deleted the product and said the company had not replied. Nothing public establishes what caused it, this piece does not claim Instinct was breached, and the correction goes on that listing with the same weight if an explanation arrives. One account is a lead.

The other unknown is bigger and duller. Thirty-three listings have a privacy policy that never mentions the question, and several of those connect Gmail, a calendar or a bank. Connecting Google is OAuth whether a policy says so or not, because Google offers nothing else. What the silence hides is everything Google does not cover: the sites an agent signs into on your behalf, where those sessions are held, and who else can reach them.

What to watch

The first is whether any provider ships delegation designed for agents instead of for apps. Meta has said the scopes are too coarse and built around them privately. A public standard for a grant that expires with a task, or that can be constrained by intent rather than by endpoint, would move every listing here at once.

The second is whether the surrogation pattern spreads below the products. It has already appeared twice in a week, once inside the largest company here and once in the infrastructure underneath several others. If it is the right answer it will show up in a subprocessor table before it shows up in a launch post.

Last is the count at the top of this page. 19 of 65 is a fact about what companies choose to publish, and not a measure of how careful they are, and it is the cheapest of all of these to change. Saying which of the six you use costs one sentence, and the products that already say it did not become less safe by doing so.