---
title: NANDA Index & AgentFacts Overview
url: https://www.emergentmind.com/topics/nanda-index-agentfacts
type: topic
---

# NANDA Index & AgentFacts Overview

NANDA Index AgentFacts denotes the discovery and trust substrate associated with the NANDA framework for autonomous AI agents. In its enterprise formulation, NANDA—“Networked AI Agents in a Decentralized Architecture”—addresses three infrastructure problems for agent ecosystems: global discovery, cryptographically verifiable capability attestation, and cross-protocol interoperability across Anthropic’s Modal Context Protocol (MCP), Google’s Agent-to-Agent (A2A), Microsoft’s NLWeb, and standard HTTPS. Within that framework, the NANDA Index functions as the discoverability layer, while AgentFacts are the verifiable metadata by which agents disclose identity, capabilities, security posture, compliance attributes, and protocol adapters. Related drafts present the same pair in a more explicitly federated or lean form, separating minimal index pointers from richer externally hosted facts and distinguishing discovery from subsequent dynamic endpoint resolution [2508.03101] [2507.14263] [2508.03113].

## 1. Concept and scope

The NANDA Index is described as a lightweight registry at the heart of the NANDA framework. It provides a Web interface for browsing agents and a REST API for programmatic access, supports Google OAuth authentication, and implements full CRUD operations with ownership controls. Functionally, it acts as a global discoverability layer where agents across heterogeneous protocol ecosystems register discoverable identities and capabilities, and where other agents can perform filtered queries that apply security, trust, and safety policies before initiating collaboration. AgentFacts are the associated verifiable claims that describe who an agent is and what it can do, and they are explicitly intended to prevent capability spoofing and impersonation by anchoring claims in signed, revocation-aware Verifiable Credentials [2508.03101].

A recurring source of confusion in the literature is whether the NANDA Index itself performs endpoint resolution. The AdaptiveResolver draft states the opposite: the index is for advertisement and discovery, not for the dynamic endpoint resolution itself, and discovery occurs before resolution. In that draft, a Requester Agent first obtains the Target Agent’s AgentFacts card from the NANDA Index and only then resolves the Target Agent Name to a context-tailored communication channel through a separate recursive and authoritative name-resolution path. The distinction is therefore architectural rather than terminological: the registry exposes capability-centric metadata, whereas adaptive resolution computes the communication endpoint under current environmental constraints such as geography, topology, load, QoS, cost, and security posture [2508.03113].

The name “NANDA” itself is not used identically in every paper. One paper expands it as “Networked AI Agents in a Decentralized Architecture,” while the AdaptiveResolver draft uses NANDA as the proper name of the overall approach and explicitly does not expand the acronym. This suggests an evolving architectural family rather than a single frozen specification, with a stable emphasis on federated discovery, verifiable metadata, and protocol heterogeneity [2508.03101] [2508.03113].

## 2. Architectural formulations and index layers

In the enterprise-oriented presentation, index records are keyed by agent identifiers anchored in Decentralized Identifiers (DIDs). The record ties an agent’s DID to its public keys, verifiable AgentFacts, and protocol endpoints. Human-readable names and tags support search and filtering, but the DID and associated keys are the authoritative cryptographic identity. The index can operate centrally, in decentralized mode with DID-anchored claims and federated trust zones, or in hybrid form. Discovery integrates third-party reputation and certification services whose credentials are cross-signed across trust zones, and lookup includes identity verification, capability attestation validation, policy filters, and protocol negotiation via adapters [2508.03101].

A second formulation, developed in the “lean index” papers, sharpens the separation between static index state and dynamic metadata. There, the index resolves an identifier to a compact signed pointer record, often called AgentAddr, which includes a facts URL, an optional private facts URL, an optional adaptive router URL, a TTL, and an Ed25519 signature. These records are described as lightweight, cacheable, and stable, with the specific claim that they are typically no more than 120 bytes. Richer AgentFacts documents, signed as W3C Verifiable Credentials v2 and often encoded as JSON-LD, are then hosted outside the index at agent-controlled domains or decentralized storage such as IPFS. Dynamic routing decisions are delegated to adaptive resolvers rather than encoded directly into index state [2507.14263] [2508.03095].

These two formulations are not identical in presentation. One places more emphasis on the index as an operational registry storing discoverable identities, public keys, AgentFacts, and protocol endpoints; the other emphasizes a minimal pointer layer and pushes richer metadata outside the index. A plausible implication is that the architecture is being articulated at multiple abstraction levels: an enterprise deployment model optimized for direct CRUD-style management, and a federated pointer model optimized for cacheability, privacy, and high-churn routing [2508.03101] [2507.14263].

## 3. AgentFacts as a verifiable metadata model

AgentFacts are stored as verifiable claims conforming to W3C Verifiable Credential v2. Each claim includes issuer metadata, signature, issuance time, expiry, and revocation pointers through VC-Status-Lists. In the enterprise schema, indicative fields include `agent_id`, `public_keys`, `capabilities`, `protocol_adapters`, `security_posture`, `compliance_tags`, `trust_certifications`, `reputation_scores`, `content_flags`, `issuer`, `issuance_time`, `expiry`, `revocation_pointers`, and `signature_metadata`. The facts are enriched with trust and safety attributes to support “Agentic SafeSearch” filtering, including kid-safe certifications, HIPAA attestations, reputation scores, and content flags such as “political,” “financial_advice,” and “adult_content” [2508.03101].

The schema is expressly capability-centric. `capabilities` enumerate structured, attested abilities such as `inventory.lookup` or `calendar.schedule`; `protocol_adapters` advertise available endpoints for MCP, A2A, NLWeb, and HTTPS; `security_posture` can encode claims about context sanitization, DLP enforcement, and isolation level; `compliance_tags` capture regimes such as “HIPAA,” “GDPR-ready,” and “OFAC-screened”; and `trust_certifications` and `reputation_scores` externalize third-party validation. The result is not merely descriptive metadata but a claim system intended to be machine-verified before interaction [2508.03101].

The lean-index papers widen the semantic envelope of AgentFacts. There, AgentFacts may additionally carry provider identity, endpoint classes such as static, rotating, and adaptive endpoints, authentication schemes, evaluations, telemetry, and certification blocks, with VC signatures and `credentialStatus` references. By contrast, the AdaptiveResolver draft is notably more conservative: it says AgentFacts are public, capability-centric metadata bundles used to discover agents by function and requirements, but it does not provide a formal schema or a concrete JSON or YAML example and defers OpenAPI and metadata design to future work. Across these accounts, the stable common core is identity, capability, endpoint disclosure, and contextual requirements; the degree of formalization varies by paper [2507.14263] [2508.03113].

## 4. Verification, trust computation, and the security model

The cryptographic model is explicit. In the enterprise paper, if $H(m)$ is a secure hash of message $m$, then signing is defined as $s = \mathrm{Sign}(sk, H(m))$, and verification succeeds when $\mathrm{Verify}(pk, H(m), s) = 1$. For attestation chains with multiple credentials and issuers, validation succeeds when every signature verifies, the trust root is satisfied, and no credential is marked revoked in its VC-Status-List. Operationally, the verification function resolves the issuer DID, verifies the signature on the AgentFacts core fields, checks revocation pointers, validates certification signatures and their status lists, aggregates reputation, and finally applies policy filters such as exclusions and required certifications [2508.03101].

Key management follows the same DID-based logic. Enterprises, consortiums, and federated certification authorities within domain-specific trust zones can act as issuers. Ed25519 and ECDSA are described as typical signing algorithms, and the agent’s DID document binds verification keys. Key rotation is handled by updated DID documents, new AgentFacts issuance, retirement of previous keys, and propagation through DID resolution and index metadata. Revocation is handled through VC-Status-List mechanisms rather than by altering the signed payload. The lean-index literature strengthens the temporal dimension by emphasizing short-lived credentials, often under five minutes, and sub-second revocation visibility through VC-Status checks and tight TTL policy [2508.03101] [2507.14263].

The security model is framed as Zero Trust Agentic Access (ZTAA), an extension of Zero Trust Network Access (ZTNA) to autonomous agents. It applies “never trust, always verify” to every inter-agent interaction and targets capability spoofing, impersonation, sensitive data leakage, and cross-protocol attack surfaces. Mitigations include cryptographically signed AgentFacts, bilateral authentication and verification through the index, least-privilege policy enforcement using skills, safety classifications, categories, reputation, isolation, and context sanitization, and DID-linked audit trails through Agent Visibility and Control (AVC). Newly Seen Agents (NSAs) are handled conservatively, with lower trust scores until sufficient verifiable history accrues [2508.03101].

Trust scoring is also formalized in the enterprise account as
$$
T(A) = w_c \cdot \mathrm{conf}(C_A) + w_p \cdot \mathrm{policy}(A) - w_r \cdot \mathrm{risk}(A),
$$
where attested capability confidence, policy compliance, and risk signals are combined with enterprise-specific weights. The broader AgentFacts literature generalizes the same idea into multi-authority validation: different authorities may validate security, regulatory, or performance claims separately, and trust becomes a policy-driven aggregation over independently signed sections. This does not define NANDA itself, but it clarifies why AgentFacts are treated as composable attestations rather than flat profile data [2506.13794].

## 5. Interoperability, discovery, and connection workflow

Cross-protocol interoperability is one of the defining functions of NANDA Index AgentFacts. The NANDA Adapter bridges MCP, A2A, NLWeb, and HTTPS. Protocol-specific descriptors embedded in AgentFacts indicate available endpoints; adapters normalize messages, map capabilities—such as MCP tools to A2A services or NLWeb intents—and negotiate session parameters. Message normalization is meant to convert tool and task descriptions and context payloads into canonical forms to avoid semantic mismatches across protocols, while negotiation selects the highest-assurance path based on `security_posture` and `compliance_tags` [2508.03101].

The enterprise workflow is specified as a four-stage pipeline. First, a client performs an index lookup with filters over capabilities, certifications, and content exclusions. Second, it retrieves AgentFacts, validates signatures and revocation state, and computes a trust score. Third, it negotiates protocol selection based on supported endpoints and enterprise policy. Fourth, it initiates a session through the adapter under least-privilege scopes and context sanitization, with AVC monitoring the task. The paper gives a concrete example: an MCP client searches the index for `inventory.lookup` while requiring `kid-safe-cert-v1` and excluding `political`, retrieves an A2A agent with valid AgentFacts, and the adapter maps the MCP invocation to the A2A endpoint while enforcing DLP and isolation according to the recorded security posture [2508.03101].

The AdaptiveResolver draft inserts a distinct name-resolution stage after discovery. Once the Requester Agent has obtained the Target’s AgentFacts card, it submits a Resolver Query containing the Target Agent Name and the Requester’s context to a recursive resolver in the Uniform Agent Locator (UAL) hierarchy. Referrals may be cached with TTLs. The Authoritative Name Server then examines current status of target and communications resources and returns a context-tailored URL, or, if trust or communication requirements are not yet satisfied, a negotiation invitation. Brokers on both sides may then gather metadata, agree on a Comms Spec, optimize placement, and only afterward establish communication. This separation makes explicit that discovery by capability and endpoint tailoring under environmental context are distinct stages [2508.03113].

The lean-index papers extend the same logic with endpoint classes and privacy options. AgentFacts may enumerate static endpoints with hour-scale TTLs, rotating endpoints with minute-scale TTLs, and adaptive-resolver paths issuing short-lived tokens. Clients choose between primary facts URLs and private facts URLs according to policy, cache AgentAddr and AgentFacts independently, and fall back from adaptive or rotating modes to static endpoints when necessary. This design is meant to absorb endpoint churn and load-balancing changes without incurring index write churn [2507.14263].

## 6. Governance, privacy, operational practice, and limitations

AVC gives NANDA Index AgentFacts an enterprise governance layer. It provides access to identity records, including name, DID, owner, and permissions; exposes performance history through completed tasks, timestamps, and durations; and permits operational control by activating, pausing, or terminating agent operations in real time. AVC enforces policy orchestration at discovery and session initiation, maintains observability and auditability across cross-protocol interactions, and implements privacy controls and DLP for context sharing, including MCP context validation and least-privilege sharing. Logs and telemetry are tied to agent DIDs and task timelines and are positioned as compliance-grade audit trails for billing, incident forensics, and regulatory reporting [2508.03101].

Operational guidance centers on caching, consistency, and conservative failure handling. Clients and gateways cache AgentFacts and resolver metadata with short TTLs; revocation and status checks consult issuer VC-Status-Lists on first use or at TTL expiry. The index aims for eventual consistency across federated trust zones, and real-time checks for newly seen agents are recommended in fast-changing environments. Suggested cryptographic parameters include Ed25519 or NIST P-256 ECDSA for signatures and SHA-256 for hashing. If DID resolution or status-list fetch fails, the recommended behavior is degraded trust with conservative policy, or blocking; for sensitive operations, fail-closed behavior is preferred. Failure modes include stale caches, unreachable status lists, and adapter negotiation failures, with re-verification required on reconnection [2508.03101].

Privacy is treated as a first-class concern rather than a side effect. In the lean formulation, dual-path discovery uses a `PrivateFactsURL` hosted on neutral or decentralized infrastructure so that clients can fetch metadata without touching the agent’s domain. The papers explicitly present this as privacy-preserving discovery across organizational boundaries and as support for least-disclosure queries. However, they also state that zero-knowledge proofs and selective disclosure are not core mechanisms of current NANDA drafts; privacy is achieved primarily through dual-path resolution, short-lived credentials, careful hosting choices, and, where feasible, selective disclosure within the VC ecosystem [2507.14263] [2508.03095].

The limitations are equally explicit. Protocol heterogeneity across MCP, A2A, NLWeb, and HTTPS is still evolving; richer and more standardized capability taxonomies and adapter semantics are needed to reduce mismatch and ambiguity. Federated trust zones, cross-signing, and unified reputation signals are early-stage; NSAs remain difficult because they have limited history. Real-time verification and revocation checking add latency and operational overhead. Common schemas for isolation, DLP, and context sanitization are not yet standardized enough to make posture claims fully comparable and enforceable. A related extension in the NANDini ecosystem adds an optional `data_facts_url` pointer to Agent Facts so that agents can advertise dataset identity, freshness TTL, integrity checksum, and tiered access paths, indicating one likely direction for future expansion beyond agent identity and capability claims alone [2508.03101] [2606.26211].

Source: https://www.emergentmind.com/topics/nanda-index-agentfacts