AI Agents Inherit Organisational Identity: Why AgentID Sits on the Business Wallet

An AI agent calls one of your customers. It says it is calling from your company, about their account.

Everything in that sentence is unverifiable. Caller ID is trivially spoofable. The voice is synthetic and can be anyone's. The agent's claim to represent you rests on nothing a recipient can check.

Now reverse it. An agent calls your support line claiming to act for a supplier, asking to change payment details. You have the same problem, pointed the other way.

The common answer is to give the agent an identity. That is necessary and not sufficient. Knowing which agent is calling tells you nothing about whether it was authorised to make the call.

The question that matters is organisational. Which legal entity does this agent act for, and what was it permitted to do on that entity's behalf? That fact does not live in a citizen's wallet. It lives in the company's.

The disclosure duty already exists

This is not a problem waiting on future regulation.

Article 50 of the EU AI Act has applied since 2 August 2026. Providers of AI systems that interact directly with people must ensure those people are told they are dealing with an AI, at the latest at the first interaction. The Commission's draft guidelines confirm AI agents are in scope and name automated phone systems explicitly. Where a provider cannot reliably predict whether a human is on the other end, the guidance says the agent should disclose in every such interaction.

So the agent in that opening scenario is already legally required to announce itself.

Notice what that achieves and what it does not. The disclosure is self-asserted. The agent declares its own nature and the recipient has nothing to check it against. The channel that carries an honest disclosure carries a dishonest one equally well, and a bad actor has no incentive to comply in the first place.

A duty to disclose, with no mechanism to verify the disclosure, is where this sits in late 2026.

Three questions, not one

Agent identity work tends to collapse three separate things.

Identity establishes which agent is acting. Authentication proves the caller controls that identity. Authorisation decides what the agent may do.

A valid identity does not make an action valid. An agent can be exactly who it says it is and still have no business asking for what it is asking for.

Most tooling today handles the first two well. API keys, workload identity, OAuth tokens and service accounts all answer "is this caller who it claims to be," inside a boundary, usually inside one company.

The third question breaks the moment the agent talks to someone outside that boundary. A customer receiving a call, a merchant receiving an order, a bank receiving an instruction. None of them can query your internal identity system. They need something verifiable independently, and it has to carry the organisation, not just the agent.

Why the citizen wallet cannot carry this

It is tempting to assume EUDI Wallets solve this. They do not, and the gap is documented rather than speculative.

A Cloud Security Alliance research note published on 15 April 2026 examined exactly this question. It found that the eIDAS 2.0 implementing acts do not expressly address AI agents as first-class identity principals, and that identity data is defined in human terms throughout.

It also looked at the certification side. The ENISA draft candidate certification scheme, which went to public consultation at version 0.4.614 with comments closing on 30 April 2026, does not expressly accommodate non-human principals. Whether it will require or validate multi-layer delegation flows for agents is unresolved.

The delegation model in the citizen wallet framework was designed for human and business-to-person scenarios. An employee proving they may act for their employer. It does not cleanly extend to agents, which can be short-lived, can cross borders mid-task, and can act under several delegated authorities at once.

The same note points at European Business Wallets as the better structural fit for machine-to-machine enterprise authorisation. That is the argument this piece is making, and it is worth being precise about why.

What an agent credential actually has to carry

Work backwards from what a recipient needs to decide whether to trust the call.

Which entity. Not the vendor that built the agent, and not the cloud account it runs in. The legal entity that takes responsibility for what the agent does.

What authority. The specific permission, scoped. Discuss an existing order, not place new ones. Read an account balance, not move funds. Authority without limits is not authority, it is a blank cheque.

For how long. Agents are spun up and torn down on timescales no employment relationship matches. A credential with a twelve-month validity describes a world that no longer exists by week two.

Verifiable by whom. By someone with no relationship to your identity infrastructure. That constraint rules out most internal approaches and is the reason verifiable credentials matter here.

The CSA note sketches this as three layers. An identification credential for the person or entity, a delegation credential carrying the authority, and an agent attestation binding the two to the specific agent. The chain matters more than any single link, because a recipient is verifying a path back to an accountable entity, not just a signature.

The payments industry is converging on the same shape from its own direction. Google donated the Agent Payments Protocol to the FIDO Alliance on 30 April 2026, and FIDO's Agentic Authentication working group is building trusted delegation frameworks meant to hold agent transactions inside user-approved parameters. What is emerging there is a signed mandate stating what an agent may do, not a credential stating who it is. That is the same conclusion reached from a different problem, which is usually a sign the conclusion is right.

This is the Business Wallet's existing job

Here is why the organisational layer is the natural home for this, rather than a new category of infrastructure.

Delegation is already one of the five core functions in the European Business Wallets proposal. Proving that a named party may act on behalf of a company, and binding that party's actions back to the legal entity. The Commission's proposal describes it for humans: authorising a representative to act in a legal capacity.

An agent is the same problem with a different actor. The company still has to prove it is the company. The delegation still has to state what was permitted. The recipient still has to verify the chain without calling anyone.

That is also why the groundwork is the same groundwork. The attestations that make reusable KYB work, where a company presents verified facts about itself rather than sending documents, are the same primitives an agent presents when it has to prove whose authority it carries. If you have built the organisational credential layer, you have built most of the agent layer.

One caveat. The European Business Wallets regulation is not law. The Council adopted its negotiating position on 9 June 2026 and the Parliament's industry committee adopted its own on 10 September 2026, voting to open negotiations. Nothing is final. What exists today is the architecture and the standards underneath it, which is enough to build against.

The part nobody has solved

Revocation is where this gets uncomfortable, and it deserves saying plainly rather than being skipped.

An employee leaves once. You revoke their access and the problem ends. An agent may be created and destroyed hourly, may run in a thousand parallel instances, and may be compromised in ways that are not visible from outside. The question "is this delegation still valid" has to be answerable in the moment, at the point of verification, not by a nightly sync.

The CSA note's own interim suggestion is telling. It recommends short-lived, sender-constrained OAuth tokens as a stopgap while the credential model matures. Short lifetimes are what you reach for when you cannot revoke reliably.

Standards work is still moving underneath all of this. NIST's National Cybersecurity Center of Excellence published a concept paper on software and AI agent identity and authorisation on 5 February 2026, with comments closing on 2 April. It is a proposed project, not a finished framework. Treat anything sold as a complete agent identity standard today with suspicion.

A working example

The abstract version of this is easy to nod along to. The concrete version is a phone call.

Hovi built a demonstration of a verifiable AI call agent, as a fork of an open source dialer enhanced with wallet capability. When an AI sales agent calls, the app verifies the agent's identity using verifiable credentials and DID-linked resources before the conversation proceeds.

The part that matters for this argument is what happens next. The verified agent acts through an organisation wallet, and verifies the user's identity in real time during the call by interacting with their digital wallet. Both directions, both verified, inside one interaction.

That is the whole model in miniature. The agent's authority is organisational, drawn from a company wallet. The user's identity is personal, drawn from theirs. Neither party has to trust a claim that cannot be checked.

What a business should do now

Decide which entity stands behind each agent. Before any technical work. If you cannot name the legal entity accountable for an agent's actions, you are not ready to give it a credential.

Write the authority down as scope, not as a role. "Customer service agent" is not a permission. "May read order status for orders placed by the authenticated customer" is. The credential carries the second kind.

Assume your recipient has no access to your systems. Design the proof for an outsider. If verification requires a call to your API, it will not work for the parties who most need it.

Build the organisational credential layer first. It is the prerequisite, and it has uses that pay for themselves before any agent is involved. Our beginner's guide to EU Digital Identity Wallets covers the groundwork, and EUDI intermediaries covers how you connect to it.

How Hovi helps

Hovi works across the Nordics and Baltics, and operates inside two of the ecosystems moving fastest.

Hovi Business Wallets let an organisation receive, manage and prove credentials, and sign with its wallet, in the cloud or on-premises. Issuance runs through Hovi Connect. Both are built on the EUDI standards that European Business Wallets are set to build on.

Moreover, Hovi is also part of the France Identité EUDI ecosystem and the German EUDI Wallet Deutschland sandbox, we can help you build and verify against real test wallets today, using Person Identification Data and age verification credentials, and issue Electronic Attestation of Attributes credentials into wallet units across the full credential lifecycle.

Want to explore business wallets and use-cases around them, schedule a meeting with us.

‍