Introduction: Protocol Foundations and Decentralized Discovery
This article examines the A2A normative definitions and discovery guidance checked on 22 October 2026. The guidance describes well-known HTTPS retrieval, curated registries and direct or private configuration as alternative discovery strategies. A central catalogue is therefore an option, and static configuration is not inherently invalid. An Agent Card supplies an agent self-description rather than independently demonstrated capability [S1]. However, accepting discovery information from external network participants introduces distinct security challenges that require rigorous structural validation before any operational interaction occurs. [S2]
Designing resilient discovery pipelines involves treating all incoming announcement data as untrusted external input rather than verified operational fact. Protocol frameworks provide the structural syntax for communication, but they cannot inherently guarantee the behavioral reliability, security posture, or operational integrity of the publishing node [S1]. Technical architects must establish dedicated parsing layers that evaluate every incoming manifest against strict versioned schema definitions. This foundational separation between network discovery and behavioral trust is essential for maintaining control over complex multi-agent deployments across enterprise environments [S1].
Structure and Anatomy of Versioned Agent Cards
At the core of the protocol specification lies the agent card, structured as standard JavaScript Object Notation rather than complex distributed ledger constructs or RDF graphs [S1]. The checked AgentCard definition includes name, description, supportedInterfaces, version, capabilities, default input and output media types, skills and security metadata, with optional signatures. Each AgentInterface declares url, protocolBinding and protocolVersion; an optional tenant value may also be present. Card version describes the agent version and must not be confused with an interface protocolVersion [S1]. A proposed consumer should record which definition it checked and handle unsupported interface versions explicitly instead of assuming that any similarly named field has the same meaning.
Where a manifest comes from a publisher outside the consumer’s administrative control, one proposed consumer policy is to validate required properties, accepted types and explicit size limits before using the description. The specification outlines required data structures, but compliance with these schemas does not validate the underlying software implementation or network accessibility of the remote agent [S1]. Engineering teams must implement robust error handling to discard malformed manifests gracefully without compromising the host application. Understanding the exact structural boundaries of the agent card is a prerequisite for secure parser development in distributed environments [S1].
Capability Descriptors vs. Executable Operational Limits
The checked AgentCapabilities definition describes optional protocol features such as streaming, push notifications, extensions and authenticated extended-card support. Skills separately describe advertised tasks, while default input and output modes identify media types [S1]. These are different fields: a skill description is not a protocol feature, and a media type is not a complete application-message schema. However, descriptive fields represent self-assertions published by the remote node rather than verified guarantees of operational performance or execution safety [S1]. An agent can readily advertise advanced reasoning capabilities that it cannot reliably deliver under heavy production workloads or strict resource constraints.
A possible design error is to conflate advertised protocol capabilities with verified runtime performance. Technical architects must treat capability declarations as discovery hints rather than enforceable execution contracts [S1]. Establishing secondary validation checks and monitoring actual task execution metrics provides a realistic assessment of peer reliability over extended operational periods. A useful review would state which advertised behavior remains untested, which evidence would be needed before use and who can accept that residual uncertainty. Discovery alone cannot answer those operational questions.
Cryptographic Signatures and Optional JWS Verification
To establish cryptographic origin attribution, the specification supports optional JSON Web Signature mechanisms for signing agent cards [S1]. When utilized, a JWS structure attaches a cryptographic signature to the manifest, allowing receiving systems to verify that the card was issued by the holder of a specific key [S1]. The checked definition permits an optional signatures array using JWS components protected, signature and an optional header [S1]. A verifier still needs an accepted key and a trust policy. Successful cryptographic verification does not by itself establish a legal publisher identity, and the presence of a signature does not make every advertised assertion true. This article does not prescribe one universal key-distribution architecture.
Furthermore, verifying a cryptographic signature under an accepted key identifies that key relationship, but it does not validate the truthfulness of the claims made within the manifest [S1]. A valid signature does not guarantee that the signing key remains uncompromised or that the publishing node adheres to enterprise security standards. Platform engineers must treat cryptographic validation as a distinct identity check rather than an umbrella guarantee of trustworthiness [S1]. A proposed local review can keep cryptographic checks, permission decisions and behavioral evidence as separate records, so that passing one check is not silently treated as passing the others.
Synthetic Scenario: Parsing and Validating Remote Declarations
Consider a synthetic enterprise architecture where a logistics orchestration platform uses protocol discovery to locate regional inventory management agents across external networks [S1]. During routine initialization, the orchestrator retrieves a card from a pre-approved HTTPS location using the documented well-known path, /.well-known/agent-card.json. Before establishing a task connection, the platform passes the incoming card through a validation pipeline configured to inspect schema compliance, check endpoint URIs against approved domain whitelists, and evaluate version compatibility. [S2]
In this synthetic operational instance, a proposed test card would advertise an interface version outside the consumer’s approved set. The expected test outcome would be rejection before a task request is made. Reviewers should also test a missing field, an unreachable approved endpoint and a validly signed but misleading skill description. These cases separate parsing, connectivity and behavioral evidence. No implementation was executed and no security outcome was measured in this illustration; the expected outcomes would still need testing in the selected consumer.
Technical Limits, Schema Drift, and Parsing Vulnerabilities
Implementing automated discovery protocols introduces distinct technical limits and operational vulnerabilities that engineering teams must manage [S1]. Schema drift represents a persistent challenge in open ecosystems, where subtle modifications to property fields by upstream developers can break downstream parsing logic and cause intermittent failures. Additionally, validation and signature checking use resources, but their practical cost depends on the implementation and workload. A proposed rollout should measure that cost, define acceptable failure handling and keep a recorded reason for any cache or revalidation choice; this article reports no latency benchmark.
Another critical technical limit involves the inability of static parsing pipelines to detect dynamic runtime failures or behavioral degradation. An agent card parsed successfully at startup provides no assurance that the remote endpoint will remain available or responsive during execution [S1]. An operational design could add health checks, timeouts or circuit breakers according to its threat model and service needs; those are design choices to evaluate, not a capability proved by the card. Recognizing these technical boundaries prevents platform architects from relying on discovery metadata as a substitute for robust runtime resilience engineering [S1].
Governance and Design Choices for Multi-Agent Networks
Governance within distributed multi-agent networks requires establishing clear administrative boundaries and policy enforcement points for all discovery activities [S1]. Technical leadership must recognize that protocol standards provide structural interoperability, but local configuration, operating responsibilities, external obligations and independent evidence all need consideration. A proposed registry policy should identify who can add or withdraw an entry, what happens when a key changes and how a failed check is surfaced. Central review is one possible governance arrangement, not proof that unauthorized interaction or unsafe behavior cannot occur.
Ultimately, successful agent discovery relies on disciplined engineering practices that treat protocol specifications as technical baselines rather than comprehensive security guarantees [S1]. By combining strict schema validation, optional cryptographic verification, and continuous runtime monitoring, organizations can make the remaining assumptions visible. Treating cards as untrusted descriptive metadata supports a more explicit acceptance decision, while runtime behavior remains a separate question. Discovery governance is one part of accountable multi-agent operation, with limits that should remain visible to the person responsible for the next action.
Official background videos
External publisher context. These recordings do not demonstrate GPIRL products or validate the proposed designs.
- Google Cloud — Google Announces Gemini Enterprise Agent Platform: The Future of Agentic AI
Vendor presentation gives context for agent platforms and discovery; exact A2A AgentCard fields remain governed by the cited specification.
Sources and further reading
References do not imply product certification or endorsement.
Have a related operational question? Bring this question to a GPIRL Technologies discovery discussion.