Verana
Live on testnet
Why AI agents must have their own identity?
Verifiable Trust: services, organizations and AI agents proving who they are, with no central observer.
AI agents already act on our behalf.
None of them can prove who they are.
Agents initiate connections, call tools and exchange personal data with no human in the loop. The counterparty's only signals today: a domain name and a padlock. That is transport security, not identity.
Every connection needs an answer at machine speed: who is this, and should data flow? Nobody is there to squint at the URL.
Agents can be impersonated, and can be deceived, at a scale and speed no human review process can catch.
Nothing binds an HTTPS endpoint, an MCP tool or an A2A peer to a legal entity that answers for it.
An agent's identity must prove three things. Its user's identity proves none of them.
Borrowed identity does not transfer. An agent is not its user, and a platform account is not accountability. An agent needs its own verifiable identity, carrying three provable statements:
A DID the agent controls: resolvable and verifiable by anyone, on any transport.
A verifiable credential binding it to the legal entity that answers for it.
Ecosystem accreditations scoping its roles and authorizations.
The obvious fix, a central agent registry, makes privacy worse.
If one platform vouches for every agent, that platform observes every interaction. In LINDDUN terms: linking, detecting, data disclosure, built into the architecture.
Serious work is underway. Each solves a slice.
| Approach | Who it is | Who operates it | What it may do | No central observer? |
|---|---|---|---|---|
| Enterprise agent IAM Entra Agent ID · Okta · AgentCore | Tenant-scoped ID | The tenant itself | Internal roles only | No: hub sees all |
| Agent directories A2A Cards · MCP Registry · AGNTCY · NANDA | Keys and names | Self-declared | Capability claims, unverified | Varies by host |
| Bot attestation Web Bot Auth (IETF) · CDN directories | Signed requests | Directory vouches | Binary: known bot | No: central directory |
| On-chain agent registries ERC-8004, mainnet Jan 2026 | Portable token ID | Pseudonymous | Reputation scores | Yes |
| Payment agent programs Visa TAP · Google AP2 mandates | Per-scheme ID | Registered with the network | Commerce only | No: scheme directory |
| Trust registry networks Ayra · TRQP · DeDi | Lists about issuers | Registry entries | Authorization lookups | Query-time lookup |
| Verana · Verifiable Trust | DID, any transport | Credential to a legal entity | Ecosystem accreditations, public and auditable | Yes: client-side |
Agent identity is not a special case. It is the same problem, again.
Verifiable Trust: verify before you connect.
Open, decentralized trust infrastructure. Ecosystems publish their rules, participants prove compliance with verifiable credentials, and anyone can check them without asking a central authority.
Rules, published
Machine-readable governance: credential schemas, participant roles, who is accredited to issue or verify what.
Proof, not reputation
Peers present DIDs and credentials, and run Proof-of-Trust in both directions before any data flows.
Discovery, ranked by trust
Find services and agents by the credentials they hold, through APIs or MCP.
An ecosystem defines what trust means in its domain.
An ecosystem is a community that defines what trust means in its domain. Anyone can found one: a sector body, a company network, a government program.
Anchored to the ecosystem DID: versioned, resolvable, public.
JSON Schemas on the registry: what each credential must contain.
The participant tree: accreditations to issue and to verify, granted, delegated, revoked in public.
Anyone can create an ecosystem. Anyone can join one.
No gatekeeper grants the right to define trust. A sector body, a government program, a company network: each can publish its own ecosystem, and every actor chooses which to join.
Publish a governance framework, credential schemas and a business model. Your ecosystem exists.
As a grantor, an issuer, a verifier, or a holder: people, services, organizations, AI agents.
Join to be accredited, or to hold credentials.
Services, organizations, AI agents and people join ecosystems for two things:
The right to issue or to verify a credential schema, granted by the ecosystem.
Proof about yourself, issued by that ecosystem's accredited issuers.
Attach your credentials to your identity, in public.
Credentials and accreditations are linked to the DID itself: anyone who resolves the agent sees its proof, before any contact. This card is what resolution returns:
Published as verifiable presentations, attached to the agent's DID document.
No account, no API key: resolve the DID and the proof is there.
The same attachment works over MCP, A2A or plain HTTPS.
Agent
Acme Support Agent
AI Agent · MCP + A2A
Operated by
🇫🇷 Acme Corp SAS
RCS 512 345 678
Credentials held
Accredited as · participant roles
Trust resolution runs on the client. Nobody watches you verify.
Public proof is searchable proof.
Because credentials are attached in public, the whole network is indexable, ranked by verifiable trust instead of SEO.
Find services and agents by credentials held and who accredited them.
Verifiable trust signals from the graph, not popularity or ad spend.
APIs and MCP: agents resolve and choose counterparties before connecting.
Privacy by design, applied to trust itself.
Trust checks are local. No central broker learns who connected to whom, or when. The relationship graph is not collected anywhere.
Verifiable presentations disclose only the claims a governance rule requires. Selective disclosure is a protocol feature, not a policy promise.
The public registry holds ecosystem metadata only: service DIDs, schemas, accreditations. Personal data stays in wallets, off-ledger, erasable.
Issuers and verifiers are accountable through public, auditable accreditations, not through surveillance of the people who rely on them.
Normative requirements deserve a conformance tester.
The Verifiable Trust spec defines testable requirements: trust resolution before endpoint use, issuer and verifier authorization, connection acceptance rules. Ontology-driven constraint testing can verify that implementations respect them, and detect when they do not.
Does a Verifiable Service or Verifiable User Agent satisfy the applicable normative requirements? Pass, fail, evidence trace.
Endpoint used before trust resolution. Authorization check missing. Interaction continuing after a failed verification.
A Verifiable Trust ontology, in the spirit of BITO, turns spec requirements into SHACL-testable semantic and behavioral constraints.
An open spec is an invitation.
Run a LINDDUN pass on the Verifiable Trust spec with this interest group. Findings feed the spec directly, in the open.
Map credential schemas and ecosystem roles to the W3C Data Protection Vocabulary, building on this group's DPV work.
Build ODC-Tester conformance suites for Verifiable Trust implementations, alongside the proposed open source semantic tester initiative at Eclipse.
Verana
Thank you.
Questions, objections and threat models welcome. The trust layer of the internet should be built the way this community builds everything: in the open, on models.
