The Inevitable: Who Authorized This Agent's Transfer?

Picture an examiner pulling one transfer from a bank's ledger. An AI agent started it on a customer's behalf at 2:14 in the afternoon. The examiner asks one question: what did the bank check before it released the money? This week the industry started building the answer to an earlier question, who or what is on the other end of the session. That work matters. The examiner's question is still open.

The Brick: Banks Start Sorting Agents From People

On October 27, Socure launched Agent Intelligence, a three-part suite for banks and fintechs. Agent Detection, generally available now, tells a bank whether a session is driven by an AI agent. Agent TrustScore, in beta, scores whether that agent should be trusted. Agent Credential, scheduled for the first quarter of 2027, ties an agent to the verified person or business behind it. Socure says it works with about 3,000 banks.

On November 4, the Office of the Comptroller of the Currency released a supervisory framework for how examiners should review AI at national banks. It ranks systems by potential harm, and its illustrative Tier 1 example is a fully autonomous, customer-facing payment agent. It also covers outside agents that reach a bank through its channels. On November 6, Banking Dive reported where PNC and Fifth Third stand as they draw their own lines: Fifth Third does not let agents start transactions in customer accounts, and PNC's chief executive has said no bank will let agents transact without a human in the loop.

Who Is Acting, and What Was Allowed

Socure is working on the right first question. A bank cannot write any policy for agents until it can tell an agent from a person, and Agent Credential goes a step further by linking the agent to a verified principal. That covers who is acting.

The examiner's question comes after that. Was this transfer within what the principal authorized at the moment it went out, and can the bank prove it now? Knowing that a verified person stands behind an agent does not say what that person agreed to let the agent do, or whether the permission had been withdrawn by 2:14.

We covered a close cousin of this last week, when Cornell and Yale researchers found nine of ten frontier models would raise their own spending caps once they could reach a one-time password (read that issue). A login or a code that works for any action leaves the agent to pick the right one.

The Card Programs Already Enforce Limits

Corporate card programs built for agents are not waiting on regulators. Ramp's documentation describes agent cards that request a checkout credential for each purchase and follow the fund's spend limit, merchant rules and approval policies. Other agent card programs, Sunrate among them, document amount controls and auditable actions. Inside a card network the issuer enforces the limit and keeps the log, and that works.

The open ground is money that moves on-chain under a delegation the customer signed with their own wallet, as banks start handling tokenized deposits and stablecoins for agents. There the bank needs a record of the on-chain condition, signed by someone other than the bank, that anyone holding the published keys can check without calling the signer back.

The Check and the Record

InsumerAPI's POST /v1/attest reads chain state, evaluates a condition and returns a signed yes or no. Two conditions fit a bank's transfer gate.

• erc7710_delegation: met is true only when the agent's wallet is the delegate, the delegator is the principal the bank expects, the principal's signature verifies, the delegation is not revoked as of the block checked, every caveat uses a recognized enforcer, and any time window is open. The amount and target limits the principal signed come back as declaredLimits, a signed decode that sits next to the verdict. They are reported, not tested against your transfer. The bank checks the proposed call against the declared caveats (for an ERC-20 transfer the call target is the token contract, and the payee sits in the calldata), checks the payee under its own policy, and on-chain redemption enforces the caveats. Base only. A result carrying a delegation expires in five minutes, because revocation is one transaction away.
• ratio_to_amount: met when the wallet holds at least a set multiple of the transfer amount. It answers a separate question, whether the agent's holdings cover this transfer, and it scales to every transfer size without re-tuning. The bank learns the yes or no, never the balance.

Every result is signed twice: ES256 and a post-quantum ML-DSA-65 signature. The five-minute window governs whether the bank may act on a result. It does not limit how long the signature can be checked. A bank that keeps the signed result and a copy of the published keys can verify the historical signature long after the live window has closed, and the open-source insumer-verify library checks both signatures offline, with no call back to InsumerAPI. That is the argument we made to NIST in our submission on agent identity and authorization: the record has to outlive the moment it was made for.

The Counterfactual

What if the bank's payment gateway were the control point? Every transfer submitted through the delegated payment path has to pass the same check, whether or not Socure flagged the session, so a missed detection skips nothing. The gateway authenticates the requester as the delegate, takes the expected principal from the bank's own customer record, and verifies a fresh attestation before it applies the transfer policy. That first step matters because the wallet in an API request is only an input: the attestation says what is true of that wallet, and the gateway still has to know the wallet is the one asking. If met comes back false, the transfer stops. If it comes back true, the gateway checks the proposed call against declaredLimits, checks the payee under the bank's written policy, then decides. It stores three things against the transfer ID: the signed attestation, the policy version it applied, and its own decision. Socure's signals still feed the policy. They just are not the trigger.

Back to the examiner. Each record proves something different. The attestation shows the delegation was signed by that principal, unrevoked as of a named block, with those declared limits. The policy version shows the rule the bank applied. The decision log shows the bank applied it to this transfer. None of this week's announcements describe that step, and it is a what if, not something any of these companies built. The check runs today. What is missing is a bank wiring it into the payment path.

What to Do Next

If you run a bank's payment gateway, a fintech or an agent card program, get a free key at /developers/quickstart/ and put the call in front of the release:

POST https://api.insumermodel.com/v1/attest
{
  "wallet": "0x<agent wallet>",
  "conditions": [{
    "type": "erc7710_delegation",
    "chainId": 8453,
    "delegationManager": "0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3",
    "expectedDelegator": "0x<customer wallet, from your customer record>",
    "delegation": { "...": "the signed delegation the customer gave the agent" }
  }]
}

Authenticate the requester as the agent wallet first, and save the signed result with your decision. The full request and response shapes are on the conditions page. If your agent already has a wallet, it can skip the key and pay per call with x402 from five cents in USDC, covered in our walkthrough on agent payments and the authorization gap. For the banks drawing these lines now, read the case for proving an agent was authorized before an examiner asks you to show your work.