Why AI Agent Standards Still Need Verified Identity

Official brand picture of Concordium
Official brand picture of Concordium

Need effective Web3 marketing?

Get on a free strategy call with Disence

We've helped 120+ Web3 teams launch effective KOL campaigns, build engaged communities, and acquire long-term users. Get 30 minutes of clarity without a pitch.

Book a free strategy call →

No commitment · We usually respond within 24h.

This article is for AI and Web3 developers, agent marketplace operators, and enterprise technology leaders who want to understand the difference between registering an AI agent and proving that it is authorised to act.

AI agents are already performing tasks on behalf of people. Every day, they schedule meetings, manage cloud service expenses, execute trades, and process payments on behalf of companies and individuals. The infrastructure supporting them has matured quickly, there are now established standards for how agents discover each other, communicate across platforms, build reputations, and settle transactions.

That infrastructure is genuinely useful, but there is a layer missing underneath all of it, one that the existing standards were not designed to provide.

What Current Standards Actually Do

To understand the gap, it helps to look at what the emerging agent stack actually covers.

Discovery standards like ERC-8004 give agents a consistent identity format on-chain. An agent registered under ERC-8004 gets a unique identifier that other agents and services can find and reference. It is the equivalent of a business listing: the entry confirms the agent exists and provides a point of contact.

  1. Communication protocols such as Anthropic's Model Context Protocol (MCP) and Google's Agent-to-Agent (A2A) standard define how agents exchange information and coordinate tasks. They solve the interoperability problem, making it possible for an agent built on one framework to work with an agent built on another.

  2. Reputation layers track an agent's behaviour over time. Transaction history, success rates, and peer ratings give counterparties a way to assess whether an agent is reliable before engaging with it.

  3. Payment protocols like Coinbase's x402 embed transaction capability directly into HTTP requests. An agent can discover a service, agree to a price, and pay in a single interaction without a human in the loop.

Together, these standards enable a functioning agentic economy.

The problem is not that they are poorly designed, but is that none of them were built to answer a different question entirely.

A Commercial Example: The Procurement Agent

Consider a straightforward business scenario.

A mid-size company deploys an AI procurement agent to source and pay for software tools. The agent identifies a suitable subscription service, negotiates a price, and initiates payment on behalf of the company.

From the supplier's side, the transaction arrives with a wallet signature and a registry entry confirming the agent exists. The agent may even carry a strong reputation score from previous successful transactions.

But the supplier cannot confirm whether the company actually authorised this specific agent to commit to this specific spend. They cannot verify that the person who controls the wallet is a real, legally identifiable employee of that company. They cannot check whether the agent's authority to spend is still active, or whether it was revoked after the employee who set it up left the business.

If the payment is disputed, or if the subscription turns out to be unauthorised, there is no mechanism inside the current standards to trace accountability back to a specific, verified party.

It is a structural gap that becomes more significant as autonomous agents handle larger transactions and operate across more sensitive domains.

The Missing Proof

What the agent stack currently provides is evidence of existence and capability. What it does not provide is proof of authority.

There is an important difference between these two things.

A registry entry proves that an agent was created and registered. A wallet signature proves that whoever holds the private key controls the agent. Neither of these proves that a real, verified person or company gave that agent permission to act in the way it is acting, that the permission covers the specific action being taken, or that the authority is still valid at the moment of the transaction.

In a low-stakes context, this gap is manageable. In regulated industries, enterprise procurement, financial services, or any domain where legal accountability matters, it is a serious problem.

Why a Wallet Signature Is Not Enough

It is tempting to assume that a wallet signature solves the authorisation problem. If an agent signs a transaction with a key, does that not prove that the key holder authorised it?

Not quite.

A wallet signature proves cryptographic control, it does not prove legal identity. The person controlling the key may not be who they claim to be. The key may have been compromised. The agent may be operating outside the permissions its owner intended to grant, and even if the key holder is exactly who they say they are, a wallet address alone does not connect to a verified legal entity in any way that a regulator, an auditor, or a counterparty in a dispute can rely on.

For many use cases, cryptographic control is sufficient. For anything touching regulated money, business contracts, or sensitive data, it is not.

The Three Questions No Registry Answers 

When an AI agent initiates a consequential action, three questions matter:

  1. Who created and authorised this agent? Not just who holds the key, but who, as a verified legal person or business, stands behind it and accepts responsibility for its actions.

  2. What is this agent permitted to do? Authority is not binary, a procurement agent may be authorised to spend up to a certain amount, in certain categories, with certain counterparties. None of the current standards carry that information in a verifiable form.

  3. Is that authority still active? Authorisations expire, get revoked, and change scope. An agent operating on a permission that was valid six months ago but has since been updated is a compliance risk.

There is currently no standard mechanism for counterparties to verify the current state of an agent's permissions.

These are not problems that better discovery or communication standards will solve. They require a verified identity layer that sits beneath the agent stack and provides cryptographic proof of authority, not just existence.

How Concordium Fills the Gap

Concordium builds AI infrastructure for the agentic economy on a blockchain where identity and auditable infrastructure are native to the protocol.

When a developer or business registers an agent on the Concordium Agent Registry, the agent receives a Verified by Concordium Badge. This badge is backed by zero-knowledge proof credentials that connect the agent to a verified human or business, one that has been checked against an accredited Identity Provider using real documentation.

The agent's authority, permissions, and credentials are encoded in the credential itself, not stored in a mutable database that can be updated without trace.

Critically, Concordium is designed to work alongside existing standards rather than replace them. The Agent Registry is ERC-8004 compatible. Any agent already registered under that standard, including those on Ethereum and Solana, can acquire a Verified Badge without migrating to a new chain. The identity layer sits beneath the existing agent stack, not on top of it.

The result is that a counterparty receiving a transaction from a Concordium-verified agent can confirm three things they could not confirm before: that a real, legally identifiable person or business stands behind the agent, that the agent has been granted authority to act, and that the credentials backing that authority were issued by an accredited provider and remain valid.

Privacy is preserved throughout. The badge does not expose the personal details of the human or business behind the agent, it just provides whatever proof was required to perform an action.

What This Means for Builders and Enterprises

For developers building agents that will operate in regulated environments or high-value commercial contexts, the practical implication is straightforward. The existing standards handle the infrastructure layer well. But any agent that will handle real money, real contracts, or real liability needs to carry verifiable proof of authority, not just a wallet signature and a registry entry.

For enterprise technology leaders, the question is simpler still. When an autonomous agent acts on your company's behalf, you need to be able to prove that you authorised it, what you authorised it to do, and that the authorisation was valid at the time. The current agent stack does not provide that. Concordium's identity layer does.

Open standards help agents interact. Verified identity establishes who authorised them and who stands behind their actions. Both layers are necessary. Right now, only one of them exists at scale.

Need effective Web3 marketing?

Get on a free strategy call with Disence

We've helped 120+ Web3 teams launch effective KOL campaigns, build engaged communities, and acquire long-term users. Get 30 minutes of clarity without a pitch.

Book a free strategy call →

No commitment · We usually respond within 24h.

Need effective Web3 marketing?

Get on a free strategy call with Disence

We've helped 120+ Web3 teams launch effective KOL campaigns, build engaged communities, and acquire long-term users. Get 30 minutes of clarity without a pitch.

Book a free strategy call →

No commitment · We usually respond within 24h.

OÜ LeadGenPro. Estonia, Harju maakond, Tallinn, Haabersti linnaosa, Vana-Rannamõisa tee 1h/1-14, 13516. Registered No: 17008709

© 2026

All rights reserved