AI agents are starting to search, transact and act on behalf of people. That raises a basic question: How do you verify who -- or what -- is on the other end?
The answer could well rely on some of the same core fundamentals that have enabled trust on the internet for decades. Domain names provide a unique identifier. DNS makes it discoverable. X.509 certificates tie the name to cryptographic proof. GoDaddy has built on that idea with Agent Name Service (ANS), a framework introduced through OWASP and the IETF a little over a year ago. The company wrote a spec and a reference implementation, and it announced the reference implementation for contribution to the Linux Foundation.
TechTarget interviewed Scott Courtney, vice president and head of edge and domains engineering at GoDaddy, about agent identity, trust and the case for open standards. Here's what he had to say.
Editor's note: The following transcript was edited for brevity and clarity.
What has been the affect of agentic AI in recent years on both the architecture and the way that you enabled it for both internal use and for your users?
Scott Courtney: From the registrar point of view, there has been little effect from AI, short of the miracle of .ai. That became a fairly serious TLD [Top Level Domain] overnight.
In terms of edge traffic coming in -- depending on the type of business -- there are a few percentage points that might look agentic. It is still pretty nascent compared to the large volumes of human and bot traffic. One other thing we're starting to see more of is direct access to our APIs -- and of course that'll come from things such as agent sessions. So, if someone is running Meta Muse, Claude Code or whatever else, they're going directly to the APIs rather than through our user interfaces.
How are you thinking about verification and the identity of AI agents? How can you verify what those agents are and who they're working for?
Courtney: Look at the CDN WAF providers; what do they do today? They have traffic coming in. It's not a whole lot different from others, and they're looking at HTTP headers. From that, they can see things in the traffic and decide whether it's a bot. That's what we're doing as well.
And then you have specifications coming in, so there are a bunch of ideas out there. I don't think they're broadly used right now. I've tried to implement several of them.
We took a security framework, developed a spec and then implemented it. That's the thing called Agent Name Service. So, this was an open internet security framework.
The Agent Name Service (ANS) was introduced a little over a year ago by OWASP and later by the IETF. We turned around and made it somewhat more opinionated.
That's what ANS v2 is. So, we started working with that. We wrote up the spec, implemented it, then built a reference implementation, which we announced as a contribution to the Linux Foundation. Since then, we've taken it further, working with other organizations and trying to prove some of this out.
How do DNS and domains help to inform identity, whether it translates to ANS or otherwise?
Courtney: So, the original ANS spec -- the security framework -- didn't specify it has to use DNS. But we have a getting started problem. So, what we started with was the set of problems already solved at scale. So yeah, DNS. If I have a domain name, the miracle of domain names is DNS. That I have discoverability as soon as I'm using a domain name that's actually recognized. So, I go ahead, I specify a domain name. I can give a unique identifier based on the domain name, and a unique identifier for an agent.
That doesn't mean that's the only way we're going to do it. We already support other approaches for identifiers, but that was an easy at-scale soft solution that's auditable today.
On the auditable side, we had again, the other miracle, and that was back in 1994/1995. We had RSA cryptography and the introduction of certificates and certificate authorities. So, every time that I'm going to issue an X.509 server certificate, I put into its SAN [Subject Alternative Name] field a domain name or some facsimile of a domain name, a wildcard, multiple domain names or whatever.
So, I have this hard tie-in between something I'm stating. Oh, here's my agent. My agent has a name. That new name is unique, and now a hard proof, right? A strong mathematical proof.
Trust is simply an algorithm between a stated identifier and hard mathematics.
Where does that sort of reputation now layer in on top of this identity kind of idea that you have for agentic AI?
Courtney: Well, the first thing is I have to be able to have my assertions or my statements and attestations. I have to be able to put them in a public log. That's really because the provability and the trustworthiness are going to come from some auditor or audit process being able to come around and say, 'Let me look at every statement you've said, and let me see the mathematical proof around them.'
When we do, let's say, any agent registration, or we update the agent registration, or we find a new fact about the agent registration, like, 'Hey, the agent metadata that you're using today changed from what you registered,' right? So that's a finding. We stamp it into an open append-only log.
Now, we leave the land of registration; we go into the land of judgment, and that is proof over time. And so, by looking into that log and other public, provable, strong logs, I can start saying more about the agent.
We created something called a trust index. So, picture there are 10 or 20 of these logs that you're pulling from. A trust index says I've got all of that. The trust index reads from all of them.
Where does agent verification interoperability stand today, and how are you testing it across organizations?
Courtney: There are things out there, like A2A, MCP. We work with Infoblox on DNS-AID (DNS for AI discovery).
Instead of creating our own resource records, which I did originally, but as somebody who's run DNS at scale and designed at scale, I don't want everybody out there doing their own. Every time there's an agent, there are 50 resources around it. So, we worked with Infoblox; that's all DNS-AID and ANS just uses it.
That's where we started getting into agent interoperability.
We're working with a number of other companies and organizations that are interested in this -- where they create their agents, we create our agents and then we go and try to do a provable thing on the open internet. Now we're saying, yeah, we need a provable financial transaction, and there are no empty words around it. You will have an auditor agent that'll go ahead and test. It'll say, I'm the auditor. I need to see proof using logs -- such as your transparency log or whatever else. I need to be able to prove what has happened here.
Sean Michael Kerner is an IT consultant, technology enthusiast and tinkerer. He has pulled Token Ring, configured NetWare and been known to compile his own Linux kernel. He consults with industry and media organizations on technology issues.
