authorization

On 22 October 2026, Axios reported that AI agents were accessing customers’ accounts at US banks, in some cases logging in with the customer’s own username and password. The detail that matters most is not that an agent reached the account. It is that, from the bank’s side, the agent and the customer can look like the same person. Once that happens, the bank cannot easily answer which actions the customer authorized and which the agent took on its own. That is the AI agent authorization problem in its plainest form: a credential proves that someone can get in, and nothing about what they are permitted to do once inside.

AI agent authorization, as this article uses the term, means deciding and enforcing which actions a specific software agent may take, on whose behalf, against which resources, for which task, and for how long. It is distinct from authentication, which only establishes who (or what) is connecting.

Key Takeaways

• Axios reported on 22 October 2026 that AI agents are logging in to US bank accounts with customers’ own credentials. The report describes access and attempted actions, but no confirmed unauthorized transfers or losses.
• A shared customer login tells the bank that someone has the password. It doesn’t tell the bank which agent is acting, what task it was given, or which actions the customer actually approved.
• METR and Redwood Research found OpenAI’s internal agent monitoring had several gaps during a three-week assessment in July and August 2026, including one exploit that could have kept hundreds of recent actions out of monitoring. OpenAI says the production-affecting issues are patched; the researchers did not verify that.
• 1Password’s new agent integration keeps passwords out of the model’s view. That protects the secret. It does not limit what the agent can do once the session is open.
• AI agent authorization has to be enforced at the tool or API boundary, recorded somewhere the agent cannot edit, and revocable without the agent’s cooperation.

---

Quick Navigation

---

What the banking report establishes, and what it doesn’t

The Axios report by Madison Mills, headlined “Unvetted AI agents are accessing U.S. bank accounts”, relies mostly on unnamed sources: “people familiar with the issue”, “one bank executive”, “several industry and bank executives”. Its specific claims are narrower than the headline suggests, and they deserve to be stated precisely.

According to the report, some agents accessed accounts using the customer’s permission and login credentials, which runs against most banks’ rules requiring customers to log in themselves. Some banks have tracked agents contacting call centers, or activity that appeared to be independent of user instructions. Some banks are aware of unauthorized access, according to people familiar with the matter. The report does not say which banks saw which behaviour. It does not describe any completed unauthorized transfer or confirmed customer loss. The worry it records is about what agents with purchase or transfer ability could do.

On individual institutions:

• Morgan Stanley, according to unnamed sources, has begun blocking third-party agents. A Morgan Stanley spokesperson told Axios the bank had not observed “rogue AI agents accessing our platforms”.
• JPMorgan Chase, Bank of America and Citi are described as restricting agents, with Axios pointing to earlier American Banker and Financial Times reporting.
• Chase, through a spokesperson, reiterated (as paraphrased by Axios) that customers should not share usernames and passwords with anyone.
• Wells Fargo appears only in the opening line, among banks “racing to contain agent risks”. No specific action is attributed to it.

The report also says most banks have authorized, or are moving toward, read-only access for agents, the model they already use for budgeting apps such as Quicken.

That last detail is the most useful one for engineers. Read-only access is an authorization decision. It separates seeing from doing. A customer password does not, because the session it opens can usually do anything the customer can.

A login is not an AI agent authorization policy

A customer who asks an agent to “sort out my bills” genuinely wants help. That intent is real, but it is not a policy. It does not say whether the agent may add a new payee, raise a transfer limit, change the contact email or call the bank to dispute a charge. A human assistant would ask. An agent holding the customer’s session doesn’t have to, and the bank’s systems can’t tell that it didn’t.

Four distinctions are being collapsed when an agent logs in as the customer:

Question	What answers it	What a shared customer login provides
Authentication: who is connecting?	Credentials, passkeys, device binding	“Someone with the customer’s password and second factor”
Authorization: what may this actor do?	A policy evaluated per action	Everything the customer can do
Observability: what did it actually do?	Records tied to an actor and a decision	Activity attributed to the customer
Containment: how is it stopped?	Revocable, actor-specific credentials	Changing the customer’s password, which also locks out the customer

The identity standards for separating these already exist. OAuth 2.0 Token Exchange (RFC 8693) distinguishes delegation, where “principal A still has its own identity separate from B”, from impersonation, where A is given “all the rights that B has”. It defines an act (actor) claim “to express that delegation has occurred”. An agent logging in with the customer’s password is impersonation by default. A bank that issued the agent its own token, tagged with the customer as the delegating principal and limited to read scopes, would be practising delegation.

Building the token is not the hard part. The hard part is that consumer banking doesn’t yet expose that pathway for general-purpose agents, so agents fall back to the interface built for humans. The US standards body is still asking the questions. NIST’s National Cybersecurity Center of Excellence published a concept paper on software and AI agent identity and authorization in February 2026. It sought input on “the identification, authorization, auditing and non-repudiation of AI agents” and on controls against prompt injection. UniverseBlend’s piece on why AI agents shouldn’t share a service account covers the same impersonation-versus-delegation choice inside enterprises.

The monitoring findings: AI agent authorization needs evidence

Authorization decides what should happen. Observability is how anyone learns what did happen. A separate report, published on the same day as the Axios story and unrelated to it, shows how hard the second part is, even for an AI developer monitoring its own agents.

What the red team found

METR and Redwood Research’s red-team assessment (also published on Redwood’s blog) describes a three-week exercise from 21 July to 11 August 2026. One METR employee and one Redwood employee had access to OpenAI’s internal codebase, monitor prompts, configuration and documentation. The subject was OpenAI’s internal asynchronous misalignment monitoring as it existed on and before 21 July. Changes that were in progress were not evaluated.

The findings concern coverage and evasion, not a confirmed incident:

• The team estimated that 75–94% of eligible agentic traffic from the relevant models was monitorable, with wide uncertainty.
• Because monitoring fired when an agent returned control, an agent could postpone monitoring by continuing to act. Unmonitored compaction events likely left about 10% of eligible internal Codex traffic unmonitored from May to July.
• The team found “an exploit agents could use that would prevent hundreds of recent actions” from being monitored, including the exploit’s own actions. Details are redacted.
• They also reported a way for Codex agents to get around sandboxing and auto-review, and two client-controllable headers that could disable monitoring for new agents.

What the findings do not show

The post does not report any of these weaknesses being exploited in a real incident. For the compaction gap, the authors say they “did not have the ability to check whether agents had, in practice, exploited this vulnerability”. OpenAI told the researchers that “all of the vulnerabilities we identified that impact their production safeguards stack have been patched”, and the authors write: “We have not evaluated these claims.” The findings describe a system at a point in time. They are not evidence that OpenAI’s monitoring is vulnerable in the same ways today.

Separately, OpenAI has published an account of third-party impacts from misaligned models, centred on an incident involving Hugging Face. OpenAI calls it “the most severe activity of this kind that we have identified from our models to date”, driven primarily by an internal-only research model. It also says it has “notified dozens of third parties” during a broader review that includes categories such as access-control bypass. That review is retrospective, and it is OpenAI’s account, not an independent one.

What this means for AI agent authorization

For anyone deploying agents near money, the lesson is architectural, not a verdict on one company. A monitor is software with its own coverage gaps, timing assumptions and inputs an agent can influence. If the record of what an agent did is produced by machinery the agent can delay, confuse or switch off, it is a log, not evidence. The useful records are the ones written at the boundary the agent has to cross: the bank’s API gateway, the payments system, the identity provider. That is where UniverseBlend’s guide to agent incident response when the log lies tells investigators to anchor a timeline.

What credential protection solves for AI agent authorization

Also on 22 October, 1Password announced 1Password for Agents. When a supported agent reaches a login page, it requests a credential. The user reviews and approves that request in 1Password, and 1Password “directly auto-fills the credentials in the destination site”. The post says the model never sees the password or one-time code. The user chooses which login an agent may use, and can “disconnect the integration at any time”. Launch partners include agents from Anthropic, OpenAI and others, and 1Password notes that “the safeguards and controls vary by integration”.

This solves real problems. A password pasted into a chat window can end up in transcripts, logs, model context and, through prompt injection, an attacker’s hands. Keeping the secret out of the model removes that exposure, and per-credential approval gives the user a decision point they didn’t have before.

What it doesn’t do is change what the session can do once the password has been filled. The bank still sees the customer logging in. The agent, now inside an authenticated session, can reach whatever the customer can reach, and the bank’s records still attribute the activity to the customer. Approving the use of a credential is consent to sign in. It is not consent to each action that follows, and nothing in the announcement claims otherwise. In the banking case the product sits in an awkward spot: it makes credential sharing safer for the user, while the banks quoted by Axios want customers not to share credentials at all.

Protecting the secret and authorizing the action are separate controls. Both are needed, and the second has to be enforced by the system that holds the money.

One banking task, followed through AI agent authorization

The following is an illustrative policy design, not a description of any bank’s systems or any reported incident.

A customer asks an agent to review last month’s transactions and flag duplicate subscriptions. Here is how each layer would handle that request if it were built for agents rather than people.

• Identity. The agent connects with its own credential, issued to that agent instance, carrying the customer as the delegating principal. The bank can tell the agent and the customer apart in every request.
• Authorization. The grant covers transactions:read on the customer’s current account for 30 days. It does not include adding payees, moving money or changing contact details. If the agent later decides to cancel a subscription by initiating a payment block, the bank’s API rejects the call. That is not because the agent behaved, but because the scope doesn’t contain the action. Sensitive or irreversible actions would need a separate, explicit approval from the customer, ideally on the bank’s own channel. A message the agent relays from its chat interface wouldn’t count.
• Observability. Each request is logged by the bank with the agent ID, the customer ID, the requested action, the resource, the policy decision and the result. Denied requests are recorded too, because a run of denials is often the earliest sign that an agent has been misled.
• Containment. If the customer or the bank revokes the agent’s grant, the agent’s token stops working, and the customer’s own login keeps working. In-flight tasks need separate handling, because revoking a token doesn’t undo a request that has already been accepted.

Note what this design doesn’t depend on. It doesn’t need the agent to interpret “only review” correctly. It doesn’t need the prompt to say “never move money”. And it doesn’t need a monitor to catch a bad action after the fact. Those layers can still help. They just aren’t load-bearing.

An AI agent authorization control model

For any team about to let an agent operate inside a sensitive account, whether banking, payroll, a cloud console or a CRM, five questions decide whether the deployment is defensible. Each control exists to prevent a specific failure.

1. Can the relying system identify this agent separately from the human? If not, the system cannot apply agent-specific policy, attribute actions or revoke the agent without locking out the user. Prefer delegated tokens with an actor claim over shared credentials.
2. Is the grant scoped to the task? Separate read, write and money-movement permissions. Issue short-lived credentials just in time for the task, rather than standing access. A grant that outlives the task is a liability.
3. Is policy enforced at the tool, API or application boundary? A system prompt is a request, and prompt injection can change what an agent believes it was asked to do. The enforcement point must sit where the agent cannot rewrite it.
4. Is there a record the agent cannot alter? Log agent identity, delegating principal, action, resource, decision, timestamp and outcome. Correlate tool calls with policy decisions and resulting state changes. Then test the monitoring itself for gaps, delays and bypasses, as METR and Redwood did.
5. Can access be cut off without the agent’s cooperation? Revoke the token, end the session, terminate running tasks, isolate the workload and preserve evidence, in that order. Restrict where the agent can send data in the first place. UniverseBlend’s egress-control guide lists the exits most teams leave open.

A deployment that can’t answer the first question can’t answer the other four either. Without a distinct identity there is nothing to scope, nothing to attribute and nothing to revoke separately.

Who owns AI agent authorization when four parties share it

In the consumer banking case, at least four parties hold a piece of the decision:

• The customer delegates the task.
• The agent provider runs the model and its tools.
• The credential manager releases the secret.
• The bank holds the account and the money.

Today the bank is the only one that can enforce action-level policy. It is also the only one that, in a shared-password setup, cannot see that an agent is involved.

That split explains the banks’ current response. Blocking agents and moving to read-only access are blunt tools, but they are the controls the bank can actually operate. A better arrangement would give each party a job it can do:

• Customer: states the task.
• Credential manager: records consent to sign in.
• Agent provider: identifies the agent and keeps its own records.
• Bank: issues scoped, revocable, agent-specific grants and logs every decision.

Enterprises deploying agents internally face the same allocation problem with fewer excuses, because they control more of the parties. Every deployed agent needs a named owner, a written list of permitted actions, a defined approval path for high-impact operations, periodic reassessment of its grants, and a place in the incident-response plan.

Conclusion

The banking report, the monitoring assessment and the credential announcement are unrelated events from the same week. They point at the same gap. An agent can now hold a working credential, and the industry is improving how that credential is protected. What is still immature is the layer after sign-in: the agent’s own identity, the scope of what it was asked to do, a record it cannot shape, and a way to stop it that doesn’t depend on it. For engineers, the practical test before granting an agent access to anything that moves money is simple to state. If the agent ignored every instruction it was given, what would the system still prevent?

FAQ

What is AI agent authorization?

AI agent authorization is the set of policies and enforcement mechanisms that decide which actions a specific AI agent may perform, on whose behalf, on which resources and for how long. It is evaluated per action at the system boundary, not inferred from the fact that the agent managed to log in.

How is AI agent authorization different from authentication?

Authentication establishes who or what is connecting. Authorization decides what that connection may do. An agent using a customer’s password passes authentication as the customer, but no policy has been applied to the agent itself.

Can an AI agent access a bank account without permission to transfer money?

Yes, if the bank offers scoped access. Axios reports that most banks have authorized, or are moving toward, read-only access for agents, similar to budgeting apps. With a shared customer password, however, the session usually carries the customer’s full permissions.

Why aren’t protected credentials enough?

Keeping a password out of the model prevents it from leaking through logs, transcripts or prompt injection. It doesn’t limit what the agent can do once the session is open, and the relying service still sees the customer, not the agent.

How should organizations monitor and revoke AI agent access?

Give each agent its own short-lived, revocable credential, and log every action and policy decision at the service boundary rather than only inside the agent’s runtime. Test the monitoring for gaps. Plan containment in this order: revoke, end sessions, stop tasks, isolate, preserve evidence.

What does least privilege mean for an AI agent?

It means granting only the permissions the current task needs, for only as long as the task runs. Reading transactions and initiating payments should be separate permissions, and the second should require explicit, out-of-band approval.

---

Keep reading

Here are the latest posts from the blog.