Four Protocols Are Solving Agent Identity for US Banks

Mercury's CEO posted a chart last week showing MCP usage on the platform. The curve is the kind of line that makes infrastructure engineers start asking questions about capacity planning.

JPMorgan blocked Meta's Muse agent and several others from interacting with its services entirely.

Two opposite bets, in the same week, on whether an AI agent should be allowed to touch a bank account.

The banks blocking agents aren't wrong about the risk. An agent with account access can view balances, initiate transfers, and make spending decisions. If nobody can prove who sent the agent, what the customer authorized, or where the agent's permissions end, then blocking it is the rational default.

But "block everything" has a shelf life. Customers are already using agents to manage expenses, file invoices, and automate payment workflows. The question for banks is whether that interaction happens through a controlled protocol stack or through screen-scraping and password sharing.

Four protocols are emerging to answer that question. Each one covers a different layer of the problem, and none of them work alone.

The four layers

When a human walks into a bank branch, four things happen in sequence: the person shows ID, the teller verifies who they are, the system checks which accounts they can access, and the transaction record captures what they authorized.

Agent identity needs the same four layers, in the same order. But the "branch" is an HTTP request, the "teller" is an API endpoint, and the "ID" is a cryptographic credential that needs to prove things about a person who isn't present.

PAP (Personal Agent Protocol) signs the agent in. Built by Sierra AI and Meta, PAP uses OAuth to let a company know that an agent represents a specific customer. The customer scopes what the agent can access. The company declares what agents are allowed to do. BofA, Wells Fargo, Synchrony, and BBVA have joined the protocol.

x401 proves the identity of the person behind the agent. It's an HTTP proof requirement protocol that carries verifiable credentials at the wire level, using three headers: PROOF-REQUEST, PROOF-RESPONSE, and PROOF-RESULT. The spec is edited by Proof and Circle, with reviewers from Visa, OpenAI, and Okta. Identity proofs meet NIST IAL2 assurance, the same level US banks use for remote account opening.

Once authenticated, MCP (Model Context Protocol) declares what the agent can do. An MCP server exposes a set of tools with scoped access tokens. "Read these transactions" is one tool. "Initiate a transfer" is another. The bank controls which tools exist and what each token can reach.

Verifiable Intent covers the last layer: recording what the customer specifically authorized. Mastercard developed it with Google and donated the spec to the FIDO Alliance. It creates a tamper-resistant record linking the customer who set up the agent, the spending instructions they gave, and the merchant interaction that produced the purchase.

How x401 works at the wire level

The spec is dense, so I'll walk through what a bank implementing x401 would actually build.

A customer's agent hits a protected endpoint. The bank's API returns a PROOF-REQUEST header containing a base64url-encoded payload. Inside that payload is an OpenID4VP request authored by the bank, specifying exactly what credential the bank requires. A bank might require a FinancialCustomerCredential at assurance level VC-AL2 or higher.

The agent doesn't compose the proof request. It takes the bank's request, hands it to a credential manager (a wallet holding the customer's verified identity), and gets back a credential result. The agent then retries the original request with a PROOF-RESPONSE header carrying that result.

If the proof checks out, the bank can optionally issue a short-lived OAuth verification token. On subsequent requests, the agent presents the token instead of re-proving identity every time.

Two details matter here. First, x401 is separate from payment. The spec explicitly states that payment must use HTTP 402 and a separate payment protocol (that's x402's job). x401 handles identity only. Second, the bank is the relying party for the credential request. The bank signs the request, and the result is cryptographically bound to the bank. A credential result generated for one bank can't be replayed against another.

Where PAP and x401 overlap and diverge

PAP and x401 both involve "proving who the agent represents," but they operate at different altitudes.

PAP is about the session. The customer grants their agent OAuth access to their bank account, scoped to specific capabilities. The bank knows which agent is connecting and what the customer allowed. This is the layer where "my agent can view my transactions but can't move money" gets enforced.

x401 is about the identity. The credential proves something about the person, not about the session. A bank might require x401 proof before allowing the agent to open a new account, apply for a credit product, or authorize a large transfer. The credential travels at the HTTP layer and works across services, because the proof is about the person, not the specific application.

In practice, a bank would use PAP for ongoing session management (the agent is signed in, here's what it can do) and x401 for high-assurance moments (prove the person is real before we process this application).

The Reg E question nobody has answered

Regulation E protects consumers in electronic fund transfers. When an unauthorized transfer happens, the consumer's liability depends on how fast they report it: $50 within two business days, $500 after that, unlimited if they don't review their statement within 60 days.

But the commentary on Section 1005.2 draws a line that matters for agents. It distinguishes between a stolen access device and one "given to another person" with authority to make transfers. If that person exceeds the authority they were given, the transfer isn't unauthorized under Reg E. The consumer is liable unless they've told the bank the person is no longer authorized.

So: is an agent a "person" who was given authority?

If a customer sets up an agent with a $200 spending limit through PAP, and the agent requests a $2,000 transfer, the question is whether that transfer is unauthorized (bank's problem, Reg E protection applies) or an exceeded authorization (customer's problem, same as giving your kid your debit card and them buying a PlayStation).

As of October 2026, no federal regulator has addressed how Reg E applies to agent-delegated transfers.

The protocol stack creates the evidence that would let someone answer it. PAP records what scope the customer granted, x401 proves the customer's identity, MCP logs which tools the agent called, and Verifiable Intent records what specific transaction the customer approved. Without these layers, a dispute resolver has no artifacts to examine.

The regulatory green light most people missed

On September 8, 2026, FinCEN, the Fed, FDIC, NCUA, and the OCC jointly updated their CIP guidance to recognize verifiable digital credentials. Government-issued credentials like mobile driver's licenses now qualify as "government-issued identification" under the CIP Rule. Third-party digital credentials are permissible for non-documentary verification if the issuer authenticates at the same level the bank itself would require.

This is the regulatory enabler for x401. A bank that accepts an x401 credential presentation from an agent's credential manager is doing something regulators have now explicitly said is permissible, as long as the credential issuer meets the bank's standards. Proof, the company behind x401, holds a Kantara-certified NIST IAL2 identity proofing certification and operates a WebTrust-audited certificate authority. The credentials are X.509 certificates bound to hardware-protected keys.

Until this guidance, a bank accepting digital credentials for CIP was making an interpretive call with limited regulatory backing. Now the five federal agencies have said it's permissible.

What a composed request flow looks like

Put all four layers together and a single agent-to-bank interaction runs like this.

The agent connects to the bank via PAP. OAuth handshake, scoped access token. The bank knows which agent platform is connecting and which customer it represents.

The agent hits a protected endpoint for, say, initiating a wire transfer. The bank's API returns a PROOF-REQUEST header requiring identity proof at IAL2. The agent's credential manager presents a verifiable credential. The bank validates the credential and issues a verification token.

The agent calls the MCP tool for wire transfers with the verification token. The MCP server checks the token's scope, confirms the agent has transfer permissions under its PAP grant, and processes the request.

Verifiable Intent records the authorization: this customer, this agent, this amount, this recipient, this timestamp. The record is tamper-resistant and can be presented in a dispute.

Four protocols maintained by four different companies and standards bodies, with no single vendor controlling the stack.

Where the seams are

The protocols compose well in theory. In practice, three seams are open.

The first seam is between PAP and x401. Both involve identity, but neither spec references the other. A bank implementing both would need to build the bridge: use PAP for session establishment, trigger x401 challenges for high-assurance actions within that session. That integration layer doesn't exist in either spec.

The second seam is revocation latency. A customer who revokes their agent's PAP access expects that revocation to take effect immediately. But if the agent holds a valid x401 verification token with 300 seconds of remaining life, it can keep making requests. The token is valid, even if the underlying authorization is gone. This is the same problem session management has always had, but the stakes are higher when the session can move money.

The third seam is cross-protocol dispute evidence. Each protocol generates its own record, but no spec defines how to package them together for a dispute resolver. The authorization scope lives in PAP, the identity proof in x401, the tool call log in MCP, and the purchase approval in Verifiable Intent. Assembling those into a coherent narrative for a chargeback case is an exercise left to the bank.

What this means for the four previous pieces

I've covered agent commerce from four angles: the missing authorization layer, the card networks splitting on approach, the absent chargeback codes, and agents as a new risk type.

Those pieces identified problems. This is the infrastructure that's forming around them. PAP and MCP address the authorization gap. x401 and Verifiable Intent create the evidence that dispute resolution currently lacks. The risk framing holds, but the mitigation stack is real and moving fast.

The open question is timing. The x401 spec is at version 0.2.0, still in draft. PAP has four US banks exploring it. MCP is shipping in production at Mercury and others. Verifiable Intent is at the FIDO Alliance but wire-level specs are pending. The pieces exist, but the assembled stack is still ahead of where most banks are building.

For the banks that are building now, the protocol stack is the answer to a question their compliance teams have been asking since the first agent hit their API: how do we let this in without losing control of who's doing what?