Skip to content

Agent Name Service (ANS): A Proof-of-Concept Trust Layer for Secure AI Agent Discovery, Identity, and Governance in Kubernetes

🕒 Published (v1): 2026-04-29 01:24 UTC · Source: Arxiv · link

Why this paper was selected

Agent Name Service: cryptographic identity, discovery, governance for agent ecosystems

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

ANS (Agent Name Service) is a DNS-inspired trust layer for Kubernetes that provides cryptographic identity management, capability attestation, and policy-as-code governance for multi-agent AI systems. The paper presents a proof-of-concept implementation using DIDs, Verifiable Credentials, and Open Policy Agent on a 3-node cluster with 50 simulated agents. Results are explicitly scoped as demo-environment evidence, not production validation.

Problem

Autonomous AI agent deployments in Kubernetes lack: (1) uniform discovery mechanisms (agents rely on hardcoded endpoints), (2) cryptographic agent-to-agent authentication, (3) capability proofs that avoid exposing secrets, and (4) enforceable policy governance. Without these, a single compromised agent in a 50-agent system can trigger cascading failures within minutes.

Method

ANS introduces four integrated components:

  1. ANS Registry — a centralized discovery and authentication service using a hierarchical naming scheme: Protocol://AgentID.Capability.Provider.v[Version].Extension (e.g., a2a://concept-drift-detector.concept-drift-detection.research-lab.v2.1.prod).
  2. Cryptographic trust chain — each agent gets a W3C DID with PKI chain: Root CA → Intermediate CA → Agent Cert → Capability Proof. Zero-knowledge proofs allow capability attestation without revealing credentials.
  3. Kubernetes-native integration — Custom Resource Definitions (CRDs) encode agent metadata; admission controllers validate naming/cert compliance pre-deployment; Istio service mesh enforces mTLS with capability attestation embedded in certificate extensions.
  4. Policy-as-code governance — OPA evaluates policies at admission control, runtime, network, and resource layers. A GitOps pipeline (ArgoCD/Flux + Sigstore for cert provisioning) drives declarative, auditable deployments.

Multi-protocol support spans A2A, MCP, and ACP via a plugin adapter layer.

Key Contributions

  • Protocol-aligned hierarchical naming convention enabling self-describing, version-aware, provider-attributable agent identities
  • Kubernetes PoC implementation with CRDs, admission webhooks, and Istio service mesh integration
  • Evidence-labeled evaluation that explicitly separates measured demo outcomes from protocol-defined roadmap claims
  • MAESTRO-grounded threat model with explicit trusted-component assumptions and out-of-scope adversaries
  • Open-source repository with reproducible benchmark scripts, Helm charts, and demo agent implementations

Results

All results are from a 3-node cluster (8 CPU/32 GB RAM/node), 50 concurrent demo agents:

  • Latency (mean / 95th / 99th percentile):
  • Agent registration: 45 ms / 89 ms / 156 ms
  • Agent discovery: 12 ms / 23 ms / 41 ms
  • Capability verification: 78 ms / 145 ms / 267 ms
  • Policy evaluation: 3 ms / 7 ms / 12 ms
  • Certificate validation: 15 ms / 28 ms / 52 ms
  • Throughput (synthetic/demo paths): 1,000+ registrations/min; 10,000+ discovery queries/sec; 100,000+ policy evaluations/sec
  • Deployment time: reduced from 2–3 days (manual) to under 30 minutes via GitOps automation
  • Deployment success rate: 100% in scripted PoC scenarios vs. 65% for traditional approach
  • Geographic multi-region latency target: <50 ms (architecture projection, not validated in this repo)

Limitations

  • Scalability numbers for agent capacity and geographic distribution are roadmap projections, not measured production evidence
  • Centralized registry is a potential bottleneck; federated multi-cluster deployment is future work
  • Zero-knowledge capability verification pipeline is partially literature-supported, not fully realized in the PoC
  • Cryptographic overhead is non-trivial: capability verification averages 78 ms
  • Depends on still-evolving protocol standards (A2A, MCP, ACP); legacy agent integration requires modification
  • Threat model excludes hardware root-of-trust compromise and malicious cluster-admin adversaries
  • Experiments use a 50-agent demo simulation, not a production-scale deployment

Relevance to Harnesses / Meta-Harnesses

ANS directly addresses the agent discovery and identity substrate that any multi-agent harness or meta-harness must assume or build. A meta-harness orchestrating heterogeneous specialized agents (e.g., digesting, trend analysis, publishing agents) faces exactly the problems ANS targets: how do agents find each other, verify each other's capabilities, and operate under consistent governance without hardcoded wiring. The DNS-inspired naming convention (Protocol://AgentID.Capability.Provider.vVersion) is architecturally analogous to a service registry in a harness, and the OPA policy layer maps directly to the kind of declarative behavioral constraints a meta-harness might want to enforce across sub-agents. The GitOps deployment model, where agent manifests are version-controlled and admission-validated, is a concrete pattern for making harness composition reproducible and auditable.