A consumer clicked “allow” so a budgeting app could read their checking account. They did not click “allow” so that app’s agent could hire a second agent to read it too. The consent was for a human’s tool, and it is now driving a fleet.

That is the whole problem in one sentence, and it is not a hypothetical. Open banking, the regulatory settlement that finally pried consumer financial data out of the bank’s exclusive grip, was built on a consent model that assumed a person at one end and an app at the other. The moment the app becomes an autonomous agent that delegates to other agents, the grant the consumer signed no longer describes what is actually reaching into their account. The rule protects a chain that has stopped existing.

What the consent actually is

Start with what open banking gives the consumer, because the language matters. In the United States the mechanism is the CFPB’s Personal Financial Data Rights rule, the one implementing Section 1033 of Dodd-Frank. Its core move is simple and genuinely good: the data belongs to the consumer, the bank has to make it available, and a third party can retrieve it only with the consumer’s authorization. The rule is explicit that authorization is scoped, revocable, and tied to a stated purpose. It is not a blanket key to the account. It is a permission slip with a name on it, a purpose written across the top, and an expiration date.

Underneath the regulation sits the plumbing, and the plumbing is where the assumptions get baked in. The Financial Data Exchange API is the industry standard that replaced screen-scraping, where an aggregator stored your bank password and logged in as you, with a tokenized OAuth flow, where you authenticate to your own bank and hand the third party a scoped, revocable token instead of your credentials. That was a real security win. Screen-scraping meant a third party held a credential that could do anything you could do. FDX narrowed it to a token that can do one declared thing for a declared window.

Look closely at the shape of that token grant and you can see who it was designed for. FDX consent carries the data recipient’s identity, the specific data clusters it may read, a duration, and a purpose. It is a bilateral contract: this consumer authorizes this named recipient to read this data for this reason until this date.

Two parties. One human, granting. One app, receiving. Every field in the object describes that pair, and the consumer’s revocation dashboard lists exactly one recipient because the model only ever imagined one. The entire stack, the regulation and the plumbing both, is a straight line with a person at one end and a single named app at the other.

OAuth was never built to be handed down

OAuth is the consent primitive under all of it, and OAuth has one job it does well and one job it was never designed to do at all.

The job it does well is delegated access between a user and an app. The Authorization Code flow exists so a consumer can grant a third party scoped, revocable permission without surrendering a password. The app presents its identity, the user consents to a defined scope, the authorization server issues a token, and every subsequent call carries that token as proof the user said yes. This is the model FDX runs on and the model 1033 assumes. It works because it is a straight line: one delegator, one delegate, one scope.

The job OAuth was never built to do is propagate that consent through a handoff. When the app receiving the token is itself an agent, and that agent calls a second agent to complete the task, there is no primitive in the protocol that carries the consumer’s authorization across the hop. The security community named this bluntly at RSAC 2026: agent-to-agent delegation needs a trust primitive that does not exist in OAuth, SAML, or MCP. Those standards were designed for human-to-service and service-to-service flows. Nobody wrote the case where a delegate re-delegates on the user’s behalf, because until agents, delegates did not do that.

I worked the enterprise version of this in The Agent Identity Federation Gap. This post is the same fault line running through consumer financial data, and consumer data is where it bites first, because 1033 already made the sharing mandatory. The regulation created a right to move the data, on rails whose consent model stops at the first delegate. The volume is arriving before the trust primitive does.

The two ways the chain breaks

When the first agent hands off, exactly one of two things happens to the consent, and both are wrong.

The first failure is that the second agent inherits nothing. The task simply stops, because the second agent has no token that says the consumer authorized this. That is the safe failure, and it is also the one that guarantees multi-agent financial workflows do not work, so the market pressure is entirely against it.

The second failure is the dangerous one, and it is the path the convenience gradient pushes toward. To keep the workflow alive, the system reaches for a pattern that already exists in the enterprise identity world: token exchange, the on-behalf-of flow, where a gateway swaps the incoming user token for a fresh credential scoped to the downstream call. Salesforce runs exactly this to preserve user context across hops, minting a new token per route so the second service still acts under the user’s identity. At enterprise scale it processes millions of these calls a day, and as engineering it is sound.

As a stand-in for consumer financial consent, though, it is a forgery. The consumer authorized the named app. Nothing in their 1033 grant said the app could mint a derived credential for a second party they never saw, never named, and cannot revoke independently. The consent was bilateral. The system quietly turned it into a bearer instrument and passed it down a chain the consumer cannot see and the bank cannot audit back to an authorization.

Either the fleet cannot act, or it acts on a consent the consumer never gave. There is no third option inside today’s standards, because the standards encode a two-party assumption that the agent handoff violates by construction.

The part where the machine cannot be trusted to hold the line

Suppose you try to fix propagation in software, by having each agent faithfully carry a description of the original consent and refuse to exceed it. Now you are asking a probabilistic system to execute a deterministic security protocol, and the evidence on that is not encouraging.

Researchers at TU Berlin built exactly this: agents equipped with verifiable credentials, presenting cryptographic proof of authority at each hop in a multi-agent exchange. Completion rates ran from 32 to 97 percent depending on the model. The failures were not slow responses. Agents altered credential data, forgot information they had retrieved, and dropped the security procedure entirely when the language model was left to orchestrate it. That is the finding that should reorganize the whole design. Consent propagation cannot live in the reasoning layer, because the reasoning layer will occasionally decide the constraint does not apply and proceed anyway. It has to be enforced by deterministic machinery outside the model, the same lesson every other part of agentic infrastructure keeps relearning.

There is a quieter identity problem underneath even that. Before you can propagate a consent, you have to be certain whose consent it is, and consumer financial identity is famously fragmented across institutions, aggregators, and derived accounts. I pulled on that thread in Data Identity Resolution: if you cannot resolve the consumer to a single stable identity, you cannot bind a revocable consent to them, and a consent you cannot reliably revoke is not really consent. The agent handoff sits on top of an identity layer that was already shaky before anyone added a second agent.

What the rule actually protects, and what to build

Read 1033 for its intent rather than its mechanics and the intent survives the agent era fine: the consumer controls their financial data, and access is scoped, purposeful, and revocable. What breaks is the assumption that a single OAuth grant to a single named recipient is enough to guarantee those properties end to end. It is not, once the recipient is a delegator.

So the thing to build is a consent that describes a chain instead of a hop. Scope has to include the permitted onward recipients, not just the first one. Revocation has to reach every agent operating under the original grant, not just the app the consumer can see in their dashboard. The audit trail has to reconstruct which agent did what under whose authority, which is precisely the behavioral-authorization gap the identity vendors keep flagging: everyone verifies who the agent is, almost nobody records what it did. A consent that cannot answer “which agent read my account, and did the consumer’s grant actually cover that agent” is not a consent an examiner can stand behind.

No shipping standard defines this yet, but the body best positioned to define it has already started. In April 2026 FDX opened an agentic-AI initiative and stood up a cross-industry task force whose call for input names the missing pieces almost exactly: agent identity and classification, consent and delegation, data minimization, and downstream accountability. The standards body itself now agrees the gap is real, and it owns the consent object that needs the extra fields, so extending that schema is a far smaller lift than inventing a delegation protocol from scratch. That is also the easy 20 percent. An exploration is not a shipped standard, and even once the schema lands, the hard 80 percent is the deterministic enforcement layer that makes the propagated consent mean something when a non-deterministic agent is the one carrying it.

The honest admission

I do not think a consumer will ever meaningfully consent to a fleet. The whole appeal of the agent is that you do not have to think about the fleet, and a consent screen that enumerated every possible downstream agent would defeat the point and get clicked through anyway. So the burden cannot sit with the human at the “allow” button. It has to sit in the infrastructure that turns one human’s scoped grant into something a chain of agents provably cannot exceed, whether or not any single agent in the chain feels like honoring it.

That is the unglamorous work, and it is where the next few years of open banking will actually be decided.

---

Consent was the load-bearing fiction of open banking: one click stood in for a human’s full intent, and the standards were built to move that click safely to one named app. Agents unbundle the click from the human and then hand it down a chain nobody consented to. The fix is not a better button. It is a consent that survives the handoff.

This is the middle post of a three-part arc on what agents do to money: payment authorization, consent propagation, and identity. The companion piece on payment rails, When the Agent Reaches for the Card, works the layer where the money actually moves; this one works the layer where permission is supposed to travel and does not. The identity post closes the loop.

I write about AI-assisted development, enterprise architecture, and the regulatory plumbing that agentic systems are about to stress-test. Find me on X @orestesgarcia or LinkedIn /in/setsero.