The login your agent is borrowing
In plenty of marketing and data teams this autumn, an AI agent is probably working on somebody’s personal password. It was the quickest way to get a demo running. The person meant to swap it for something cleaner, and then the quarter happened. Last month the largest US banks decided they would no longer wait for that swap.
According to Linas’s weekly fintech edition of 1 November, JPMorgan, Bank of America, Citi, Schwab and Wells Fargo restricted outside agents between 13 and 16 October, and Morgan Stanley has restricted them too. The moves came weeks after Meta’s Muse agent, launched on 8 September, passed 10 million users, most of them shopping with it. From 24 November, Wells Fargo will treat actions taken by an agent holding your credentials as your own. Under Regulation E, a transfer made by someone you gave your access to generally does not count as unauthorised, even when that someone goes beyond what you allowed. An earlier Linas piece on Meta’s Q3 call reports that Meta has accepted that merchants and banks will set the terms for the next phase of agent commerce.
What the banks are actually sorting
The useful part is where the banks drew the line. Agents that log in with a shared password are on their way out, the same way screen scraping went. Agents that identify themselves and hold scoped, revocable tokens get in slowly. JPMorgan and Citi allow read-only access, Schwab runs a trading pilot, and no bank yet lets an outside agent move money on its own. Bank of America’s Brian Moynihan wants a person authorising any money that leaves an account. Mercury already works that way, with agents requesting payments that a human then approves.
That same week, the tooling moved in the opposite direction. Vercel Labs open-sourced agent-desktop, which lets coding agents operate apps on macOS, Windows and Linux by reading the accessibility tree instead of guessing from screenshots. Both The Code and AlphaSignal covered it on 2 November. In its 31 October issue on always-on agents (Muse, OpenAI’s dots, Grok Bot and Claude Duet), The Code gave plain advice. These agents hold your logins, so give each one only the access it needs and keep the merge button for yourself. Their side-by-side video of the four agents is worth ten minutes before you connect anything. Agents gain new capabilities every week. The boundary around them is the part you own.
Our position, and the number we do not have
The model underneath any of these agents will be swapped, probably more than once before next summer. What compounds is the judgement about which rung each agent sits on and who signs off when it climbs. Katelyn Lesse, head of platform at Anthropic, made the engineering version of this point in an essay The Code summarised on 30 October. She argues for short-lived workload identities instead of static keys, isolation for every agent action, tracing that no agent can modify, and kill switches that revoke credentials.
Now a gap in our own evidence. We do not have a reliable figure for how many agents in a mid-sized marketing team run on a personal login. We have not measured it across enough teams to say, and we would rather tell you that than invent a number. Our hypothesis is that the count is higher than most heads of data would guess, because a shared password was the fastest path to a working demo for most of this year.
The permission ladder
This is the ladder we suggest for any agent that touches customer or company data. There are four rungs, with a gate between each one.
| Rung | What the agent may do | Credential | Who carries a mistake | Gate to climb |
|---|---|---|---|---|
| 1. Read | Read, triage, summarise and flag. Nothing leaves. | Read-only, scoped, revocable token | Nobody, no action is taken | A person has checked the tool-call log on the first runs |
| 2. Draft | Write drafts, branches or staged records that a person picks up | Write access limited to a sandbox or branch | The operator who reviews the draft | Drafts are accepted with light edits, and the agent’s own identity is in place |
| 3. Act with approval | Request a send, payment or merge, which a named person approves each time | Scoped token plus an approval step | The approver | A written owner who agrees to cover losses |
| 4. Act alone | Act within set limits, with every step logged | Short-lived identity, tamper-proof trace, kill switch | The operator, stated in writing | Back to rung 3 after any incident |
The ladder has risks. It slows you down at the start, and a team under pressure will be tempted to skip rung two. The opposite risk also exists: keeping every agent on rung one forever throws away the time it was meant to save. Nate Grahek, who teaches teams to use AI at The Rundown, treats read-and-triage as a good first step rather than the last one.
What to do this week
Start by listing every agent that can reach a system holding customer records, and write its rung next to it. Next, replace each shared password with a scoped token, or remove the access. If an agent sits on rung four, name the person who pays when it gets something wrong. If nobody will put their name to it, the agent belongs on rung three. As Linas argues, banks will probably write the rules for agent access to money. It seems wise to write your own first.