{"id":"89858395-3016-44de-a54a-23126fcda557","arxiv_id":"2508.03101","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A work-in-progress proposal for a global agent registry, cryptographically signed capability claims, and cross-protocol adapters for secure AI agent collaboration.","lead":"This draft proposes NANDA, a registry and verification layer that helps autonomous AI agents discover one another, prove their capabilities, and communicate across different protocols. It is an enterprise-oriented extension of earlier NANDA work, but it offers no implementation or evaluation to support its claims.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"AgentFacts signing proves assertion origin, not capability truth: corrupted or colluding issuers can certify malicious agents, so the claimed protection against capability spoofing collapses unless issuer vetting is made part of the architecture.","rationale":"The reader's weakest_assumption identifies the same load-bearing risk: cryptographically signed AgentFacts attest to what an issuer asserts, not to what an agent safely does. This is the most load-bearing concern because every claimed security benefit in the paper—prevention of capability spoofing, impersonation, supply-chain poisoning, and the ZTAA guarantees—depends on the truthfulness of signed claims. The paper has no mechanism for validating issuer behavior or connecting a signed credential to runtime capabilities, and the self-referential support chain (prior NANDA papers) does not strengthen this point. I considered whether the absence of implementation or evaluation is the more fundamental weakness, but the reader already conditions the verdict on that; the issuer-trust issue is more precise and would remain even if a full implementation were supplied, unless the implementation explicitly adds runtime validation or honest-issuer assumptions. I also considered the cross-protocol interoperability claim, since no protocol translation semantics are given; however, that claim is more clearly a design sketch and would be settled by an implementation, whereas the security claim is stated as a prevention guarantee and is internally unsupported by the architecture itself. Therefore the reader's conditional verdict is appropriate, and no verdict change is needed.","tokens_in":8444,"tokens_out":3896,"duration_ms":53875,"concrete_test":"Deploy the NANDA Index and a test VC issuer configured as trusted. Register a benign agent with an accurate AgentFacts credential, then register a deliberately malicious agent with an equally well-formed credential from a colluding test issuer that falsely asserts a safe, high-reputation capability. Run the consumer discovery and verification flow described in §4.2 exactly as specified, including signature verification, DID resolution, and revocation checks, and record whether the malicious agent is accepted. If it passes all checks, the architecture does not detect capability spoofing when issuers are untrustworthy, and the only remaining defense would be out-of-band issuer reputation, which the paper does not specify. An independent code review of the NANDA Index should also confirm that no runtime capability validation is performed beyond credential verification.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3.1 claims that AgentFacts prevent capability spoofing, impersonation, and supply-chain poisoning through W3C Verifiable Credential v2 attestation, issuer DIDs, and VC-Status-List revocation. Section 6.1 repeats this as the core of ZTAA. The verification chain checks only that a claim was cryptographically signed by an issuer and has not been revoked; it does not check that the signed statement is true of the agent's actual runtime behavior. If the issuer is malicious, compromised, or negligent, every NANDA check succeeds for a false capability claim. The paper says trust certifications and reputation scores come from 'trusted third-party entities' (§5), but it never defines how an entity becomes trusted, how issuers are audited, or how a signed claim is tied to verified runtime behavior. The 'Newly Seen Agents' discussion in §6.1 acknowledges that agents with limited verifiable information are risky, but that is a different failure mode: NSAs may lack credentials, whereas the weakness here is that valid credentials can certify falsehoods. The load-bearing assumption is therefore that issuers are honest and competent; without it, the claimed protections reduce to accountability mechanisms contingent on unstated issuer trust rather than a spoofing prevention guarantee.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper, marked as v0.1 work-in-progress, presents the NANDA Index as an infrastructure layer for autonomous AI agents in enterprise settings. It claims that NANDA provides global agent discovery, cryptographically attested capability metadata through AgentFacts, cross-protocol interoperability among MCP, A2A, NL Web, and HTTPS, and security mechanisms built on Zero Trust Agentic Access (ZTAA) and Agent Visibility and Control (AVC). The paper motivates the design through an analogy to DNS and TLS for the traditional web, and it illustrates the architecture with enterprise use cases such as a sales and marketing assistant. The central assertion is that NANDA plus AgentFacts would prevent capability spoofing, impersonation, and supply-chain attacks while enabling seamless cross-framework agent communication. The text also discusses governance and compliance considerations, including OFAC and GDPR.","tokens_in":8704,"tokens_out":3287,"duration_ms":43324,"significance":"If the described architecture were implemented and validated, it would address a real and timely problem: the fragmentation of agent communication protocols and the lack of verifiable discovery mechanisms for autonomous agents. The paper's strengths are its clear web-to-agent analogy, the concrete enterprise scenario centered on Figure 5, and the security taxonomy in Table 1 that contrasts web security practice with agentic requirements. The paper explicitly engages with relevant standards such as W3C Verifiable Credentials and DIDs. However, the core claims are presently unsupported by any implementation, experiment, or independent evaluation, and the security model rests on an unexamined trust assumption about credential issuers. The paper would be more persuasive as a design proposal with clearly scoped claims, or as a systems paper with empirical validation.","major_comments":[{"comment":"The verification chain described in Section 3.1 validates that an AgentFact was cryptographically signed by an issuer and has not been revoked, via W3C Verifiable Credential v2, DID resolution, and VC-Status-List. It does not validate that the signed capability claims correspond to the agent's actual runtime behavior. As written, a malicious, compromised, or negligent issuer can issue valid AgentFacts for a misbehaving agent, so the stated prevention of capability spoofing and impersonation is not established. Section 6.1 repeats this as the core of ZTAA but adds no mechanism for issuer accreditation, audit, or behavioral attestation. The paper should either specify such a mechanism or weaken the claim from 'prevents capability spoofing' to 'provides accountability contingent on issuer trust.'","section":"§3.1, §6.1"},{"comment":"The load-bearing claims that 'the NANDA Adapter subsequently establishes actual communication channels, automatically configuring protocol translations' and that NANDA operates as a global discoverability layer are stated as implemented, but the manuscript provides no system description, no protocol translation specification, no interoperability tests, and no deployment evidence. The paper is labeled a draft and a 'framework' in the abstract, yet Section 3.1 says 'NANDA has developed a comprehensive infrastructure.' The authors should either report an implementation and evaluation or explicitly reposition the paper as a design proposal with those claims identified as future work.","section":"§3.1, §4.2, §8"},{"comment":"The claim that NANDA has developed a comprehensive infrastructure for preventing spoofing, impersonation, supply-chain poisoning, Sybil attacks, and traffic diversion is supported primarily by references [5] and [6], both of which share multiple authors with this paper and appear to be companion or prior descriptions of the same framework. This is not independent evidence. The paper should cite independent implementations, third-party audits, or experimental results to substantiate the operational claims.","section":"§3.1, References [5], [6]"},{"comment":"The subsection on Newly Seen Agents (NSAs) acknowledges that agents with limited verifiable information present 'significant risk factors,' but it does not describe any concrete mitigation strategy. It states that 'development and implementation of effective risk mitigation strategies becomes critical' without proposing one. Since NSA handling is part of the ZTAA security model and the paper claims enterprise readiness, the absence of any proposed defense is a load-bearing gap. The authors should either provide a mitigation approach or explicitly list NSA handling as open work.","section":"§6.1"}],"minor_comments":[{"comment":"The abstract refers to Anthropic's 'Modal Context Protocol'; the correct name is Model Context Protocol (MCP). This typo also appears in Section 3.1.","section":"Abstract"},{"comment":"Several typos appear in the figure text: 'domaim' should be 'domain', 'Azsue' should be 'Azure', and 'with the desire performance' should be 'with the desired performance'. The figure is also difficult to read because of inconsistent capitalization and punctuation.","section":"Figure 1"},{"comment":"The URI scheme 'ans://a2a/fin-consultant/openai/v3' is introduced without explanation. The reader cannot tell whether this is a proposed NANDA scheme, an example of a structured agent address, or a standard scheme used elsewhere.","section":"Figure 3"},{"comment":"The acronym 'A VC' is inconsistently spaced; it appears as 'A VC' in some places and 'AVC' in others. Please standardize.","section":"Throughout"},{"comment":"The bullet list of 'trust certifications' and 'reputation scores' says these come from 'trusted third-party entities' but does not define how those entities become trusted. This is related to Major Comment 1 and should be clarified in the text.","section":"Section 5"}],"recommendation":"major_revision","confidential_remarks":"The paper is a position/RFC-style draft rather than a full systems paper. Its central claims about an existing infrastructure are not backed by implementation or evaluation. The heavy reliance on self-cited companion work [5,6] for the core 'has developed' claim deserves careful editorial scrutiny. I would suggest the editors consider whether the venue's standards require empirical validation for infrastructure claims, and if so, require the authors to either add it or restructure the paper as an explicit design/vision paper."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You'll get more from this as a position paper than as a result. The NANDA idea—global agent registry with cryptographically signed capability claims and adapters across MCP/A2A/NL Web—is clearly presented, and the DNS/TLS analogy is a helpful frame. What's new here is the enterprise packaging: ZTAA terminology, Agentic SafeSearch as policy-based filtering, and a realistic sales/marketing use case. Those are genuinely useful conceptual contributions.\n\nWhat it isn't is an implemented system. The text states \"NANDA has developed a comprehensive infrastructure\" (§3.1), but the evidence for that is the authors' own prior papers [5,6]. No code, no interoperability experiments, no security evaluation. The cross-protocol adapter claim is made as fact, yet no adapter behavior is shown. So treat every \"prevents\" as a design goal, not a measured property.\n\nThe load-bearing weakness is the trust model. AgentFacts being signed proves who issued the claim, not that the claim is true. A compromised or colluding issuer can certify a malicious agent as \"kid-safe\" or \"HIPAA-compliant,\" and all NANDA checks pass. The paper acknowledges Newly Seen Agents have limited information (§6.1), but that's a different failure: NSAs lack credentials, while the issuer-collusion case has valid credentials certifying falsehoods. Nothing in the paper defines issuer vetting, audit, or how a signed claim is connected to runtime behavior. Without that, the claimed protection against capability spoofing reduces to accountability-by-reputation, not a cryptographic guarantee.\n\nThat said, the paper doesn't hide its status—it's marked v0.1 Work in Progress/RFC—and the prose is readable. The issues are the usual ones for a systems proposal without a system: overclaiming implementation, self-referential support, and an unexamined root of trust.\n\nFor a reader surveying agent infrastructure, this is worth a skim; the ZTAA and SafeSearch framing might be reusable. For a researcher needing validated results, there is nothing here yet. I would not send it to a strict peer-reviewed venue in current form—it needs an implementation, a threat model, and an independent evaluation. As a workshop paper or RFC, it's appropriate.","headline":"Readable enterprise position paper for agent discovery and attestation, but it's a design sketch with no implementation and an unexamined issuer-trust assumption.","tokens_in":9255,"tokens_out":2236,"would_cite":false,"duration_ms":28393,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper proposes that a global registry of cryptographically attested capability claims can make AI agents discoverable, verifiable, and interoperable across today's fragmented protocols, and illustrates the architecture with an…","keywords":["NANDA Index","AgentFacts","agent discovery","cross-protocol interoperability","zero trust agentic access","verifiable credentials","A2A","MCP"],"falsifier":"A concrete test would be to take an agent with a validly signed AgentFacts credential, such as 'kid-safe' or 'HIPAA-compliant', and show that it can be prompted, directly or indirectly, to leak data or perform an action outside the attested capability; alternatively, show that an issuer can be induced to issue a false capability claim. Either result would break the paper's claim that AgentFacts prevent capability spoofing and impersonation.","tokens_in":8240,"feed_emoji":"🤖","tokens_out":7185,"duration_ms":72900,"temperature":0.7,"pith_summary":"The paper is trying to establish that autonomous AI agents need—and can have—an infrastructure layer like the one websites got from DNS and TLS: a global registry, the NANDA (Networked AI Agents in a Decentralized Architecture) Index, where agents register names and publish cryptographically signed AgentFacts describing who they are and what they can do. It argues this registry can serve as a universal discovery and handshake layer across today's incompatible agent protocols, including Anthropic's MCP, Google's A2A, Microsoft's NL Web, and plain HTTPS, with a NANDA Adapter translating between them so that agents on different stacks can actually communicate. The payoff would be that enterprises could deploy multi-agent workflows while verifying identity and capability before collaboration, reducing capability spoofing, impersonation, and sensitive data leakage. The paper also extends zero-trust thinking to agents through Zero Trust Agentic Access and defines governance controls such as real-time agent visibility and termination authority. It flags newly seen agents with little verifiable history as a significant remaining risk.","feed_headline":"Registry gives AI agents verifiable identity and cross-protocol reach","feed_subtitle":"NANDA Index plus AgentFacts could let MCP, A2A, and NL Web agents discover, verify, and trust each other.","key_machinery":"The load-bearing machinery is the triad of the NANDA Index, AgentFacts, and the NANDA Adapter. The Index is a lightweight registry/index system, described as a name-resolution system for agents, that stores cryptographic identifiers, capability descriptors, trust metadata, and audit logs, with a REST API and ownership controls. AgentFacts are the verifiable metadata claims that define an agent's identity and capabilities, signed as W3C Verifiable Credentials and linked to issuer DIDs with revocation status. The NANDA Adapter is the component that translates between MCP, A2A, NL Web, and HTTPS so that discovery through the Index becomes real cross-framework communication. The argument's work is distributed across these pieces: the Index provides global discoverability, AgentFacts provide verifiability and filtering, and the Adapter provides interoperability.","core_discovery":"On its own terms, the central claim is that the NANDA Index operates as a global discoverability layer where agents across heterogeneous protocols register and find each other, AgentFacts provide cryptographically verifiable capability attestation, and the NANDA Adapter establishes the actual communication channels by automatically configuring protocol translation. AgentFacts are claims requiring W3C Verifiable Credential v2 attestation, anchored to issuer Decentralized Identifiers (DIDs) with revocation managed through VC-Status-List mechanisms. The paper presents this as the agentic-web analogue of DNS plus a public certificate: a name-to-agent-address resolution step followed by capability and trust verification, after which ordinary encrypted transports carry the conversation. The claimed result is that an MCP-based assistant can work directly with an A2A inventory system or an NL Web calendar service, and that enterprises can filter agents by safety certifications, reputation scores, and content flags through structured index queries while administrators retain full visibility and kill-switch control over agent operations.","pith_inferences":["The architecture moves the hard trust problem to the credential issuers: it proves that a claim was attested, not that the attested capability is actually safe, so real-world security depends on issuer vetting, cross-signing policies, and reputation systems that the paper leaves mostly unspecified.","If the Index were opened widely, a natural audit experiment would be to sample registered AgentFacts, resolve their issuer DIDs, and check revocation status; a high rate of unreachable or stale issuers would signal that discoverability is outpacing verifiability.","The closest analogue to web PKI is also its cautionary tale: as trust zones cross-sign, a single compromised or careless issuer could vouch for malicious agents, so the framework may need something like certificate transparency logs for AgentFacts.","The NANDA Adapter's automatic protocol translation could become a new attack surface; a concrete extension of the paper would be a formal specification of how adapter-mediated requests stay authenticated end-to-end rather than only at each hop."],"forward_implications":["An MCP-based assistant could directly call an A2A inventory agent or an NL Web calendar service through the NANDA Adapter, ending protocol fragmentation.","Safety policies become queryable: a rule like 'exclude political content and require kid-safe certification' turns into structured NANDA Index API search against verifiable fields.","Enterprises gain audit and control: full agent identity records, performance history, and real-time pause or terminate authority over deployed agents.","Zero trust extends to agents: before collaboration, both sides verify identity, capability claims, location, and reputation, not just credentials.","Domain-specific trust zones could cross-sign each other's credentials, letting enterprises and consortiums vouch for agents by federation."],"supporting_citations":[{"why":"Introduces the NANDA Index and AgentFacts, the registry and verifiable-metadata objects the paper applies to enterprise use cases.","marker":"[6]"},{"why":"Supplies the W3C Verifiable Credential v2 and DID-attestation model that AgentFacts rely on.","marker":"[5]"},{"why":"Defines Anthropic's MCP, the tool-access protocol the paper bridges with the NANDA adapter.","marker":"[1]"},{"why":"Defines Google's A2A protocol, the horizontal agent-to-agent channel used in the enterprise use case.","marker":"[2]"},{"why":"Defines Microsoft's NL Web, the third protocol the NANDA Index claims to cover.","marker":"[3]"},{"why":"Provides the DNS concepts and name-resolution analogy on which agent-name-to-address resolution is modeled.","marker":"[4]"},{"why":"Establishes HTTP-over-TLS as the secure transport baseline for browser-website and assumed agent-agent sessions.","marker":"[7]"}],"fun_headline_variants":["AI agent registry adds verifiable identity and cross-protocol links","NANDA Index: DNS for AI agents, with verified claims","AgentFacts enable trust across MCP, A2A, and NL Web","Decentralized agent registry with cryptographically attested capabilities","Global discovery and attestation for interoperable AI agents"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that a cryptographically signed AgentFacts claim accurately describes what an agent actually can and will do; the paper acknowledges in its discussion of newly seen agents that agents with limited verifiable history present significant risk, but it supplies no mechanism that closes that gap.","fun_headline_variants_meta":{"raw":{"variants":["AI agent registry adds verifiable identity and cross-protocol links","NANDA Index: DNS for AI agents, with verified claims","AgentFacts enable trust across MCP, A2A, and NL Web","Decentralized agent registry with cryptographically attested capabilities","Global discovery and attestation for interoperable AI agents"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000273,"raw_usage":{"total_tokens":1660,"prompt_tokens":995,"completion_tokens":665,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":611,"completion_tokens_details":{"reasoning_tokens":578}},"tokens_in":611,"tokens_out":665,"duration_ms":7932,"temperature":1.0,"reasoning_tokens":578,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T04:40:12.338141+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A concrete test would be to take an agent with a validly signed AgentFacts credential, such as 'kid-safe' or 'HIPAA-compliant', and show that it can be prompted, directly or indirectly, to leak data or perform an action outside the attested capability; alternatively, show that an issuer can be induced to issue a false capability claim. Either result would break the paper's claim that AgentFacts prevent capability spoofing and impersonation.","supporting_citations":[{"cited_title":"Beyond dns: Unlocking the internet of ai agents via the nanda index and verified agentfacts, 2025","cited_arxiv_id":null,"evidence_quote":"Introduces the NANDA Index and AgentFacts, the registry and verifiable-metadata objects the paper applies to enterprise use cases."},{"cited_title":"Model context protocol (mcp)","cited_arxiv_id":null,"evidence_quote":"Defines Anthropic's MCP, the tool-access protocol the paper bridges with the NANDA adapter."},{"cited_title":"Announcing the agent2agent (a2a) protocol","cited_arxiv_id":null,"evidence_quote":"Defines Google's A2A protocol, the horizontal agent-to-agent channel used in the enterprise use case."},{"cited_title":"NL Web: Natural Language Web","cited_arxiv_id":null,"evidence_quote":"Defines Microsoft's NL Web, the third protocol the NANDA Index claims to cover."},{"cited_title":"Domain names - concepts and facilities","cited_arxiv_id":null,"evidence_quote":"Provides the DNS concepts and name-resolution analogy on which agent-name-to-address resolution is modeled."},{"cited_title":"Http over tls","cited_arxiv_id":null,"evidence_quote":"Establishes HTTP-over-TLS as the secure transport baseline for browser-website and assumed agent-agent sessions."}],"review_version":1}