Wells Fargo Wants Proof You Revoked Your AI Agent. Here Is What That Proof Looks Like.

On November 24, 2026, a new Online Access Agreement takes effect at Wells Fargo. Section 15 covers AI agents, and one sentence in it asks customers for something most of them cannot produce today. If you let an agent act on your account and later shut it off, "You must retain evidence of such revocation and must provide such evidence to us, at our request." Chase rewrote its own terms on October 27. Both banks now treat whatever an agent does as something the customer did. Wells goes one step further and makes the customer responsible for proving when the agent stopped.

What the two agreements say

Chase's Digital Services Agreement bans outside AI from logging in with a customer's password. It does allow "third-party applications and tools, including External AI, to access customer account data through approved application programming interfaces ("APIs") with your authorization." Either way, a customer who lets an agent in is deemed to "expressly authorize that third party to transact in your account," and Chase will "rely on, and treat as evidence of your authorization, any actions taken or instructions given by the third party as if you personally took or gave those actions or instructions."

The agreement says plainly that this can go wrong. Agent instructions "may be inaccurate, incomplete, unintended, or inconsistent with your actual requests." It also says who is watching for that. It is "solely your responsibility to monitor the third party's activities," and Chase has "no obligation to automatically or subsequently review or screen the third party's activities, including transactions."

Wells Fargo's Section 15 lands in the same place. Unless the law says otherwise, agent actions "are deemed to have been initiated and authorized directly by you, without further verification." Use of an agent is "AT YOUR OWN RISK." The bank does "not monitor, screen, or review AI Agent activities." Then come the two clauses that matter most here. Section 15(f) asks for the revocation evidence quoted above, and says the customer stays responsible for everything the agent does until the bank is notified. Section 15(g) reserves the right to require "that you register your AI Agents with us."

Why the banks wrote it this way

American Banker's Penny Crosman reported on October 27 that at least five large banks are blocking outside AI agents: JPMorganChase, Citi, Bank of America, Wells Fargo and Morgan Stanley. Her lead anecdote explains why. A large bank watched an ordinary-looking agent reset an account's password, log in, change the approved transfer accounts and move $100,000 out. The fraud team went to the CEO and recommended blocking every external agent.

A bank in that position has two problems. It cannot tell a customer from an agent using the customer's login, and it cannot tell whether the customer meant for the agent to do what it did. Blocking deals with the first problem. The new terms deal with the second by deciding in advance who is responsible, subject to the law. That allocates the risk. It leaves nobody holding a record of what the agent was allowed to do, or when the permission ended.

Customers rarely hold a record they can check

Think about how a customer revokes an agent today. They change their password, or they delete a connection on a settings page, or they cancel a subscription with the company that runs the agent. Each of those leaves a record, but the record sits in the bank's logs or the agent provider's logs. What the customer keeps is a confirmation email or a screenshot: something they hold, but nothing anyone else can check independently.

If a dispute turns on whether the agent was still authorized when it moved the money, that is a weak hand. The customer is asked to prove a negative about a system they do not control, using records kept by the other side.

What a usable record looks like

The pieces for a better record already exist as public standards, and none of them is ours.

ERC-7303, a draft Ethereum standard, describes an "Agent Permission" pattern. The customer mints a control token to the agent's account to grant it a role, and burns the token to take the role back. Anyone can check whether the agent holds it. The standard allows transferable control tokens; for an agent pass you would use one that cannot be transferred, so the permission stays with the agent it was granted to.

ERC-7710 defines a standard way to check delegated authority. In the implementation most of this work runs on, the MetaMask Delegation Framework, the customer signs a delegation to the agent's wallet that can carry limits: a time window, a spending cap, a list of allowed destinations, a maximum number of uses. The delegation is signed off chain, and revoking it is a transaction on chain.

Either way, the revocation is the strong part. It is a transaction the customer signs, dated by its block, on a public chain that neither the bank nor the agent provider can edit. A pass grant is dated the same way, because minting is also a transaction. A delegation grant carries the customer's signature but no block date of its own. A time window in it records the period the customer meant it to be valid, not when it was signed. Proving the delegation existed by a given block takes a separate recorded event, such as the first check that read it.

None of this satisfies the bank's terms by itself. Section 15(f) still requires the customer to notify Wells Fargo under its own procedures, and a public permission only counts as registration under Section 15(g) if the bank agrees to recognize it. The missing step is the bank's: linking the customer's account to the wallet that grants the permission, so the bank knows whose grant it is reading. With that link in place, the revocation transaction becomes evidence the customer can keep and hand over when asked, and the grant becomes an agent registration the bank can check without calling anyone.

The check at each action

A record of the grant and the revocation only helps if somebody looks at it when the agent acts. That is where wallet auth comes in. Before acting on an agent's instruction, the bank asks one question: does this agent's wallet still hold the customer's permission right now? InsumerAPI reads the chain, evaluates the condition and returns a yes or no, signed twice: ES256 and a post-quantum ML-DSA-65 signature. The bank can check both signatures offline against our published keys.

For an ERC-7710 delegation, the answer is yes only if every one of these holds: the wallet asking is the delegate, the delegation names this customer as the one who granted it, the customer's signature verifies, the delegation has not been revoked as of a named block, every limit in it is of a recognized kind, and any time window in it is open. The limits the customer signed come back decoded alongside the answer, so the bank can see the cap the customer set. Because revocation is one transaction away, a signed answer that includes a delegation expires in five minutes rather than the usual thirty. Ask for a Merkle proof and "not revoked as of block N" can be checked against the block header itself, without taking our word for it.

A pass under the ERC-7303 pattern is simpler still: the bank asks whether the agent's wallet holds the pass. The call for both is at the end of this post.

The bank stores the signed answer next to the transaction. If the customer later says the agent was acting without permission, the bank can show that the permission existed, at which block, and with which limits. If the bank says the agent was still authorized, the customer can point to the block where they revoked it. Both sides are reading the same public record.

None of this needs the bank to open its doors to every agent. Chase already names the door it prefers: approved APIs, with the customer's authorization. A check like this one supplies evidence inside that process: something the bank can read at the moment of each transaction, as one input to its own decision. I wrote about the general question in June, in How Do You Prove an AI Agent Was Authorized to Act?, and about the merchant version of it in September, when Amazon blocked Meta's Muse for logging in as the customer. The banks have now reached the same place from the other side.

What this does not do

It does not prove what the customer meant, and it does not decide whether a given transaction is allowed. It shows that the agent held the customer's permission, with the limits the customer signed, as of the block the check names. When that permission ended is shown by the revocation transaction, not by any one check. Whether this particular payment fits those limits, and the bank's own rules, is still the bank's call.

A signed answer also does not show who controls the wallet. The bank still needs the agent to prove it holds the wallet's key, with a signed challenge, before the answer means anything. Otherwise any caller could name an agent wallet that holds a permission.

The limits in a delegation are reported as the customer signed them. The check does not enforce a spending cap. The bank has to compare the actual transaction against those limits, or the chain does it when the delegation is redeemed.

A signature never stops verifying, so an answer signed before a revocation still checks out afterward. What limits the risk is its expiry. Each answer states when it should no longer be relied on, five minutes for a delegation, and a bank that checks fresh at every action never leans on an old one. That narrows the gap without closing it: there can still be a few seconds between the block the check read, a revocation landing, and the bank executing the payment. Researchers working on agent credentials call the gap between shutdown and the last usable credential the "zombie window" (Heartbeat-Bound Hierarchical Credentials), and the goal is to keep it short.

The delegation check runs on Base today, for delegations signed directly by the customer. And both agreements say their terms apply unless the law provides otherwise. Federal consumer protection rules for electronic transfers still apply, and nothing here changes them.

For developers: the call

The delegation check is one request. Add "proof": "merkle" and the answer carries a proof of the revocation slot against the block header:

curl -X POST https://api.insumermodel.com/v1/attest \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "wallet": "0x<agent wallet>",
    "proof": "merkle",
    "conditions": [{
      "type": "erc7710_delegation",
      "chainId": 8453,
      "delegationManager": "0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3",
      "expectedDelegator": "0x<customer wallet>",
      "delegation": {
        "delegator": "0x<customer wallet>",
        "delegate": "0x<agent wallet>",
        "authority": "0xffff...ffff",
        "caveats": [ { "enforcer": "0x<enforcer>", "terms": "0x<hex>" } ],
        "salt": "42",
        "signature": "0x<customer signature>"
      },
      "label": "Authorized by this customer"
    }]
  }'

For a pass, swap the condition for {"type": "nft_ownership", "contractAddress": "0x<pass contract>", "chainId": 8453}.

November 24

Wells Fargo has given its customers four weeks to start keeping evidence of revocation, and most of them have nothing they could hand over that anyone else could check independently. That record can exist. A customer can grant an agent a permission they sign and revoke it with a transaction they sign. A bank that links the customer's account to that wallet can check the permission at every action and keep the signed answer. That turns "deemed to have been initiated and authorized directly by you" into something both sides can look up.

Douglas

Sources: Chase, Digital Services Agreement, Section 9 and Section 17, changes effective October 27, 2026 (static.chasecdn.com); Wells Fargo, Online Access Agreement effective November 24, 2026, Section 15 (wellsfargo.com/online-banking/online-access-agreement/upcoming/); Penny Crosman, "Banks are blocking external AI agents. Is this sustainable?," American Banker, October 27, 2026; ERC-7303, "Token-Controlled Token Circulation" (Draft), eips.ethereum.org; "Heartbeat-Bound Hierarchical Credentials: Cryptographic Revocation for AI Agent Swarms," arXiv 2605.20704.

The book behind this post

Secrets and Agents: Why AI Agents Cannot Hold Secrets, and How the Blockchain Becomes the Way They Prove Anything is Douglas Borthwick's third book. It argues that an agent carrying its owner's password is a leak waiting to happen, and that an agent carrying a permission it can prove has nothing worth stealing. Chapter 4 covers why an agent cannot keep a secret. Chapter 10 covers the delegate that never needs one. In paperback, hardcover and Kindle.

Get Secrets and Agents on Amazon →