This is both something old and something new. As with many cybersecurity-related matters, such as patching, AI means we need to focus on the basics as well as come to terms with the change it is making to our roles. A classic example of a basic that can be addressed to improve security appears in this Alignment Research Blog from OpenAI.
To quote the opening of the summary section:
“An agent attempting to complete a search-based training task queried a public chatbot service through a gap in our internet-access restrictions: insufficient DNS filtering in its training sandbox.”
When I read that, my first thought was that it was an “old” case of an organization implementing security and forgetting about DNS. It is good that DNS traffic was being logged, as DNS telemetry is a key building block of any log management framework. However, DNS can also block specific domains at the resolver and can enforce the more restrictive policy of only allowing certain domains to resolve.
The “new” here is that it is not malware reaching out to a command-and-control (C2) server via something like a domain generation algorithm (DGA); rather, it is a more capable agent autonomously using DNS as a route to circumvent other controls. It is an example of the same old vector turned up to 11, as we are increasingly seeing with the use of AI.
Organizations can use several mitigations to prevent the unwanted behavior seen in the OpenAI case, such as:
- Run an internal DNS root in test environments where internet access is not required, with resolvers that use only the internal root servers. I’ve not been a fan of an internal DNS root, as it is operationally a pain, but for a highly constrained network it could be useful, and its administration could be devolved to the AI testers.
- Block all domains using response policy zones (RPZs), then operate an allow list by exception. This is more restrictive than blocking only the known-bad domains, and is the concept also espoused by Microsoft’s Zero Trust DNS. Again, administration could be devolved to the testers.
- Allow only certain DNS record types, as suggested in the OpenAI blog, so that the avenues for abusing DNS are further restricted
- Have separate AI agents actively monitor telemetry for anomalous DNS activity, e.g., via dnstap logging.
- Build controls into the AI agents themselves, such as the instruction “You must only use DNS in this way for this purpose”; however, the agents under test would then be both gamekeeper and poacher.
- Use an implementation of the Agentic Resource Discovery (ARD) specification for internal agents, together with a (possibly federated) list of approved external resources. Protective DNS can then enforce that only those domains are resolved on agent networks, because new agents are registered in a catalog such as ARD and simultaneously added to DNS as a mitigating control.
- Most likely, a combination of several of the above.
If regulation or legal precedent makes companies liable for any impact their agents cause, I would assume that the above mitigations would become proportionate controls that are expected to be in place. Of course, liability may require intent, but given that AI companies are well aware of what their agents can do, is that enough to say the companies have intent? This is an interesting question, best put to legal professionals, but one that might feature on a corporate risk register.
In the longer term, others and I have proposed standardizing DNS records within the Internet Engineering Task Force (IETF) for organizational agent indices, and for the use of records for individual agents. The proposed DNS-AID is aimed at this, and such standardization will help support controls. Again, we are back to something old and something new: ITIL has the concept of a configuration management database (CMDB), and knowing what is where on the network, what assets are for, how critical they are, what they are called and so on, is key to implementing security. This is another area given a new imperative by AI.
As we turn the AI dial up to 11, I will ironically say that we need to avoid the froth and focus on our basics, such as internet plumbing, as any standards we develop in this area could be circumvented without actively managed controls.
