AgentFacts: Verifiable Credentials for AI Agents
Cryptographically signed metadata documents that serve as resumes for AI agents — capabilities, trust scores, compliance attestations, and performance metrics in a single verifiable package.
The Trust Problem
When you hire a contractor, you check their resume, references, certifications, and track record. When an AI agent delegates a task to another agent, it needs the same kind of information — but verified cryptographically and available instantly.
Today's agent metadata is fragmented: A2A has Agent Cards at /.well-known/agent.json, MCP has server manifests, and custom platforms have
their own formats. None of these are cryptographically signed, none carry trust
attestations, and none support privacy-preserving lookups.
AgentFacts solve this by encoding agent metadata as W3C Verifiable Credentials — the same standard used for digital identities, academic credentials, and supply chain attestations. The result: agent metadata that is machine-readable, cryptographically verifiable, and interoperable across protocols.
Anatomy of an AgentFact
The AgentFacts schema organizes agent metadata into eight layers, each serving a distinct purpose in agent discovery and trust verification:
1. Identity & Naming
Unique machine ID, URN-based agent name, human-readable label, description, version. id, agent_name, label
2. Provider & DID Verification
Organization name, website, and optional Decentralized Identifier (DID) for cryptographic provider verification.
3. Network Endpoints
Static API URLs plus adaptive resolver configuration with geographic, load-balancing, and threat-shielding routing policies.
4. Technical Capabilities
Supported modalities (text, audio, video, image), streaming/batch support, authentication methods, and required OAuth scopes.
5. Functional Skills
Detailed skill definitions with input/output modes, language support, latency budgets, and token limits. This is what agents query when searching for capabilities.
6. Quality Evaluations
Performance scores, 90-day availability, audit timestamps, immutable audit trails (e.g., IPFS-pinned evidence), and auditor identification.
7. Telemetry & Observability
Real-time metrics: p95 latency, throughput (RPS), error rate, availability. Sampling rates and retention policies for transparency.
8. Certification & Trust
Certification level, issuing authority, issuance and expiration dates. Enables automated trust decisions based on third-party attestations.
Interactive · AgentFacts Schema Explorer
Click any layer to explore · Eight layers of verifiable agent metadata
AgentFacts vs. Agent Cards
A2A's Agent Cards and NANDA's AgentFacts share common DNA — both describe agent capabilities in machine-readable JSON. In fact, the AgentFacts schema maintains direct compatibility with Agent Card fields:
| Agent Card Field | AgentFacts Equivalent | Extended? |
|---|---|---|
| name | label | ✓ Compatible |
| description | description | ✓ Compatible |
| url | endpoints.static | + Adaptive resolver |
| skills | skills | + Latency, tokens |
| securitySchemes | capabilities.authentication | ✓ Compatible |
| Not available | evaluations | ★ NANDA only |
| Not available | certification | ★ NANDA only |
| Not available | telemetry | ★ NANDA only |
The key difference: AgentFacts go beyond technical metadata to include trust infrastructure — performance evaluations, certification status, audit trails, and real-time telemetry. These fields enable automated trust decisions that Agent Cards alone cannot support.
Cryptographic Verification
Every AgentFact is signed using Ed25519 keys with versioned key rotation, following the W3C Verifiable Credentials data model. This means:
- Tamper evidence — any modification to the document invalidates the signature
- Non-repudiation — the agent's operator provably issued the claims
- Selective disclosure — agents can reveal only the fields relevant to a specific interaction, keeping sensitive metadata private
- Third-party attestations — auditors, certification bodies, and other agents can add their own signed claims to an AgentFact
This is fundamentally different from A2A's Agent Cards, which are served as plain JSON from a well-known URL. There's no way to verify that an Agent Card hasn't been modified in transit or that the claims within it are backed by the stated authority.
Real-World Trust Decisions
Consider a scenario: your enterprise orchestrator needs to delegate a sensitive document analysis task. With AgentFacts, it can programmatically verify:
- Capability match — does the agent's
skillsarray include document analysis with text and image input modes? - Performance SLA — is p95 latency under 200ms? Is 90-day availability above 99.9%?
- Certification — has the agent been audited by a recognized authority? When does the certification expire?
- Jurisdiction — is the agent compliant with GDPR/HIPAA requirements for the data being processed?
- Provider trust — does the DID resolve to a known, verified organization?
All of this happens automatically, in milliseconds, without human intervention. The AgentFact document provides everything needed for an informed, auditable trust decision.
Getting Started with AgentFacts
The AgentFacts format is an open standard. To create an AgentFact for your agent:
- Start with the AgentFacts specification and populate the required fields
- Register your agent in the NANDA Index to obtain an AgentAddr
- Sign the document with your Ed25519 key pair
- Host the signed AgentFact at a publicly accessible URL (referenced by your AgentAddr)