Four of five information points in the source material carry no named source. The only quotation in the piece — "horrified" — appears inside the headline, unattributed, without a speaker, an outlet, or a timestamp. The article carries no publication date at all.
That is where I stopped reading the claim and started reading the provenance. I have spent enough years auditing contracts to know the pattern: the press release says reentrancy, the diff says a missing modifier. The severity is real. The description is wrong. Both facts matter, and the second one usually tells you who wrote the copy.
Here is the actual event the body text supports: third-party AI agents logged into customer accounts at multiple large banks using the customers' own credentials. The banks began restricting that access. That is the whole of it. No fund losses reported. No model breaking containment. No bank statement quoted. No regulator named.
The headline calls the agents rogue. Rogue means the agent exceeded its principal's intent. Credential delegation means the agent executed exactly the principal's intent, through a channel the bank never authorized. Those are different failure modes with different fixes. One is an alignment problem. The other is a contract problem.
The code doesn't lie, but the narrative does.
What the agent was actually doing at the transport layer
There is no sanctioned way for a retail customer to hand an agent the keys to a bank account. That is the entire root cause, and everything downstream is a consequence.
Open banking exists on paper. In the EU, PSD2 created the legal category of payment initiation service provider and forced account access through consent flows and tokenized credentials. It works, within limits. Coverage is uneven across institutions. Latency is worse than a direct session. Scope is narrower than what an agent wants — read balance, initiate payment, but not "rebalance my savings based on a rule I described in plain English." A customer who wants that today has no compliant primitive to reach for.
So the market built one out of duct tape. Credential delegation: the customer hands over username and password, or a session cookie, or a one-time code, and the agent replays human behavior against the bank's own interface.
The stack is not exotic. Browser automation via Playwright, Puppeteer, or raw Chrome DevTools Protocol. A computer-use class vision model reading screenshots and emitting click and keystroke actions. Or an older RPA pipeline with an LLM bolted on to handle the pages the RPA scripts never anticipated. There is no architectural novelty here. It is an engineering composition, and the interesting engineering is on the defense side, not the offense side.
The technical sophistication in this event belongs entirely to the banks. The agents are running a twenty-year-old scraping playbook with a better parser.
This has happened before, in a smaller frame. Financial data aggregation spent a decade in exactly this fight — screen scraping against bank portals versus tokenized API access. Plaid, Yodlee, MX, and every aggregator of that generation lived through the same conflict: banks blocked, aggregators re-encoded, lawsuits followed, and the resolution came from regulators pushing standardization rather than from either side winning. The open banking frameworks we have now are the peace treaty from that war.
What is different this time is the direction of the operation. Scraping read data. Reading wrong produces an information error. An agent that can initiate a transfer produces a loss. The risk gradient is not comparable, and any analysis that treats this as the same fight at higher volume is missing the part that matters.
Three authorizations, one product, and the gap nobody priced
The commercial conflict is not about model quality. It is about three separate authorization layers that customers, agent vendors, and banks each mean something different by.
Layer one is customer authorization. The customer gave the agent the password. In the customer's mind, that is consent, and it is total.
Layer two is bank authorization. The bank never issued a token, never received a consent record, never saw the agent in its developer portal. From the bank's side, this is unauthorized third-party access using shared credentials. Not an AI problem. An access control problem, and one that predates AI by decades.
Layer three is regulatory recognition. A payment initiation service under PSD2 or PSD3 requires licensing. Anti-money-laundering obligations attach to an identifiable operating subject. Consumer protection rules assume a human counterparty. An agent satisfies none of these by default.
Any product that clears layer one and stops will scale until it hits layers two and three, and then it dies. Not because the model was weak. Because the authorization chain was incomplete. This is a structural ceiling, and it was visible from the first commit.
What "detection" means when a bank says it found an agent inside an account
The buried lede in this story is not that banks blocked something. It is that banks could see it.
If four major institutions independently began restricting the same class of traffic in the same window, they are running production-grade non-human session detection. Not a research project. A classifier with enough labeled samples to justify action.
Here is what that pipeline looks like, from the inside. Device fingerprint entropy — canvas and WebGL rendering variance, font enumeration, audio stack signatures, hardware concurrency and memory inconsistencies. Behavioral biometrics — keystroke dwell and flight time distributions, pointer velocity and acceleration curves, scroll deceleration, navigation cadence, the micro-pauses before form submission. Transport-layer fingerprints — TLS ClientHello ordering, JA3 and JA4 hashes, HTTP/2 frame sequencing and header order. Automation artifacts — the residue that frameworks leave in the DOM and in the runtime, headless rendering quirks, CDP session characteristics. And timing distributions — a read-only sweep of twelve pages in four seconds is not a person checking a balance.
Note what the classifier is actually discriminating. It is not asking "is this an AI." It is asking "is this a typical human session." That distinction matters enormously, because it means the detection generalizes. A better model does not evade it. A different vendor does not evade it. Only re-humanization evades it, and re-humanization is expensive and perishable.
I debugged bots; now I debug bias.
I ran a minting bot in 2021 and lost three weeks to race conditions under network congestion — RPC latency spikes, nonce collisions, transactions landing out of order. That was a race condition in my own code, and the fix was mine to write. What an agent vendor faces here is different in kind. The adversary is not latency. The adversary is a defender who can ship one rule update and invalidate every variant simultaneously. The cost curve is asymmetric and it points the wrong way for the attacker. Anti-fraud and anti-scraping have fifteen years of data on this, and the defender always wins the marginal round.
A detection capability deployed at four institutions means the sample population was already material. You do not build a production classifier for three incidents.
That is the fact the article never states. If the blocking is coordinated across multiple large banks, credential-delegated financial agent traffic was not a curiosity. It was a measurable share of sessions. The agent economy arrived at the bank's front door in volume, unannounced, wearing a costume.
The risk surface that the headline buried
Strip out the "rogue AI" framing and the real risk table is short, quantifiable, and almost entirely ignored by the coverage.
Prompt injection and instruction hijacking — high. An agent with operating capability reads page content, emails, statements, confirmation dialogs. Any text it reads is a potential instruction channel. Malicious content — a crafted invoice line item, an injected paragraph in a document the agent parses — can redirect a transfer or trigger an authorization the customer never intended. Generic agents have weak separation between data and instruction. This is an architecture boundary, not a tuning problem, and it does not get fixed by a better system prompt.
Credential concentration — high. The customer's password sits in a third-party vendor's vault, aggregated across thousands of customers. That is a single point of compromise with an addressable population far larger than any individual account. From the customer's side it is unauditable. You cannot verify what the vendor stores, how it encrypts at rest, or who inside the vendor can decrypt.
Liability vacuum — high. Customer authorized, bank did not. Both sets of terms may disclaim responsibility. When the loss lands, it lands on whoever has the weakest contract position, and today that is the customer. There is no case law here. There is no established rule for who eats the loss when an agent misreads a decimal point.
Scope creep — medium. Delegated permissions are coarse. An agent granted account access to check a balance effectively holds authority to move funds. Granularity — per-transaction caps, read-only tokens, time-boxed grants — is technically straightforward and commercially rare, because coarse permissions are easier to sell.
Hallucinated operations — medium. Wrong amount, wrong recipient, wrong account. Mitigable with hard thresholds and second-party confirmation. Cheap to fix, and mostly unfixed.
Static analysis misses the human variable.
That line matters here more than anywhere. A code review of an agent stack will tell you the permissions model and the injection surface. It will not tell you what happens when a customer who does not understand any of this clicks approve because the interface made it feel safe. The human variable is the part that turns a medium-severity design flaw into a high-severity loss event.
What the banks actually did, and what they did not say
The public description is "restricted access." The operational reality is almost certainly two tracks running in parallel.
Track one is technical. Session-level blocking, step-up authentication challenges that an automated client cannot complete, rate limits on read patterns, and fingerprint-based interception at the edge.
Track two is contractual. Terms of service already prohibit credential sharing at most institutions, and those clauses typically void fraud reimbursement. That is the cheap half of the defense. You do not have to detect anything perfectly if the terms say the loss is the customer's.
What no bank has published is the part that would tell us where this goes. Is there a developer program for agents? A consent flow with a machine-readable grant? A whitelist and an appeals process? A false-positive rate disclosure for customers running screen readers, password managers, or delegated portfolio management — all of which produce non-typical session signatures and will get caught in the same net?
None of that exists publicly. That silence is the actual signal, and it is more informative than any quoted adjective.
Liquidity is just trust with a timeout.
Every access decision in this story is a trust decision with a clock on it. The customer's trust in the agent vendor. The bank's trust in the session. The regulator's trust in the operating subject. Right now only the first clock is running, and the other two are stalled at zero.
The contrarian read: safety is the cheapest moat available
The framing that reached the public is that banks panicked at AI capability. Read the incentive structure instead.
If an agent can compare rates, move funds, and allocate across institutions from outside the bank's interface, the bank is demoted from relationship owner to account plumbing. Restricting third-party agents on security grounds is the lowest-cost way to defend that relationship.
This is not cynicism. It is just reading the balance sheet. Losing one agent channel costs a bank approximately nothing in revenue today. Losing the customer interface costs it the entire product surface. The bargaining position is wildly asymmetric: the agent vendor cannot complete a fund movement without entering the bank's system, and the bank can refuse service unilaterally. That asymmetry is the whole negotiation.
A second contrarian point, and the one that matters most technically: alignment research does not touch this problem. RLHF aligns a model's values. It does not resolve the question of whether the model can reliably distinguish "content I was asked to process" from "instruction I was asked to follow" when both arrive as text on a rendered page. You cannot fine-tune your way out of a data/instruction boundary failure. It is not an alignment tax. It is a capability boundary, and the industry keeps filing it under the wrong heading.
A third: open source is irrelevant here. The block is not on weights. An open-weights agent gets blocked identically, because the block is at the session layer, not the model layer. Anyone arguing that decentralized agents will route around this is confusing a licensing problem with a censorship problem. They are not the same, and the mitigation is not the same.
Smart contracts are cold, but margins are warm.
The market's instinct — banks block AI, therefore buy AI security — is a narrative trade with almost no revenue elasticity behind it. Trace the actual cash. Robot management and behavioral biometrics vendors get incremental demand first, because their product already exists and the requirement just became urgent. Delegated authorization infrastructure gets demand second, because someone has to build the consent and grant layer. Open banking API providers get demand third. Screen-scraping aggregators and consumer financial agents take the loss. That ordering is defensible from the structure alone, and it requires no forecast about which bank moves next.
What to watch, and what would change the read
The constraint on the agent sector over the next twelve months is not model capability. It is authorization protocol. Everything else is downstream.
Four signals, in order of information value.
First, whether any bank publishes developer terms or an agent access policy. That single document would tell you whether this is a defensive pause or a permanent wall, and it would set the template everyone else copies.
Second, whether the first real loss event lands. A prompt-injected transfer, a misread recipient, a disputed charge. That is the trigger for liability rules to form, and until it happens every party is negotiating in the dark. One adjudicated case would reprice the entire category.
Third, what the card networks do. Their agent payment specifications are the actual gate. If agent transactions get folded into existing clearing and dispute machinery, the compliance path opens. If they do not, agents stay stuck in a half-state: queries permitted, executions forbidden.
Fourth, how regulators classify machine-initiated account operations under KYC and AML frameworks. Under PSD3 and the payment initiation licensing regime in Europe, and under whatever final form the US open banking rules take — and I will not state a firm legal conclusion on that, because the rulemaking and litigation posture have moved repeatedly and any summary is stale within a quarter. Verify against the current official text, not against an article about it.
Efficiency is the only honest emotion.
The efficient outcome is obvious and nobody is racing toward it. Machine-readable consent, scoped tokens, per-transaction caps, auditable delegation, a licensed operating subject, and a dispute path that does not require a human to have been present. Every piece of that exists in some form. What is missing is an agreement on who owns it.
The agent that survives the next cycle will not be the one with the best reasoning benchmark. It will be the one holding a signed authorization, from a counterparty that has a reason to honor it.
Until then, the interesting number is not how many agents got blocked. It is how many banks have published the terms under which one would be allowed back in.
Right now, that number is zero. And a zero that specific is not an absence of data. It is the data.