Know Your Agent: Who Authorised the Software in Your Customer's Account?

22 Oct 2026

22 Oct 2026 by Luke Puplett - Founder

This week brought reports that US banks are finding third-party AI agents inside customer accounts. Not agents the bank built or approved, but software the customer, or someone, has handed a login to. The agents log in, look around, move money, change settings and pull data, and to the bank's systems they look a lot like the customer.

Some of that is perfectly legitimate. People are starting to let assistants pay bills, chase refunds and tidy up their finances, and plenty of them will want to keep doing it. Some of it won't be legitimate at all. The awkward part is that, from the inside of a banking platform, the two can look almost the same.

So every regulated service is about to face the same question, if it isn't already: when a customer's account is touched by software, can you tell who authorised it?

Why existing controls can't see it

Most security controls quietly assume there's a person at the keyboard. Passwords, one-time codes and device checks are all ways of asking "is this the right human?" Once that question has been answered, the session is trusted.

An agent breaks that assumption without breaking any of the controls. It can hold session cookies, refresh tokens or API keys, and then behave exactly like the customer. You see the activity. You don't see whether a real, verified person actually wanted that particular agent to act for them, or what they wanted it to be allowed to do.

Blocking anything that looks automated is one answer, but it's a blunt one. It annoys customers who are using agents on purpose, and it sets off an arms race with the ones who aren't. What's missing is a separate, checkable proof of authorisation that travels with the agent.

KYC was built for people

Regulated services still have to meet their own rules: KYC, AML, age limits, sanctions and the rest. None of that goes away because an agent is doing the clicking.

But the question you need answered for an agent is narrower than "who is this person?" It's closer to: "is this agent allowed to do this on behalf of a real, verified person?" You shouldn't have to copy everyone's passport into your systems to answer that. Every extra copy of an identity document is one more thing to secure, retain, delete and explain to a regulator.

A chain you can verify

Zipwire Attest and the open-source ProofPack libraries support a simple sequence. Each step produces evidence the next one can check, and your service never needs to see anyone's ID document.

1. A verified human. The customer completes a one-time identity check, for example through Zipwire Attest. Their wallet receives an on-chain IsAHuman attestation: a cryptographic stamp saying they're a real person, rather than a scan of a document sitting on your servers.

2. A signed delegation. The customer delegates their agent's wallet with an IsDelegate attestation on the Ethereum Attestation Service (EAS). In effect, that record says "this agent may act for me".

3. The agent presents proof. When the agent calls your API, it can send a signed ProofPack (a JWS) that reveals only the claims you need, such as "over 18", nationality or AML status. Those claims link back to the human root through the delegation chain.

4. Your service verifies. Your backend checks the signature and the chain with ProofPack. For a lighter check, it can call the public IsDelegate API instead. Then you apply your own policy.

The useful thing about a chain is that each link can be checked on its own. A valid delegation without a verified human at the root fails. So does a ProofPack signed by an attester you've decided not to trust. Your service gets a yes or no it can reason about, instead of a guess based on behaviour.

I went into the developer side of this, including what a backend needs to verify, in When Agents Come Calling back in March.

Verification without seeing the ID

In this model the customer's passport or driving licence stays with the attestation provider. What reaches you is cryptography: attestations on-chain, optional selective disclosure in a ProofPack, and your own choice of which attester addresses to trust.

You learn whether the chain is valid and which claims were disclosed. You don't learn what the document looked like, and you don't end up storing it unless you choose to collect it separately for your own reasons.

For regulated flows that need specific claims, rather than just "is there a human behind this agent?", the Compliant Agent Operations guide shows how agents prove user compliance to regulated and financial APIs. If you only need the delegation check, the IsDelegate API docs cover the public endpoint.

What exists today, honestly

I'd rather you heard the limits from me.

• Delegations are created on the EAS site today. Creating delegations inside Zipwire is coming soon. Until then, a customer who wants to delegate an agent does it directly on EAS.

• ProofPack is open source. The verification libraries for JavaScript, .NET and Rust are on GitHub, so you can read exactly what gets checked rather than taking our word for it.

• We're not claiming any bank partnerships. Zipwire provides infrastructure and open specifications for this model. We don't claim adoption by any particular bank or regulator. This is a technical approach your teams can evaluate against their own risk and compliance processes.

It also doesn't make agents safe by itself. A verified delegation tells you a real person authorised an agent. Deciding what that agent may do, how much it can move and when to step in is still your policy. The point is that you'd be setting that policy on evidence rather than on guesswork.

Where to go next

We've put the short version on a single page for risk, fraud and compliance teams: Know Your Agent.

If you're on the engineering side, start with the Compliant Agent Operations guide, then the IsDelegate API and the ProofPack libraries. The March post walks through the whole chain from the agent's side.

Agents in customer accounts aren't going away. Knowing which ones were invited is the part we can fix.

---

Learn more