AI agent identity and blockchain: what it adds and what it does not
What already works without blockchain, what anchoring on Base with EAS and ERC-8004 will add, and which problems neither layer is going to solve.
The verifiable identity of an AI agent does not need blockchain to work: a signed W3C credential, published on a domain and revocable through a signed list, already lets anyone check who operates the agent and with what scope. What anchoring on a blockchain will add is something else, narrower and more useful than it is usually sold as: a history of issuances and revocations that third parties can check without depending on the issuer.
This article separates what already works, what is coming, and what neither layer is going to solve.
What already works today, without blockchain
The digital ID for AI agents rests on open W3C standards and conventional web infrastructure:
- An identifier
did:web:digitalcortex.tech:agents:<slug>published on the issuer's domain. - A W3C Verifiable Credentials 2.0 credential in
vc+jwtformat, signed with ES256, with the private key in Google Cloud KMS. - A fingerprint of the configuration: the SHA-256 hash of the agent's manifest.
- A 90-day expiry and revocation through W3C Bitstring Status List v1.0.
- Eight live public checks, with no sign-up, in the Argos verifier.
The credential binds an identity declaration to the hash of the registered manifest. The scope is signed at issuance. To detect a change of prompt, model or permissions outside that registry you have to check the effective configuration: the hash does not automatically observe external systems. Every approved change of scope requires reviewing and reissuing the declaration.
The gap that remains
There is a weak point, and it is worth naming without hedging: the history depends on the issuer. If tomorrow we wanted to make the trace of a credential that was valid in August disappear, we would have the technical ability to rewrite what we publish on our own domain.
A third party can check the current status, but cannot demonstrate for themselves what the credential said three months ago or exactly when it was revoked. For most everyday uses that is enough. For a dispute, it is not.
A signature protects the origin and integrity of a statement. An external registry can add timestamp evidence. Neither of those things, on its own, demonstrates how the agent behaves.
What anchoring on Base will add
The current layer does not need blockchain. The roadmap includes studying an anchor on Base with EAS and ERC-8004, with no committed date and no deployment on record. Before announcing it as live, NEXTAI will have to publish contracts, transactions and evidence. An external registry will be able to provide timestamp evidence; it will not prove that a declaration is true or that its limits are respected.
Specifically, the plan covers three pieces:
EAS attestations. Each issuance and each revocation will leave an attestation with a timestamp and a reference to the credential's content. Neither the full credential nor any personal data will be published: what gets anchored is the proof that something was issued or cancelled at a given moment.
ERC-8004 registry. The agent will be recorded in an on-chain registry designed for agent identity, so that the reference is readable by third-party systems and not only by our verifier.
A ninth check. The public verifier will go from eight checks to nine: validation of the anchor will be added, that is, that the status the issuer asserts matches the history anchored on chain.
There will be no associated token, no speculative mechanism and no cost to whoever verifies.
Why Base
For three practical reasons: low cost per transaction, which will allow every issuance and every revocation to be anchored without the spend dictating the 90-day renewal policy; mature attestation tooling, with EAS widely used; and settlement on Ethereum, which brings a recognised security anchor.
If the conditions changed, the architecture does not force anyone to stay: the credential remains a standard W3C credential, and the anchor is an extra layer, not a requirement for it to work.
Problem by problem: which layer solves it
| Question | Evidence | Reference status |
|---|---|---|
| Which issuer declares the identity? | Signed credential and DID | Public |
| What scope does it declare? | Signed fields of the issuance | Public |
| Does the registered manifest match? | Hash comparison | Queryable |
| Is the credential still accepted? | Validity and status | Queryable, with its cache policy |
| Is an action blocked in the connector? | Execution and rejection evidence | Has to be tested per integration |
| Is there an on-chain history? | Contracts and transactions | Roadmap |
| Is the reasoning correct or safe? | Evaluations and additional controls | Identity does not demonstrate it |
What blockchain does NOT solve here
This is where the sector tends to stretch the language, so it is worth being explicit.
The anchor will address attribution, scope and non-repudiation: who issued what, when, with what limits, and with no way to deny it afterwards. It will not address the model's alignment or its security. An agent can be perfectly identified, with its history anchored to the millisecond, and still behave in an unwanted way because the objective was badly specified.
An anchored self-declaration is still an assertion by the issuer. The anchor can make later alteration of the record harder; it does not attest that the assertion is true. A permission change outside the manifest can go unnoticed if there is no additional operational check.
That distinction between identity and operational control is the same one we set out in governance of autonomous agents, and the limits of the credential as an incident tool are in how to revoke a credential and stop an agent.
How to read the market's promises
When a provider mentions blockchain applied to AI agents, it is worth asking three things: what exactly is anchored, whether there is personal data on chain, and what can be checked today versus what is planned. With those three answers, most proposals sort themselves out.
Our policy and our formats are published in the agentic identity policy and in the technical documentation. What is in production can be checked; what is planned, we label as planned.
Frequently asked questions
Do you need blockchain to have verifiable agent identity?
No. The signed credential, the published DID, the manifest hash and the revocation list already let you verify who operates an agent and with what scope. The anchor will add a further guarantee about the history.
What are EAS attestations?
EAS is an on-chain attestation standard that allows signed statements to be recorded with a timestamp. Applied here, it will serve to record when a credential was issued or revoked without publishing its full content.
Will personal data be published on chain?
No. The credentials contain no personal data about individuals, and what will be anchored are references and timestamps, not the full content of the credential or any client information.
Will there be a token or a cost for whoever verifies?
No. There is no associated token and no speculative mechanism, and public verification will remain free and sign-up free.
What to do with this
- Separate what can be checked today from what a provider announces for the future, ourselves included.
- Start with the layer that already works: signed credential, published scope and revocation. The anchor is an improvement, not a foundation.
- Ask what exactly is anchored when someone mentions blockchain, and whether any personal data is involved.
- Do not confuse immutable with true. An immutable record protects the history, not the truth of the assertion.
- Separate identity from security. Neither of these layers replaces access controls or evaluation of the model.
Want to understand which part of this makes sense for your specific case? Talk to us.
Editorial update of 17 September 2026, produced with the support of AI tools and cross-checked against public documentation. It is not presented as an external audit.
Identity and execution: the scope of this explainer
The public checks describe the credential and its relationship with the registered manifest. They do not prove the authentication of whoever presents it, the state of each external permission, or that actions are actually blocked. See the published evidence and limits.