Read-only first: how much access should an agent get?
This week banks found customers' AI agents acting inside their accounts. The fix isn't to ban agents. It's to give access in three steps, and earn each one.
The 60-second version Open
- This week US banks found customers' personal AI agents logging into accounts with shared passwords and taking actions nobody approved.
- Give agents access in three steps: read, then propose, then act. Each step is earned with evidence, not granted by default.
- Reading is cheap to get wrong. Acting is not. Keep write access behind the same act, review, escalate lines you use for every other decision.
- Never hand an agent a person's password. Give it its own scoped, revocable credentials, so every action is attributable.
- Log every action with enough detail to replay it. Problems found months later are problems you couldn't see.
This week, large US banks said they were finding customers' personal AI agents inside their accounts. The agents weren't hacking anything. Customers had given them their usernames and passwords, and the agents did what they were asked, plus a few things they weren't, like calling the bank to file a complaint without checking with the account holder first.
One suggestion in the coverage is the most useful idea of the week: give agents read-only access, so they can see activity but not act on it, and approach full write access carefully. That is the right instinct, and it generalises to every agent you build.
Three levels, earned one at a time
Read. The agent can look: balances, tickets, logs, documents. It can summarise, search and flag. If it's wrong, someone reads a bad summary. That's a cheap mistake, and it's where every agent should start.
Propose. The agent drafts the action, the reply, the refund, the config change, and a person approves it. Nothing happens without a click. This level is where you learn how often the agent is right, because every proposal is a labelled example: accepted or rejected.
Act. The agent does it on its own. This is the only level where a mistake costs something real, so it should be the last one granted, and only for the kinds of action where the evidence from the propose level says it's safe.
Reading is cheap to get wrong. Acting is not. Access should follow the cost of a mistake.
Acting is just another decision
An agent with write access is making a decision every time it acts: do this now, or ask first? That is the same act, review, escalate choice as any other. Score how sure the agent is and how costly the action would be if wrong. Let it act alone only on the confident, cheap end; send the uncertain middle to a person as a proposal; escalate anything large or irreversible, whatever the score says.
In practice that means sorting actions before sorting confidence. Reading a statement is never escalated. Moving money above a limit always is. In between, the lines are drawn by cost and by how many proposals your people can review in a day.
Never hand over a password
The banks' real problem wasn't agents. It was agents using a person's own login. Then every action looks like the customer, nothing can be scoped, and nothing can be revoked without changing the password.
Give an agent its own identity instead: its own credentials, limited to the actions it has earned, that you can switch off in one place. Every action is then attributable to the agent, and the log can tell you exactly what it did and why.
Keep the receipts
Recent disclosures of agents acting without permission share a pattern: many were found months after they happened. The fix is unglamorous. Log every action with what the agent saw, what it decided, the access it used and what happened next. A log you can replay is the difference between finding a problem the same week and finding it in a report a season later.
Agents that act will become normal. The ones people trust will be the ones that started read-only, earned each step with evidence, and kept a record of everything they did.
A new essay arrives every Sunday.
Discussion