AgentFacts: Verifiable AI Agent Metadata

• AgentFacts is a verifiable metadata construct for AI agents that binds unique agent IDs, claimed capabilities, and governance details via cryptographic proofs.
• It employs JSON-LD, W3C Verifiable Credentials, and dynamic endpoints with TTLs to ensure rapid revocation, freshness, and seamless discovery.
• AgentFacts underpins zero trust access and enterprise governance by enabling validated, policy-driven agent discovery and runtime verification.

Searching arXiv for papers on AgentFacts and NANDA to ground the article in current literature. AgentFacts is a metadata and credential construct for AI agents that has emerged in recent work on agent registries, decentralized discovery, and enterprise governance. In the NANDA line of work, AgentFacts denotes a cryptographically verifiable record that binds an agent identifier to claimed capabilities, governance metadata, and signatures or proofs, so that other agents and administrative systems can discover, authenticate, and policy-check the agent before collaboration (Wang et al., 5 Aug 2025). Related formulations generalize the concept into a broader “Know Your Agent” standard for enterprise deployment, where AgentFacts becomes a universal metadata schema with independently verified sections, dynamic permissions, and multi-authority validation (Grogan, 11 Jun 2025). Across these formulations, the unifying idea is that agent interaction should not rely on unverifiable self-description: the agent’s identity, endpoints, capabilities, status, and compliance-relevant attributes are represented as signed, machine-readable facts that can be resolved, checked, revoked, and audited.

1. Definition and conceptual scope

In the NANDA framework, an AgentFacts record is defined as a cryptographically verifiable credential binding four elements: the agent’s unique identifier, described as a Decentralized Identifier (DID); a structured set of claimed capabilities; metadata for governance; and a digital signature issued by a recognized Certification Authority (Wang et al., 5 Aug 2025). The same paper assigns three primary roles to AgentFacts: global discovery, capability verification, and enterprise governance through Agent Visibility and Control (AVC) (Wang et al., 5 Aug 2025).

A complementary formulation appears in work on the NANDA index architecture, where AgentFacts is described as a self-describing JSON-LD bundle containing a stable agent identifier, pointers to dynamic metadata such as endpoints and capabilities, cryptographic assertions, and policy hooks including time-to-live and adaptive resolvers (Raskar et al., 18 Jul 2025). In that formulation, AgentFacts is not merely a credential payload but a dynamic metadata layer that sits atop a minimal index and supports routing, privacy-preserving access, and schema-validated capability assertions (Raskar et al., 18 Jul 2025).

A broader enterprise-oriented formulation is given by the “Know Your Agent” framework, which defines AgentFacts as a universal metadata standard for verified AI agent metadata and deployment (Grogan, 11 Jun 2025). That specification places AgentFacts in direct analogy with “Know Your Customer” processes, but for software agents rather than human or institutional counterparties. Its objective is to replace unverifiable self-declared capabilities and ad hoc integration with standardized, cryptographically signed capability declarations, multi-authority validation, and dynamic permission management (Grogan, 11 Jun 2025).

These definitions are compatible rather than contradictory. They suggest that “AgentFacts” functions at once as a credential, a metadata document, and a trust substrate for agent ecosystems. A plausible implication is that the term is best understood not as a single fixed schema, but as a family of interoperable patterns for verifiable agent description.

2. Core data model and schema design

The NANDA enterprise perspective represents AgentFacts as a W3C Verifiable Credential v2, typically serialized as JSON-LD and containing a JSON Web Signature (Wang et al., 5 Aug 2025). In abstract form, the record is written as

$$\mathsf{AF} =\bigl\{ \mathit{agent\_id}, \mathit{capability\_claims}, \mathit{governance\_metadata}, \sigma_{CA}(\mathit{agent\_id}\|\mathit{capability\_claims}\|\mathit{governance\_metadata}) \bigr\}.$$

To prevent replay and provide freshness, the signed payload may additionally include a timestamp $t$ and nonce $n$ (Wang et al., 5 Aug 2025).

The “Beyond DNS” architecture provides a more elaborated typed tuple: $$\mathit{AgentFacts} = \bigl( \mathit{id}:\mathsf{UUID}, \mathit{agentName}:\mathsf{URN}, \mathit{endpoints}:\mathcal{E}, \mathit{capabilities}:\mathcal{C}, \mathit{telemetry}:\mathcal{T}, \mathit{certs}:\mathcal{V}, \mathit{ttl}:\mathbb{N}, \mathit{signature}:\mathsf{Sig} \bigr)$$ with endpoints typed as static, rotating, or adaptive, and certificates modeled as W3C Verifiable Credential envelopes (Raskar et al., 18 Jul 2025). This representation emphasizes endpoint dynamism, observability hooks, and metadata-level time-to-live. It also encodes relationships between credentials and capabilities via JSON-LD @id references (Raskar et al., 18 Jul 2025).

The registry-comparison paper presents a concrete JSON-LD fact model carried inside a W3C VC envelope, usually 1–3 KB in size (Singh et al., 5 Aug 2025). Its credentialSubject includes agent DID, an array of capabilities, endpoint descriptions grouped into static, rotating, and adaptive, authentication schemes, and optional compliance assertions such as HIPAA or FDA-SaMD (Singh et al., 5 Aug 2025). It also includes credentialStatus for revocation and a proof object, for example an Ed25519Signature2018 proof (Singh et al., 5 Aug 2025).

The enterprise KYA proposal extends the scope beyond these registry-focused schemas. It defines a universal superset schema with ten core sections: identity, model, classification, capabilities, authentication and dynamic permissions, compliance, performance, supply chain, verification, and extensibility (Grogan, 11 Jun 2025). In that formulation, the complete AgentFacts document $M$ is partitioned into sections $S_1,\dots,S_{10}$, and each section can be signed or validated independently by specialized authorities (Grogan, 11 Jun 2025).

The following table summarizes the major schema emphases across the principal formulations.

Work	Primary representation	Distinctive schema emphasis
NANDA enterprise (Wang et al., 5 Aug 2025)	W3C VC v2 / JSON-LD / JWS	DID, capabilities, governance metadata, CA signature
Beyond DNS (Raskar et al., 18 Jul 2025)	JSON-LD tuple with signature	Dynamic endpoints, telemetry, TTL, adaptive resolvers
Registry evolution (Singh et al., 5 Aug 2025)	JSON-LD VC envelope	Capability arrays, endpoint classes, auth schemes, compliance
KYA standard (Grogan, 11 Jun 2025)	Universal sectioned metadata document	Ten core sections, multi-authority validation, dynamic permissions

This schema variation reflects different deployment priorities. Registry-centric papers prioritize resolution, discovery, and revocation, whereas the KYA specification emphasizes procurement, governance, and section-wise confidence assessment.

3. Cryptographic attestation and verification semantics

Cryptographic verifiability is the defining property that distinguishes AgentFacts from ordinary service descriptors. In the NANDA enterprise formulation, verification proceeds by extracting the signed concatenation of agent_id, capability_claims, and governance_metadata, then checking the signature against the CA’s public key, resolving the DID, and consulting a VC-Status-List for revocation (Wang et al., 5 Aug 2025). The verification condition is given as

$$\mathsf{VerifyCA}(\mathsf{AF}) : \mathrm{Verify}\bigl(\sigma_{CA},\mathit{agent\_id}\|\mathit{capability\_claims}\|\mathit{governance\_metadata}\bigr)=\mathsf{true}.$$

The same work states that NANDA uses Ed25519 or ECDSA-secp256r1 with SHA-256 and a JSON-LD canonicalization profile for deterministic signing (Wang et al., 5 Aug 2025).

The “Beyond DNS” paper likewise centers Ed25519, both for AgentFacts and for the smaller AgentAddr index records (Raskar et al., 18 Jul 2025). It specifies signature generation over canonical JSON-LD serialization and verifies signatures under the owner’s public key (Raskar et al., 18 Jul 2025). It also introduces short-lived public key lists and describes key rotation through publication of new AgentFacts documents with low TTL values, including TTL as low as 30 seconds for rotating metadata (Raskar et al., 18 Jul 2025).

Revocation is treated as a first-class requirement. The NANDA architecture paper claims sub-second revocation and key rotation as one of its five guarantees, using VC-Status-List root updates published every $\ll 1$ second (Raskar et al., 18 Jul 2025). The registry-comparison paper describes sub-second revocation checks through credentialStatus pointing to a StatusList2021 VC, with clients fetching the relevant bitstring credential and checking the indexed bit for revocation (Singh et al., 5 Aug 2025).

The KYA proposal generalizes attestation beyond a single issuer. For a section $S_j$, a validating authority $A_i$ signs

$t$0

where $t$1, $t$2 specifies validated sections, and $t$3 is the signing timestamp (Grogan, 11 Jun 2025). Verification is then defined by a section-level predicate that checks the signature over the hashed section, scope, and timestamp (Grogan, 11 Jun 2025). This section-wise structure allows different authorities to sign different portions of the metadata rather than requiring a unitary root of trust.

The security properties explicitly claimed for AgentFacts in NANDA are integrity, authenticity and non-repudiation, freshness, revocation checking, and fine-grained trust decisions based on governance metadata (Wang et al., 5 Aug 2025). The paper further states that these properties mitigate capability spoofing, impersonation, and traffic diversion by binding capabilities to issued signatures, agent identifiers to DIDs, and peer keys to DID resolution (Wang et al., 5 Aug 2025).

4. Discovery, resolution, and protocol interoperability

AgentFacts is closely tied to agent discovery infrastructure. In NANDA, agents register AgentFacts with the NANDA Index, described as a lightweight global registry, so that they can be discovered across heterogeneous protocols (Wang et al., 5 Aug 2025). The same work depicts a layered architecture in which the index stores AgentFacts, ZTAA modules retrieve and verify them at connection time, and AVC consoles audit them for governance purposes (Wang et al., 5 Aug 2025).

The “Beyond DNS” paper sharpens the architectural separation between a lean index and richer facts documents (Raskar et al., 18 Jul 2025). The index stores only static, cacheable AgentAddr records of size $t$4 B: $t$5 Resolution proceeds by looking up AgentName → AgentAddr, verifying the signature on AgentAddr, and then choosing one of several paths: direct endpoint use, metadata fetch through facts_url or private_facts_url, or adaptive routing through an adaptive resolver (Raskar et al., 18 Jul 2025). This design keeps the index minimal while off-loading dynamic detail to AgentFacts documents.

The registry-comparison paper describes an analogous two-layer flow in which a resolver first retrieves an AgentAddr record from a lean index, verifies it, selects either FactsURL or PrivateFactsURL, fetches the AgentFacts VC, verifies its proof, checks revocation, and then uses the capabilities and endpoints found in credentialSubject (Singh et al., 5 Aug 2025). That paper argues that the index layer need only trust the DID document, not a centralized gatekeeper (Singh et al., 5 Aug 2025).

Cross-protocol interoperability is central to the NANDA enterprise paper, which gives protocol examples for Anthropic MCP, Google A2A, Microsoft NLWeb, and standard HTTPS/REST (Wang et al., 5 Aug 2025). In each case, AgentFacts is transmitted during handshake or retrieved over HTTP, then unpacked and validated by the receiving adapter before the extracted capabilities are bound into the local ZTAA policy engine (Wang et al., 5 Aug 2025).

The interoperability argument is comparative as well as constructive. The registry-survey paper evaluates AgentFacts alongside MCP Registry, A2A Agent Cards, AGNTCY Agent Directory Service, and Microsoft Entra Agent ID, using the dimensions of security, authentication, scalability, and maintainability (Singh et al., 5 Aug 2025). Its treatment of AgentFacts emphasizes end-to-end cryptographic binding, decentralized identifiers, small AgentAddr records, TTL-based caching, and forward-compatible JSON-LD contexts (Singh et al., 5 Aug 2025). This suggests that AgentFacts is intended not to replace all registry forms, but to serve as a high-assurance, interoperable fact model among competing registry architectures.

5. Governance, zero trust, and enterprise policy

A major strand of the literature treats AgentFacts as an enforcement surface for zero-trust collaboration. In NANDA, AgentFacts underpins Zero Trust Agentic Access (ZTAA), which extends Zero Trust Network Access to autonomous-agent interactions (Wang et al., 5 Aug 2025). Under this model, agents operate under a “never trust, always verify” principle by retrieving and validating AgentFacts on every new connection (Wang et al., 5 Aug 2025). Capability verification is therefore not a one-time onboarding event but a runtime requirement.

The same paper places AgentFacts within an enterprise governance layer called Agent Visibility and Control (Wang et al., 5 Aug 2025). IT administrators inspect and audit AgentFacts to enforce policy, such as blocking agents lacking a required certification, and can pause, terminate, or throttle agent behavior (Wang et al., 5 Aug 2025). Governance metadata may include trust certifications, reputation scores, and content flags, which are then interpretable by policy engines (Wang et al., 5 Aug 2025).

The KYA proposal systematizes this governance function by introducing a trust policy engine that computes aggregate confidence per section (Grogan, 11 Jun 2025). If $t$6 is the confidence score associated with authority $t$7’s signature and $t$8 the authority weight, the aggregate confidence for section $t$9 is

$n$0

and section $n$1 is accepted if

$n$2

for a consumer-defined threshold $n$3 (Grogan, 11 Jun 2025). This formalizes graded trust rather than binary acceptance. It also permits distinct organizational risk tolerances across sections such as compliance, performance, or supply chain provenance.

Dynamic permission management is another governance extension. The KYA specification models permissions as tuples over agents, resources, actions, scopes, and temporal intervals, with a time-dependent permission matrix $n$4 describing whether a permission is active at time $n$5 (Grogan, 11 Jun 2025). It also gives an LTL safety property,

$n$6

to enforce separation of duty unless explicit escalation occurs (Grogan, 11 Jun 2025). This links agent metadata to runtime authorization semantics.

The practical enterprise deployment scenario in the NANDA enterprise paper illustrates the governance role concretely. A “Sales AI Assistant” discovers and verifies the AgentFacts of external agents such as PricingAgent, InventoryAgent, and EmailCampaignAgent, confirms capabilities and flags such as “OFAC-compliant,” binds peer public keys into TLS or MCP channels, and interacts while the AVC dashboard logs lookups, tracks task durations and billing, and can revoke AgentFacts if compliance issues arise (Wang et al., 5 Aug 2025). The significance of this example lies less in the application domain than in the explicit coupling of metadata verification, connection establishment, policy enforcement, and auditability.

6. Privacy, dynamism, and contested design questions

Although AgentFacts is frequently presented as a verification mechanism, several papers stress that it must also support privacy-preserving disclosure and highly dynamic updates. The “Beyond DNS” paper lists privacy-preserving discovery across organizational boundaries via verifiable, least-disclosure queries as one of its five guarantees (Raskar et al., 18 Jul 2025). It formalizes a fetchFacts operation returning only a subset of fields allowed by policy and describes private_facts_url, proxy or mix-net retrieval, selective field encryption, and zero-knowledge-proof-based disclosure as mechanisms for limiting exposure (Raskar et al., 18 Jul 2025). The formal guarantee states that clients should learn only fields $n$7 permitted by policy $n$8, and that two queries by the same client to private_facts_url should not be correlatable except through TTL expiration leaks (Raskar et al., 18 Jul 2025).

The registry-comparison paper presents a more conservative privacy model. It does not specify zero-knowledge proofs in the current design, though it notes that selective-disclosure schemes such as BBS+ could be layered into future versions (Singh et al., 5 Aug 2025). It instead emphasizes dual-path hosting through public FactsURL and access-controlled PrivateFactsURL, short-lived credentials, and TLS to reduce leakage of access patterns (Singh et al., 5 Aug 2025). This difference marks an important design tension: one branch of the literature treats advanced privacy mechanisms as core guarantees, while another treats them as possible extensions to a simpler VC-based architecture.

Dynamism is addressed through TTLs, rotating endpoints, adaptive resolvers, and concurrent update protocols. The “Beyond DNS” paper equips dynamic parts of AgentFacts, specifically endpoint and credential sets, with a Last-Write-Wins set CRDT (Raskar et al., 18 Jul 2025). With state

$n$9

where $$\mathit{AgentFacts} = \bigl( \mathit{id}:\mathsf{UUID}, \mathit{agentName}:\mathsf{URN}, \mathit{endpoints}:\mathcal{E}, \mathit{capabilities}:\mathcal{C}, \mathit{telemetry}:\mathcal{T}, \mathit{certs}:\mathcal{V}, \mathit{ttl}:\mathbb{N}, \mathit{signature}:\mathsf{Sig} \bigr)$$0 and $$\mathit{AgentFacts} = \bigl( \mathit{id}:\mathsf{UUID}, \mathit{agentName}:\mathsf{URN}, \mathit{endpoints}:\mathcal{E}, \mathit{capabilities}:\mathcal{C}, \mathit{telemetry}:\mathcal{T}, \mathit{certs}:\mathcal{V}, \mathit{ttl}:\mathbb{N}, \mathit{signature}:\mathsf{Sig} \bigr)$$1 are add and remove sets tagged by logical timestamps, two replicas merge by union: $$\mathit{AgentFacts} = \bigl( \mathit{id}:\mathsf{UUID}, \mathit{agentName}:\mathsf{URN}, \mathit{endpoints}:\mathcal{E}, \mathit{capabilities}:\mathcal{C}, \mathit{telemetry}:\mathcal{T}, \mathit{certs}:\mathcal{V}, \mathit{ttl}:\mathbb{N}, \mathit{signature}:\mathsf{Sig} \bigr)$$2 and an element remains present iff its latest add timestamp exceeds its latest remove timestamp (Raskar et al., 18 Jul 2025). The paper presents this as a convergence mechanism for decentralized hosts such as IPFS, CDNs, or S3 buckets, without requiring index writes for every update (Raskar et al., 18 Jul 2025).

Performance claims also shape the design debate. The adaptive resolver prototype described in the same paper reports median additional latency over DNS plus HTTPS of approximately 12 ms, $$\mathit{AgentFacts} = \bigl( \mathit{id}:\mathsf{UUID}, \mathit{agentName}:\mathsf{URN}, \mathit{endpoints}:\mathcal{E}, \mathit{capabilities}:\mathcal{C}, \mathit{telemetry}:\mathcal{T}, \mathit{certs}:\mathcal{V}, \mathit{ttl}:\mathbb{N}, \mathit{signature}:\mathsf{Sig} \bigr)$$3 ms, throughput of 10 k requests per second per instance at 2 vCPU, and end-to-end AgentName → ephemeral endpoint < 40 ms in 90% of trials, across 20 global points of presence (Raskar et al., 18 Jul 2025). These figures are presented to show that stronger metadata verification need not preclude low-latency resolution.

Several limitations recur across the literature. The KYA proposal identifies signature forgery or key compromise, replay of stale metadata, collusion by malicious authorities, unauthorized permission escalation, and metadata tampering in transit as central threat vectors, and responds with strong signatures, TTLs, monotonic version chains, public audit logs, revocation lists, and multi-authority aggregation (Grogan, 11 Jun 2025). This suggests that AgentFacts solves only part of the trust problem: verifiability of claims and revocability of credentials do not eliminate risk from compromised authorities or flawed policy configuration.

A further conceptual ambiguity concerns the boundary of the term itself. In the NANDA literature, AgentFacts refers to verifiable metadata for networked AI agents (Wang et al., 5 Aug 2025, Raskar et al., 18 Jul 2025, Singh et al., 5 Aug 2025). In other agent literatures, the term “facts” is used differently, for example as local observations in multi-agent reinforcement learning or as atomic long-term memory units for LLM agents (Fang et al., 2023, Yao et al., 18 Jun 2026). Those usages are semantically related in that they treat “facts” as structured units supporting agent reasoning, but they are not the same technical artifact. This distinction is important because it prevents conflation between registry-level agent metadata and internal memory or belief representations.

Taken together, the literature presents AgentFacts as a convergent answer to a specific infrastructural problem: how autonomous agents can be discovered, identified, and admitted into collaboration under explicit, machine-verifiable trust conditions. The concept spans lightweight index architectures, W3C VC-based credentialing, zero-trust runtime verification, enterprise governance, privacy-preserving discovery, and multi-authority confidence aggregation (Wang et al., 5 Aug 2025, Raskar et al., 18 Jul 2025, Singh et al., 5 Aug 2025, Grogan, 11 Jun 2025). The remaining open questions concern standardization pressure between competing schemas, operational complexity of revocation and privacy-preserving disclosure at scale, and the extent to which authority-weighted metadata can resist adversarial issuers or institutional trust failure.