Agent registry and identity systems for OSSA architecture decisions

The most critical finding: agent identity and trust remain the single largest unsolved problem in the agentic AI ecosystem, even as communication protocols have rapidly consolidated around MCP (agent-to-tool) and A2A (agent-to-agent) under Linux Foundation governance. OSSA has a genuine opportunity to innovate on this gap. The protocol interoperability layer is largely solved — 150+ organizations back A2A, 97M+ monthly SDK downloads for MCP — but no single, vendor-neutral agent identity standard exists. Multiple open-source agent registry implementations already exist and could be extended rather than built from scratch, most notably the A2ABaseAI/A2ARegistry project (Python/FastAPI with full search, federation, and OAuth). OSSA's OpenAPI-based specification, Kubernetes-native deployment, and token efficiency claims position it to build a differentiated registry layer that bridges existing protocols while solving identity and trust problems the ecosystem has left unaddressed.

---

The protocol landscape has consolidated faster than expected

The agentic AI ecosystem underwent remarkable consolidation in 2025. What was a fragmented landscape of competing approaches has crystallized into a complementary multi-protocol stack, all converging under the Linux Foundation:

MCP (Model Context Protocol) dominates agent-to-tool connectivity. Originally created by Anthropic (November 2024) and donated to the Agentic AI Foundation (AAIF) in December 2025, MCP standardizes how LLM applications connect to external data sources and tools via JSON-RPC 2.0. It has achieved extraordinary adoption: 5,800+ MCP servers, adoption by OpenAI, Google DeepMind, and Microsoft, and an official registry at registry.modelcontextprotocol.io with nearly 2,000 entries. MCP is the "USB-C for AI integrations."

A2A (Agent-to-Agent Protocol) addresses agent-to-agent communication. Launched by Google in April 2025 and donated to the Linux Foundation in June 2025, A2A defines how agents discover each other via Agent Cards (JSON documents at /.well-known/agent.json), communicate via JSON-RPC 2.0 over HTTP(S)/gRPC, and manage task lifecycles. It absorbed IBM's ACP (Agent Communication Protocol) in August 2025 and now has 150+ supporting organizations including Adobe, Cisco, SAP, ServiceNow, and all major cloud providers. v0.3 added gRPC support and cryptographically signed Agent Cards.

AGNTCY provides the infrastructure plumbing. Donated to the Linux Foundation by Cisco in July 2025, AGNTCY fills the gap between protocols with four pillars: the Open Agent Schema Framework (OASF) for DNS-like discovery, cryptographically verifiable task-based identity, SLIM (Secure Low-latency Interactive Messaging) extending gRPC with quantum-safe security, and end-to-end observability. 75+ companies support it, with formative members including Cisco, Dell, Google Cloud, Oracle, and Red Hat.

For OSSA, the strategic implication is clear: do not create new communication protocols. Adopt MCP for tool connectivity and A2A for agent-to-agent communication. The innovation space lies above the protocol layer — in registry, identity, trust, and governance.

---

How major tech companies handle agent registration and discovery

Every major tech company now offers an agent platform, but their approaches to registry and identity vary dramatically. None has solved the cross-vendor identity problem.

Google offers the most complete open-standard approach. Beyond A2A, Google's Agent Development Kit (ADK), Vertex AI Agent Engine, and Agentspace provide end-to-end agent development, deployment, and consumption. Agent Cards at /.well-known/agent.json describe capabilities, authentication requirements, and supported skills. Discovery is decentralized (well-known URLs) supplemented by curated marketplaces. Authentication supports OAuth 2.0, OIDC, mTLS, and signed cards. Everything is open-source under Apache 2.0.

Microsoft has consolidated Semantic Kernel and AutoGen into the unified Microsoft Agent Framework (public preview October 2025), explicitly supporting both MCP and A2A. Identity is anchored in Microsoft Entra Agent ID (public preview November 2025) — the most comprehensive enterprise agent identity platform, providing a centralized agent registry, Zero Trust policies, lifecycle governance, and delegation chain tracking. This is proprietary but sets the standard for enterprise agent governance. 10,000+ organizations use Azure AI Foundry Agent Service.

Anthropic owns the MCP ecosystem. The MCP Registry uses a namespace system (io.github.username/* for GitHub-verified publishers, com.yourcompany/* for DNS-verified domains) and functions as a meta-registry — it hosts metadata but not code. Claude has 75+ built-in MCP connectors. However, MCP explicitly does not address agent-to-agent identity; it's tool-focused.

OpenAI contributes through the AAIF (co-founder) with AGENTS.md and the Agents SDK, and has adopted MCP natively in its Responses API. The GPT Store provides consumer-facing agent discovery, but OpenAI has no open agent-to-agent protocol. Identity is basic (API key scoped to projects). Salesforce Agentforce is notable for its AgentExchange marketplace (claimed as "world's first" agent marketplace) and MuleSoft Agent Fabric for governed orchestration, but it's deeply proprietary. Amazon Bedrock AgentCore provides the strongest IAM integration but is AWS-locked.

Meta takes no platform position — Llama models (400M+ downloads) are open-weight, but Meta provides no agent infrastructure, discovery, or identity. Agent platforms are left entirely to the ecosystem.

The critical takeaway: no vendor offers a vendor-neutral, cross-platform agent identity solution. Microsoft Entra Agent ID comes closest architecturally but is Azure-centric. This is OSSA's clearest innovation opportunity.

---

Existing open-source registries that OSSA could extend

Several open-source agent registry implementations already exist, eliminating the need to build from scratch. The most promising candidates ranked by maturity and relevance to OSSA:

A2ABaseAI/A2ARegistry is the most complete implementation. Built on Python/FastAPI with PostgreSQL, Redis, and OpenSearch, it provides full OAuth 2.0 Client Credentials authentication, agent registration via A2A Agent Cards, semantic and lexical search, federation support (peer registries with cross-registry sync), and a React web UI. It directly implements the A2A Registry proposal (Discussion #741 in the A2A GitHub). This is the strongest candidate for OSSA to fork and extend with OSSA-specific agent card formats and token efficiency metrics.

The official MCP Community Registry (modelcontextprotocol/registry) serves as a meta-registry for MCP servers. Its architecture — namespace verification via GitHub/DNS, API at registry.modelcontextprotocol.io, sub-registry federation pattern — provides an excellent model for organizational mirroring and policy overlay. Its API was frozen at v0.1 in October 2025.

Fetch.ai's Almanac is the most mature agent-specific registry in production, using blockchain-based registration where agents auto-register at startup with cryptographic identity derived from seed phrases. It supports protocol-based discovery (find agents by supported message types), broadcasting, and an Agentverse marketplace. The blockchain dependency limits enterprise adoption, but the registration patterns and protocol manifests are directly applicable.

The mcp-gateway-registry (agentic-community) combines MCP server governance with agent discovery and A2A communication hub, using OAuth with Keycloak/Entra integration. It's enterprise-focused and the most relevant for organizations needing unified MCP + agent discovery.

The A2A Registry Proposal (GitHub Discussion #741) deserves special attention as a specification rather than implementation. It defines open discovery endpoints (GET /agents/public), entitlement-based access (GET /agents/entitled), search (POST /agents/search), and role-based administration — the closest existing specification to what OSSA needs.

---

Identity standards form a layered architecture for agents

The identity landscape for AI agents is fragmented but converging toward a composite approach. No single standard suffices; agents require layered identity spanning infrastructure, authentication, and capability attestation.

W3C Decentralized Identifiers (DIDs) provide the strongest foundation for cross-platform agent identity. The v1.0 specification (W3C Recommendation, July 2022) defines globally unique, self-sovereign URIs that resolve to DID Documents containing cryptographic keys and service endpoints. For agents, two DID methods stand out: did:web (identity tied to hosting domain, easiest adoption path using existing DNS/TLS infrastructure) and did:wba (purpose-built for AI agents under the Agent Network Protocol v0.1, adding humanAuthorization verification and AgentDescription service types). The DIF Trusted AI Agents Working Group (launched September 2025) is actively developing specifications for DID-based agent identity with verifiable credentials.

W3C Verifiable Credentials v2.0 (W3C Recommendation, May 2025) enable the "driver's license" model for agents. A trusted authority issues digitally signed, tamper-evident credentials encoding an agent's capabilities, model provenance, safety certifications, autonomy level, and delegation chain. Any verifier can cryptographically validate the credential against the issuer's public key via DID resolution. Selective Disclosure JWT (SD-JWT) allows agents to prove specific capabilities without revealing full credentials — an agent can prove "authorized for financial analysis" without exposing all permissions. Bitstring Status Lists enable real-time credential revocation.

OAuth 2.0 Client Credentials remains the pragmatic choice for within-domain agent authentication but has fundamental limitations for autonomous agents. The OpenID Foundation's landmark whitepaper (October 2025) explicitly identifies the gaps: OAuth is human-centric, static scopes are too coarse for dynamic agent behavior, no built-in delegation chain tracking, and cross-organizational agent-to-agent scenarios break the hierarchical trust model. A proposed OIDC-A 1.0 (OpenID Connect for Agents) extension adds agent-specific claims (agent_type, agent_model, agent_capabilities) and delegation chain verification, but it remains a proposal.

SPIFFE/SPIRE (CNCF Graduated project) provides workload-level identity perfectly suited to containerized agent deployment. Each workload receives a SPIFFE ID (spiffe://trust-domain/workload-id) via short-lived X.509 certificates or JWT-SVIDs, with automatic rotation and no shared secrets. Istio, Envoy, and all major cloud providers integrate with SPIFFE. The IETF WIMSE Working Group has published an explicit draft (October 2025) applying WIMSE/SPIFFE architecture to AI agent identity, proposing Identity Proxy attestation and user-agent identity binding.

The emerging consensus for an OSSA identity architecture is a five-layer stack:

1. Infrastructure layer: SPIFFE/SPIRE for workload identity in Kubernetes/cloud environments
2. Base identity layer: DIDs (did:web or did:wba) for portable, cryptographic agent identity
3. Credential layer: W3C VCs for expressing capabilities, certifications, and delegation authority
4. Authentication layer: OAuth 2.0 Client Credentials within domains; DID-based auth cross-domain
5. Policy layer: Real-time authorization engines (OPA, Cedar) evaluating context-aware policies

---

Proven registry patterns from software ecosystems

Successful software registries share architectural patterns directly applicable to agent registries. Analyzing NPM, Docker Hub, Terraform Registry, VS Code Marketplace, GitHub Actions, and PyPI reveals convergent design principles.

Tiered trust classification appears in every mature registry. Terraform uses Official/Partner/Community tiers. Docker Hub distinguishes Docker Official Images, Verified Publishers, and community content. VS Code requires domain ownership verification, 6-month track record, and editorial review for Verified Publisher badges. For an agent registry, this maps to: OSSA Official (maintained by OSSA core team), Verified Publisher (domain-verified organization with established track record), and Community (open contributions with lower trust guarantees).

Immutable versioned artifacts with provenance is now industry standard. NPM enforces that published name@version pairs can never be reused. Docker Hub's content-addressable digests (SHA-256) are immutable alongside mutable tags. Sigstore-based provenance (adopted by NPM, PyPI, and Kubernetes) provides keyless signing using OIDC identity with transparency logging — cryptographic proof of where and how an artifact was built. PyPI and NPM now support OIDC Trusted Publishing following the OpenSSF standard, eliminating long-lived credentials entirely by exchanging CI/CD OIDC tokens for short-lived, project-scoped publish tokens.

Reputation signals combine static and dynamic components. Static signals include verified publisher badges, domain ownership, and organization verification. Dynamic signals include download counts, dependent counts, community ratings, and last-update recency. VS Code's multi-layer security pipeline (malware scanning, dynamic sandboxed analysis, signature verification, secret scanning) represents the gold standard for pre-publish validation. Bayesian-adjusted ratings solve the cold-start problem — new agents' scores regress toward the category mean until sufficient data accumulates.

For anti-gaming, the most effective mechanisms are: daily reputation caps (StackOverflow), cost-to-downvote (discouraging frivolous negative signals), time-based gating for trust elevation (VS Code's 6-month minimum), anomaly detection on usage metrics, and separation of concerns where trust verification is done by the registry rather than self-reported.

---

Service discovery patterns translate directly to agent discovery

Three service discovery paradigms from infrastructure engineering map cleanly to agent discovery, each solving different problems at different scales.

Consul's service catalog model is the closest analog to an agent registry. Services self-register via API with rich metadata (tags, health checks, key-value data). Discovery operates through both DNS (agent.service.consul) and HTTP API. "Intentions" (allow/deny rules between services) translate directly to agent-level access policies. Multi-datacenter federation enables distributed agent registries. For OSSA, Consul's pattern suggests: agent self-registration via API with capability tags, dual DNS + REST discovery, health checking with automatic deregistration, and federated registries across organizational boundaries.

DNS-based Service Discovery (DNS-SD, RFC 6763) provides lightweight, federated, internet-scale discovery without centralized infrastructure. Agents would register under standardized service types (e.g., _ai-agent._tcp.agents.example.com), with PTR records enumerating instances, SRV records providing endpoints, and TXT records carrying capability metadata. This "DNS for agents" concept aligns with the Agent Name Service (ANS) proposal from CSA-affiliated researchers and AGNTCY's OASF directory. The key limitation is DNS's weak metadata capacity (~255 bytes per TXT string) and lack of authentication, but it provides universal federated discovery infrastructure.

Kubernetes CRD-based extensibility enables defining AgentRegistration custom resources that the OSSA Kagent operator already manages. Label-based selection powers capability matching ("find all agents with label capability=code-review"), namespace isolation provides multi-tenant separation, and headless services expose individual agent endpoints. OSSA's existing Kagent CRD pattern (apiVersion: kagent.openstandardagents.org/v1alpha1) already demonstrates this approach — extending it with registry metadata is a natural evolution.

---

Eight critical gaps where OSSA can legitimately innovate

Based on this comprehensive landscape analysis, eight specific gaps exist where OSSA can create genuine value rather than reinventing existing solutions:

1. Cross-domain agent discovery at internet scale. No production "DNS for agents" exists. A2A's .well-known/agent.json is per-domain but has no global search or aggregation. AGNTCY's directory and ANP's discovery protocol are promising but immature. OSSA could build a federated agent directory service that indexes agents across protocols (A2A Agent Cards, MCP servers, OSSA agent descriptors), providing unified search with capability matching. The DNS-SD pattern combined with A2A Agent Cards and OSSA's structured YAML manifests would enable both well-known-URL discovery and centralized search.

2. Vendor-neutral agent identity bridging existing standards. The identity landscape is deeply fragmented: Microsoft Entra Agent ID (Azure-centric), W3C DIDs (decentralized but early), OAuth/OIDC (human-centric), AGNTCY (Cisco-led), ANP DID:WBA (China-led). OSSA can provide a practical identity layer that bridges these — issuing DIDs (did:web) for registered agents, packaging Verifiable Credentials for capability attestation, and translating between OAuth, SPIFFE, and DID-based authentication at registry boundaries.

3. Token efficiency as a first-class registry metric. No existing registry tracks computational efficiency. OSSA's core claim of 70-95% token reduction through multi-agent orchestration is unique. The registry could publish verified token efficiency benchmarks for each agent, enabling consumers to optimize cost — a differentiator no competitor offers.

4. OpenAPI-native agent definitions with structured capability schemas. OSSA's existing OpenAPI-based specification provides richer structural information than A2A Agent Cards (flat JSON) or MCP server manifests. This enables machine-readable capability matching, compatibility checking, and automated integration — moving beyond keyword search to semantic capability resolution.

5. Recursive delegation chain management. The OpenID Foundation whitepaper explicitly calls this unsolved. When agents spawn sub-agents across organizational boundaries, no standard mechanism exists for verifiable delegation chains with automatic scope reduction at each hop and revocation that propagates through chains. OSSA could implement this using W3C VCs with embedded delegation chains and Bitstring Status Lists for revocation.

6. Cross-protocol reputation aggregation. No standardized agent reputation system exists. OSSA can build a composite trust score combining static signals (verified publisher, DID verification, VC attestations), dynamic signals (usage, dependent count, error rates, community ratings), and token efficiency performance as a unique quality metric. Bayesian-adjusted ratings handle cold-start, and EigenTrust-inspired transitive trust handles agent dependency chains.

7. Agent lifecycle governance across platforms. While Microsoft Entra defines lifecycle states within Azure, no cross-vendor standard exists for agent provisioning, versioning, deprecation, successor references, or retirement. OSSA's YAML-based manifests already include version metadata — extending this to full lifecycle management with migration paths fills a real need.

8. Drupal/CMS marketplace integration. If OSSA is building toward Drupal integration specifically, an agent capabilities marketplace where CMS administrators can discover, install, and configure agents from a curated registry — similar to Drupal's module system but for AI agents — would be a unique vertical application of horizontal registry infrastructure.

---

Two architectural options for OSSA agent registry

Option A: Standalone open-source agent registry (separate project)

This option creates an independent, protocol-agnostic agent registry that OSSA agents use but that also supports A2A Agent Cards, MCP servers, and other agent formats.

Architecture: Fork A2ABaseAI/A2ARegistry as the starting foundation (Python/FastAPI, PostgreSQL, Redis, OpenSearch). Extend with: OSSA YAML manifest parsing alongside A2A Agent Card JSON, MCP server manifest indexing, DID-based agent identity (did:web issuance at registration), W3C VC issuance for capability attestation, Sigstore-based provenance for agent artifact signing, federated sub-registry support (organizational mirrors with policy overlay), and a composite reputation engine (Bayesian-adjusted scores with EigenTrust transitive trust). Discovery operates through three channels: REST API (/agents/search, /agents/public, /agents/entitled), DNS-SD records (_ai-agent._tcp.registry.openstandardagents.org), and .well-known/agent.json generation for A2A compatibility.

Standards used: A2A Agent Cards for discovery format, MCP for tool integration, W3C DID (did:web) for identity, W3C VC v2.0 for credentials, OAuth 2.0 Client Credentials for authentication, SPIFFE for infrastructure identity, Sigstore for provenance, OpenSSF Trusted Publishing for CI/CD integration.

Integration: OSSA agents register via CLI (ossa registry publish) or CI/CD pipeline. The registry validates OSSA YAML manifests, issues DIDs, generates A2A-compatible Agent Cards, and publishes to both the OSSA registry API and DNS-SD. Non-OSSA agents (pure A2A or MCP) can also register, making the registry a universal agent directory.

Pros: Protocol-agnostic attracts broader community; independent governance enables faster iteration; can become the "npm for agents" serving multiple ecosystems; positions OSSA as infrastructure rather than just specification; enables community contributions from outside the OSSA ecosystem. Cons: Higher maintenance burden as separate project; risk of fragmenting OSSA community attention; must compete with MCP Registry, A2A registry proposals, and AGNTCY directory; requires dedicated team and hosting infrastructure; cold-start adoption challenge.

Option B: Built into OSSA specification and tooling

This option integrates registry capabilities directly into the OSSA specification and Kagent operator, making registration and discovery native to every OSSA deployment.

Architecture: Extend the existing Kagent CRD with registry metadata fields (capabilities, trust tier, DID, VCs, health endpoints, token efficiency benchmarks). The Kagent operator acts as both agent lifecycle manager and local registry node. Each OSSA deployment automatically registers its agents in a local registry (Kubernetes-native via CRDs) and optionally syndicates to a global federated index. Agent discovery is built into the OSSA CLI and SDK: ossa agents discover --capability=code-review --min-trust=verified queries both local cluster and federated registries. Identity is managed through OSSA manifests — each agent's .ossa.yaml file includes DID configuration, and the Kagent operator handles DID issuance, SPIFFE/SPIRE integration for workload identity, and VC lifecycle.

Standards used: OSSA YAML manifest as the primary agent definition format (superset of A2A Agent Card information), Kubernetes CRDs for registration, SPIFFE/SPIRE for infrastructure identity (already Kubernetes-native), W3C DID (did:web) for cross-platform identity, OAuth 2.0 for authentication, DNS-SD for federated wide-area discovery.

Integration: The .ossa.yaml manifest IS the registration document. Publishing an agent means deploying a Kagent CRD. The operator handles registry synchronization. A2A Agent Cards are auto-generated from OSSA manifests for interoperability. MCP tool registrations are managed through OSSA's existing MCP bridge. Token efficiency metrics are automatically collected by the operator and published as registry metadata.

Pros: Zero-friction adoption for OSSA users (registry is automatic); deeply integrated with existing Kagent lifecycle management; Kubernetes-native fits OSSA's deployment model; token efficiency tracking is native; single coherent specification reduces cognitive overhead; stronger value proposition for OSSA adoption ("deploy once, registered everywhere"). Cons: Kubernetes dependency limits non-K8s adoption; tighter coupling makes it harder for non-OSSA agents to participate; may be perceived as OSSA-specific rather than ecosystem-wide; federated discovery across non-OSSA registries requires additional bridging work; specification complexity increases.

Recommended approach

Start with Option B, evolve toward Option A. Build registry capabilities directly into OSSA's Kagent operator and specification first — this provides immediate value to OSSA users with zero additional infrastructure. Use the A2A Agent Card format as the interchange format, ensuring OSSA agents are automatically discoverable by any A2A-compatible system. As the OSSA ecosystem matures, extract the registry logic into a standalone service that can also index non-OSSA agents, effectively evolving into Option A while maintaining backward compatibility. This mirrors how Kubernetes itself evolved — CRDs provided extensibility within the platform, then tools like OperatorHub emerged as standalone discovery layers on top.

---

Conclusion: where to build, where to adopt, where to wait

The agent registry landscape in early 2026 presents a rare window where the communication layer has stabilized but the identity and trust layers remain wide open. OSSA's strategic positioning should be precise.

Adopt immediately: MCP for agent-to-tool connectivity, A2A Agent Cards as the discovery interchange format, OAuth 2.0 Client Credentials for authentication, SPIFFE/SPIRE for Kubernetes workload identity, and Sigstore for provenance attestation. These are mature, well-governed, and adding value requires integration rather than invention.

Build and innovate on: Cross-protocol agent discovery (federated registry indexing OSSA, A2A, and MCP agents), DID-based vendor-neutral agent identity (issuing did:web identifiers at registration), W3C VC-based capability credentials (the "agent driver's license"), token efficiency benchmarking as a unique registry metric, and OpenAPI-native structured capability matching that goes beyond keyword search.

Monitor and wait on: The W3C AI Agent Protocol Community Group (early stage, unclear trajectory), OIDC-A 1.0 (still a proposal, not adopted by OpenID Foundation), blockchain-based identity approaches (ERC-8004, Fetch.ai Almanac — interesting patterns but adoption barriers), and the IETF WIMSE agent identity draft (informational, not yet a standard). These may become important but are too immature to build dependencies on.

The organizations driving this space — the Linux Foundation's AAIF (hosting MCP), LF AI & Data (hosting A2A and AGNTCY), the DIF Trusted AI Agents Working Group, the OpenID Foundation AI IM Community Group, and the W3C AI Agent Protocol CG — should all be engaged. OSSA's unique advantage is its OpenAPI-grounded, Kubernetes-native, token-efficiency-focused specification. The registry should amplify this advantage while bridging to the broader ecosystem through standard protocols that the industry has already chosen.