![\"Infoblox\"](\"/wp-content/uploads/infoblox-logo-2.svg\"){kind=logo}
![](\"https://www.infoblox.com/blog/wp-content/uploads/search.png\")
![\"Read](\"https://www.infoblox.com/wp-content/uploads/infoblox-video-build-for-a-world-that-never-stops.png\")
![\"Infoblox](\"https://www.infoblox.com/wp-content/uploads/promo-support-portal-menu-v2.jpg\")
\r\n\t\t\t\t\t\t\t\t\t![\"Read](\"https://www.infoblox.com/wp-content/uploads/infoblox-whitepaper-independent-research-20-20-visibility-clarifies-network-security-home-page-navigation-promo-v2.jpg\")
\r\n\t\t\t\t\t\t\t\t\t![\"Share](\"https://www.infoblox.com/blog/wp-content/uploads/FB.svg\")
![\"Share](\"https://www.infoblox.com/blog/wp-content/uploads/x-logo.svg\"){kind=logo}
![\"Share](\"https://www.infoblox.com/blog/wp-content/uploads/LI.svg\")
On September 12, Dario Amodei, Anthropic’s CEO, published an essay titled We Must Pace the Frontier. In this essay, he urges that “We must slow the pace at which we improve the capabilities of AI models.” OpenAI CEO Sam Altman and xAI CEO Elon Musk quickly tweeted their agreements. The call for AI development to slow down is not new. In July, about 1,400 employees from leading AI companies signed a statement requesting “the U.S. government support an international effort to develop the technical and governance tools needed to deliberately pace the frontier of automated AI development.”
\nA debate around whether the AI companies should or could “pace the frontier” followed. Some suggested that “pacing” is partly a strategy to reduce competitive pressure, respond to compute scarcity or shape the narrative ahead of the AI companies’ potential IPOs. Some raised antitrust or self-serving concerns.
\nMaking AI Safe Is Everyone’s Job
\nIt is easy to look at this debate and conclude that it is too political or technical for the rest of us to participate, let alone influence the direction of AI development.
\nI don’t believe that is true.
\nWhen I think about AI safety, I often draw an analogy to fire safety. Fires remain extremely dangerous today. They still destroy homes, injure people and take lives. Yet most of us coexist with fire every day because layers of protection developed over centuries make the risks manageable.
\nMost of these layers of protection did not come from “fire engineers” with Ph.D.s or companies offering “fire as a service.” Instead, they were invented over time by a broad ecosystem of industries and businesses focusing on fire safety:
\n- \n
- Fireproof doors and walls \n
- Alarms and sprinklers \n
- Fire hydrants and water systems \n
- Building codes and inspectors \n
- Emergency services and fire departments \n
- Public education and fire drills \n
- Insurance policies \n
Over time, these protections, once perceived as inconvenient, became part of our daily life. They made co-existing with fire not only possible but enjoyable, enabling us to prepare delicious food and generate electricity for every household.
\nAI needs a similar ecosystem: an ecosystem where every field, including manufacturing, health care, law, security, education and frontline operations, need to draw on our unique knowledge, experience and creativity to contribute in our own ways.
\nWe believe every organization deploying AI can, and should, do its part to make AI safer, instead of waiting for the governments to pass regulations or the world to settle their debate. Just as we do not need to understand every element of fire to design a fire alarm or build a sprinkler, we do not need to fully understand AI to contribute to AI safety.
\nWork is Underway at Infoblox
\nIn his essay, Amodei calls on frontier AI companies within democratic countries to coordinate to establish common safety standards. I believe the same call to action applies to every organization when building and deploying AI systems. And that work is already underway at Infoblox.
\nFor the past year, Infoblox has been leading AI safety work through:
\n- \n
- Standards Development: We proposed DNS for AI Discovery (DNS-AID), an open standard now advancing as an Internet Engineering Task Force (IETF) draft. It is also central to the IETF’s new Discovery of Agents With Names (DAWN) effort on secure discovery mechanisms for AI agents and other network-resident entities across organizational boundaries. \n
- Industry Collaboration: DNS-AID is launched as a Linux Foundation open-source project backed by a broad industry coalition, including Akamai, Cloudflare, CSC, Equinix, GoDaddy, IDC, Indeed, Internet Systems Consortium and WWT. GoDaddy and Infoblox jointly announced that DNS-AID and Agent Name Service are designed to operate seamlessly with each other. \n
- Policy Engagement: Infoblox has submitted comments to the National Institute of Standards and Technology (NIST) on its Concept Paper on Identity and Authority of Software Agents, a Request for Information (RFI) Regarding Security Considerations for Artificial Intelligence Agents, and its Cyber AI Profile. We have also submitted a response to the consultation on the EU Cybersecurity Act Revision, as well as to the Cyber Security Agency of Singapore on its Draft Addendum on Securing Agentic AI Systems. Most recently, we supported a Bill introduced to the House that directs NIST to develop a security framework for AI agent discovery. \n
DNS-AID as the Foundation for an Agent Chain of Trust
\nEven if the frontier labs paused AI development tomorrow, organizations would continue building autonomous agents that select tools, access systems and delegate tasks to other agents. Each agent workflow begins with discovery: could an autonomous agent reliably find the right endpoint, website, data source, cloud workload or another agent? When discovery is unsecure, an agent might be redirected to a malicious or unauthorized endpoint.
\nThe internet already has a solution to this problem: Domain Name System (DNS).
\nFor over 40 years, DNS has been translating human-readable domain names (e.g., infoblox.com) into machine-readable IP addresses (e.g., 151.101.2.253). It is open, federated, interoperable, scalable and already globally recognized and deployed. Domain Name System Security Extensions (DNSSEC) adds a layer of cryptographic verification to discovery. By digitally signing DNS records, DNSSEC ensures that the records returned during discovery are authentic and have not been tampered with or spoofed by malicious actors.
\nDNS-AID uses this established internet infrastructure to give an agent a name anchored to a verified domain. In simple terms, an agent operating at billing.acme.com with DNSSEC can be cryptographically tied to the organization that controls acme.com. Any actions taken by this agent can be traced back to acme.com to establish accountability. In addition to an agent name, DNS-AID enriches existing DNS records with information such as supported protocols (e.g., A2A), capabilities and other metadata, all under a domain controlled by the organization operating it.
\nBy providing an open, globally federated namespace secured cryptographically by DNSSEC, DNS-AID serves as the universal root for agent chain of trust. Many agent identity and authentication standards, including SPIFFE, Agent Name Services and ARD, rely on domain names as their foundational trust root.
\nLeveraging DNS as a Kill Switch
\nMost security teams already use DNS to enforce policy and restrict access to known malicious domains. Protective DNS solutions such as Infoblox Threat Defense™ can preemptively block resolution to unauthorized or malicious domains based on corporate policies and advanced real-time threat intelligence.
\nIf an organization identifies an unauthorized or compromised agent, it can block users, devices and workloads from resolving that domain and therefore cut off the connection.
\nThis is sometimes called a DNS kill switch. DNS serves as a “choke point” for agent reachability.
\nDNS-AID and Protective DNS provide complementary, bidirectional controls:
\n- \n
- DNS-AID (Positive Control): Names the agent, validates the operator’s domain and verifies endpoint provenance via DNSSEC. \n
- Protective DNS (Negative Control): Restricts outbound traffic to unauthorized or malicious domains even before the first connection is established. \n
Domain-based trust benefits from decades of well-established international dispute-resolution framework:
\n- \n
- UDRP: ICANN’s Uniform Domain-Name Dispute-Resolution Policy, administered by international bodies such as WIPO, gives rights holders an enforceable, rules-based mechanism to challenge abusive registrations and mandate domain transfer or cancellation. \n
- URS: The Uniform Rapid Suspension system offers an expedited path to freeze domains in blatant cases of cybersquatting and impersonation. \n
- Domain Takedown and Mitigation: Organizations can actively dismantle infringing or abusive infrastructure through registrars and hosting providers. Services like Infoblox Digital Risk Protection Services (DRPS) operationalize this with rapid execution, notifying within four minutes and achieving domain takedown in approximately nine hours with a 98.9 percent success rate. \n
Together, these mechanisms deliver an immediately actionable security architecture for autonomous systems. While network controls cannot ensure an AI model generates benign outputs, they provide what the industry currently lacks: deterministic, network-layer enforcement that verifies or blocks access before an agent is able to connect.
\nWhat to Do Next
\nFor enterprises, translating this call to action into practical governance starts at the network layer. Key steps to operationalize agent security today include:
\n- \n
- Publish Agents under Your Enterprise Domain: Anchor every agent’s digital identity directly to your organizational domain (e.g., billing-agent.example.com). This ensures customers, partners and external services can unambiguously verify provenance. Start with the open-source DNS-AID repository. \n
- Enforce DNSSEC for Agents: Implement cryptographic signing on all DNS records tied to agents. DNSSEC guarantees that metadata, endpoints and identity records cannot be spoofed, poisoned or altered in transit. \n
- Configure DNS Controls for Agent Traffic: Configure internal DNS policies to detect, log and preemptively isolate suspicious or unapproved agent connections. \n
- Champion Open, Federated Standards: Support interoperable protocols that let enterprises maintain direct ownership of their agent namespaces, avoiding proprietary vendor lock-in. \n
- Join Community Experimentation: Join a community of builders to build and test controls that are open, interoperable and built on proven global internet standards. \n
At Infoblox, we remain optimistic about the future of AI safety because the foundational controls such as DNS are already in place, and the work on extending them for AI safety has already begun.
\n\n\n\t\t![](\"https://www.infoblox.com/blog/wp-content/uploads/avatar_user_388_1698771899.jpg\"){kind=avatar}
![\"\"](\"https://www.infoblox.com/blog/wp-content/uploads/dns-aid-thumbnail.jpeg\")
![\"\"](\"https://www.infoblox.com/blog/wp-content/uploads/ib-on-ib-thumbnail.jpeg\")
![\"\"](\"https://www.infoblox.com/blog/wp-content/uploads/how-many-agents-does-your-company-have-thumbnail.jpeg\")
![\"Infoblox\"](\"https://www.infoblox.com/wp-content/uploads/infoblox-logo-2.svg\"){kind=logo}