Inspiration

I attended the GoDaddy workshop at VTHacks 14, where I learned about Agent Name Service (ANS), A2A communication, and how identity can become a core part of agent-to-agent systems. I wanted to build a project where AI agents do not just communicate, but first verify who they are talking to.

What it does

DomainGuard is a two-agent system with a Buyer Agent and a Seller Agent. The Buyer discovers and resolves the Seller through GoDaddy ANS, verifies that the Seller has an active and valid ANS identity, checks the registered endpoint and transparency information, and only then communicates with it.

If the Buyer is given a lookalike or untrusted endpoint, the request is refused before any message is sent. The Seller also exposes an A2A endpoint, allowing another agent to communicate with it using the A2A protocol.

How I built it

I built both agents in Python using FastAPI and Gemini. The Buyer uses Gemini with function/tool calling to decide when to contact the Seller.

The Seller is deployed publicly and registered with GoDaddy ANS under seller.domainguard.us. During registration, I generated identity and server certificate requests, completed DNS ownership validation, published the required ANS DNS records, and activated the Seller identity in the production ANS registry.

The Buyer resolves the Seller through ANS, retrieves the registered endpoint, verifies the Seller's DNS records, ANS transparency-log entry, active status, expiration, host, agent ID, endpoint, and identity certificate fingerprint, and then sends the request. I also added a real A2A JSON-RPC endpoint to the Seller.

Challenges I ran into

One challenge was learning how all the pieces fit together: Gemini provides the reasoning, A2A provides agent-to-agent communication, and ANS provides the identity and trust layer.

I also ran into deployment and protocol issues, including DNS propagation, certificate validation, missing dependencies on Render, differences between A2A SDK versions, JSON-RPC method names, protocol-version headers, and asynchronous event handling.

Another challenge was making the system fail closed. I wanted an invalid or lookalike Seller to be rejected before the Buyer sent any data.

Accomplishments that I'm proud of

I successfully registered a live Seller Agent with GoDaddy's production ANS and reached an ACTIVE status.

I built a Buyer Agent that performs real ANS resolution and verification before contacting the Seller. I also implemented a refusal path that blocks lookalike endpoints without valid ANS identity records.

I created an attack battery covering multiple identity and endpoint attacks and successfully blocked all of the cases I tested. I also added a live A2A endpoint and successfully sent an A2A message to the publicly deployed Seller Agent.

What I learned

I learned that agent interoperability is not only about getting two models to talk to each other. Identity, endpoint integrity, trust, and verification are just as important.

I also learned how ANS can provide a trust layer on top of agent communication, how A2A structures communication between independent agents, and how DNS, certificates, transparency logs, and public endpoints can work together to establish agent identity.

What's next for DomainGuard

Next, I want to expand DomainGuard beyond a single Buyer-Seller pair and allow the Buyer to discover multiple agents dynamically by capability.

I also want to expand the A2A integration, add stronger signed-message verification, support more ANS-registered agents, and run additional adversarial tests against external agents and attack services.

Longer term, DomainGuard could become a reusable trust layer for agent marketplaces, where agents can discover and communicate with unfamiliar agents while verifying identity before exchanging sensitive information.

Built With

  • a2a
  • ans
  • fastapi
  • geminiapi
  • godaddyapi
  • porkbun
  • python
  • render
Share this project:

Updates

Submission history