What the OCC's AI Framework Means for Agents Banks Don't Control
On November 4, the OCC gave its examiners a new framework for reviewing how banks use AI. The OCC's main points are that AI shouldn't be viewed as a separate risk category, but as part of the risks a bank already manages, like operational, compliance, and credit risk. The second is that oversight of an agent can scale with what the agent is actually capable of doing and how much damage it can cause, instead of basing risk simply on how advanced the technology is. The framework doesn't create new rules for banks, but it shows how examiners will look at a bank's use of AI.
Much of the framework covers agents banks deploy themselves, but at Proof, we think what's most important for the moment is how banks treat agents that they don't control: the ones that are going to be used by their customers and access a bank's systems. Right now, some of the largest institutions are turning those agents away. JPMorgan Chase CEO Jamie Dimon recently said the bank blocks external AI agents from operating on behalf of retail customers, citing security risks, and Charles Schwab has moved to block personal agents like Meta Muse, CNBC reported.
Before a bank can trust a customer's agent to move money or close an account, it needs proof of who the agent is acting for and what that person approved, bound to a verified legal identity. It also needs to know that the verified person is its customer, the one with the relationship to the account. We think that's what it will take for banks to give customers' agents access, and the riskier the action, the more that proof matters.
The framework touches on these outside agents in its section on operational resilience (2.10). It says they could present channel risk and lists things examiners may consider, from confirming who an agent is and who it's acting for to monitoring it and cutting off its access. These are considerations rather than requirements, and the OCC says they can be matched to what the agent is asking to do. In practice, checking a balance and moving money out of an account don't need the same scrutiny.
Where the strongest checks belong
When the framework sorts a bank’s own agents by risk, it asks whether a mistake can be undone, and its examples of ones that can’t are “a payment sent, a disclosure made, an account closed.” Its illustrative tiers put a fully autonomous payment agent that a bank offers its customers in Tier 1, which the OCC labels “Critical.”
Our read is that agents brought by the customer should get the same treatment for those same actions. That covers payments, a total withdrawal, and opening a new account. For actions like these, a bank should want that proof in hand before anything goes through.
Delegation needs the right person behind it
Some of the considerations in 2.10 run on the bank's own systems, like watching what an agent does once it's in the bank's channels or limiting how often it can act. Delegation is harder to check from inside the bank. It's the authority someone gave an agent to act for them, and for a customer's agent, that someone has to be the customer who holds the account. Verifying that a real person is behind the agent isn't enough; the bank needs to know that person is the account holder.
The framework's cybersecurity section (2.11) suggests banks manage agent identities and credentials much as they manage users with elevated system access. If I were a bank, I'd want the same for a customer's agent, and I'd want to keep the evidence. The documentation section (2.14) says records of approvals, among other things, can help reconstruct an important decision after the fact. A customer's signed approval, kept alongside the bank's logs, would do that if an action is ever disputed.
Where x401 fits
That's the kind of control we built x401 to provide. x401 is our open protocol that lets any website ask an AI agent to prove who it's acting for and what that person approved. The customer approves on their own device exactly what the agent can do, including which agent, which merchant, what action category, what amount ceiling, and what time window. Their identity is verified to NIST IAL2, and when they approve, a hardware-protected key signs the presentation, binding their verified legal identity to the terms they authorized.
The business receiving the request, which can be a bank, can confirm the customer's identity and check the signature. The bank can also retain the signed evidence and validate it later if the transaction is disputed. x401 is already live in the Superfluid Wallet.
For a customer’s agent, x401 gives the bank a verified identity and a signed approval, which the bank can match to the account holder before it acts.
Read the x401 specification to see how a site can require that proof before granting access.
.jpg)
