Read more ->
Agentic AI and DNS liability with Alan Woods (CleanDNS)
12 Min
AI agents are registering domains and rewriting DNS records without anyone approving each step. When automation gets it wrong, who answers for it? Read on to dive in.
Published by
Simone Catania
Date
26/08/2026
AI systems are increasingly acting on their own. They register domains, configure DNS records and reissue certificates without a human approving each step. That reopens legal questions our existing frameworks were never built to answer. Who is liable when an autonomous system causes harm? And how does a company prove its automation acted responsibly rather than recklessly?
The answers live in two places at once: in the code, and in the contract. A domain suspension looks like a low-risk technical action from inside an operations team. Seen from outside, the same action can look like arbitrary interference with a functioning business. Between those views sits a growing stack of obligations governing how domains are managed, from ICANN’s contracts to the Digital Services Act’s demand for proportionate enforcement. Automation does not remove that tension. It scales it.
To unpack this, we’re joined by Alan Woods, Chief Legal and Policy Officer at CleanDNS, an anti-online-harms company working with registries, registrars, hosts and brand protection providers. A professionally qualified Barrister (Ireland) with qualifications in data protection and e-law, Alan’s ICANN work spans both the Contracted Parties House and the Non-Contracted Parties House, from Vice Chair of the Registries Stakeholder Group to the DNS abuse contract amendments and the SSAC’s SAC115 paper. He takes the Nomcom-appointed GNSO non-voting seat in October 2026.
Read on for our full conversation with Alan on liability, regulation and the legal gaps opening up in the age of agentic AI.
1. You trained as a barrister before moving into DNS policy and abuse management. Looking at how companies handle domains and DNS today, what legal exposure do they underestimate, the kind a purely technical team would never think to flag?
The pressure to do more against abuse, set against the often-ignored obligation of proportionality under legislation like the Digital Services Act (DSA).
The DNS industry, and ICANN in particular, has become the focal point of the abuse mitigation battleground. Not because it is the most appropriate place to act, but because ICANN can enforce obligations on all contracted parties. Nothing equivalent exists for hosting or social media, so all roads lead to the DNS. That enforcement asymmetry has created a massive legal choke point.
On one side, DNS operators face growing obligations and vilification for not doing enough, which in turn becomes the justification for yet more obligations. On the other, legislators and civil society demand transparency, proportionality and necessity in how those obligations are discharged. These pressures are converging fast.
The problem is that technically minded teams tend to treat all domain takedowns as low-value, low-risk actions. The registration is contractual, acceptable use policies disclaim any need for justification, so down it goes. But interfering with an operating business’s domain can generate real damage: lost revenue, customer attrition, reputational harm and considerable mitigation costs. Simply put, every action taken needs a justification and an understanding of its consequences.
The DSA makes this tension explicit. Article 14(4) requires intermediary service providers to act “in a diligent, objective and proportionate manner” when enforcing their terms, with due regard to the rights and legitimate interests of all parties, and it requires non-arbitrary and non-discriminatory conduct. So in a world where reputation blocklists are accepted at face value and actioned without validation, we are on a legal collision course.
Add to this that ICANN compliance operates on an exception basis, where a single complaint can trigger a compliance inquiry regardless of the quality of the underlying process. Without the right support, operators sometimes feel they face only a binary choice: act quickly on unsubstantiated reports, perhaps arbitrarily, or risk compliance action that threatens their contract with ICANN. That tension between “do more” and “do it right” is, I feel, where the real legal exposure lives.
None of this means progress isn’t being made on DNS abuse. But the tendency to prioritize the quick and easy fix, the arbitrary action, is neither sustainable nor supportive of the due process and innovation needed for lasting, real impact.
2. CleanDNS works on the policy and legal side of DNS abuse, not just detection. At what point does a DNS incident stop being an engineering problem and become a legal one, and where does the line sit between what an operator must do and what it should do?
In a word: evidence.
Nobody in this industry believes our role in this fight is static. As attacks grow more sophisticated, the expectation to do more grows right alongside them. For our policy advocacy, we prefer to be informed by what the team at CleanDNS sees daily in operations. Where are the process pain points? Are there gaps in understanding of the processes we run every day for registries and registrars? Have we identified new forms or categories of abuse we think we can tackle with a clear evidence and threshold expectation?
But we need to be very clear on the line between what must be done and what should be done. One is obligation, the other is best practice. This is not new. It was a key part of the Framework to Address Abuse, where a group of registries and registrars stated clearly that where they believe they can appropriately disrupt a harm, as long as the action is proportional to that harm and it is appropriate for them to take it, then they will. Domains used exclusively for the dissemination of child sexual abuse material are the clearest example.
Policy work can be frustrating, because the starting point is always “harm is happening, do something.” But action requires clear problem statements, repeatable evidence thresholds, and an understanding of impact and proportionality. “DNS abuse” is defined as it is because we know there are clear evidence thresholds and it warrants action that can be considered both proportional and appropriate at the domain name level. Those definitions may, and should, evolve, but that evolution has to stay grounded in these concepts.
It is also worth remembering that action may be more appropriate, or simply more accessible, for some operators than others: better resources, a different business model. Just because one entity can act, and does, does not mean it is appropriate for another. With time and replicability that may become a minimum expectation. But the “put everything into the contract” argument you hear in some advocacy can be counterproductive and inhibit progress.
3. Automated systems now change DNS records, reroute traffic and reissue certificates without anyone signing off each step. When one of those decisions causes harm, liability frameworks have no clean answer: the operator, the tool vendor, or nobody. How should companies be designing automation so that question never has to be settled in court?
As we look towards more automation, CleanDNS believes a human must still be in the loop at some point. Humans set the lines of responsibility and make sure the process is clear. No automated system will be perfect, and the human’s objective is to build an automation that minimizes both the risk and the impact, so that if something does go wrong the consequences are minimal and easily reversible. Humans provide the conditions that seek to ensure the outcome of the automation is objectively justifiable.
That requires clear expectations, including documented processes and controls. It is a great deal more than just a prompt added to an AI agent.
The aim should be to achieve a number of safeguards:
- Access must be controlled and logged. Know who accesses the system, and ensure only authorized people can use it.
- Auditability. Logs of every action must be present. Anything less than a full audit trail is not acceptable.
- Agreed expectations, with room to change. Every action must be approved against agreed thresholds and workflows. Onboarding and understanding risk tolerance is key. Control the risk as far as possible, so that errors, if they occur, are low-risk or low-impact. And after all that, be prepared to change if you need to.
- Understand that failure is not necessarily a bad thing. We learn when things go unexpectedly, and you have to adapt accordingly. Controlled failure is an opportunity to evolve.
4. Say something does go wrong and a regulator or claimant comes knocking. In practice, how does a business show that its automated system acted reasonably rather than recklessly, and what actually makes the difference when you are the one defending it?
Audit trail, audit trail, and then, just to be safe, audit trail.
Take CleanDNS as an example: the system can act as a 100% end-to-end process, from ingest to action, for our clients. Having a comprehensive audit trail of that process is fundamental. In the case of DNS abuse it cannot be just about timestamps and users. We need to tell the story of why Report X resulted in Action Z. Any action, automated or not, must be non-arbitrary and necessary, and so we have to show the journey through our system. All of it recorded in an intuitive and understandable manner. Minimize the shadows in your system, and in the event of an exception, let your work, or the work of your system in the case of automation, speak for itself.
On recklessness, remember that no system is perfect. It remains your obligation to assess the risk, minimize it and, I feel, err on the side of caution. Overreliance without truly understanding your risk is the epitome of recklessness, and any claim to unerring certainty will defeat you. For some reason, with AI, people are beginning to expect perfection, and that technological over-expectation is part of the problem. Automation works because of careful preparation and adaptability. If you are in doubt about any process, review it now rather than feel remorse later.
5. Harm often doesn’t start with the domain holder. A site gets compromised, or a service gets exploited by the very users it was built for. When something abusive is happening under a company’s domain but not by its hand, does that distance reduce its legal exposure or only its visibility? And does knowledge change the answer?
Two very different scenarios come to mind.
First, the company whose website or infrastructure has been compromised: a third party exploits a weakness and buries a phish in a subdomain. I have never once considered automatically blaming such a company. The impact of this abuse falls on both the phishing victims and the compromised company itself. Once notified, matters morph slightly and responsiveness becomes key. Clear notification and evidence of the issue should lead to timely remediation by the relevant provider. If there is knowledge and nothing happens, then whoever is dropping the ball has triggered a much broader question of negligence and recklessness.
The second scenario is “exploitable services”: social media sites, file shares, dynamic DNS, where third-party use of the service is a feature of the website or of the content associated with the domain. Here the bar should be significantly higher. If you provide a service, you are expected to deal with abuse occurring on it. This is less a domain issue, and liability should attach to the service provider, not the infrastructure provider. Barring extreme circumstances, it would be hugely inappropriate, and very damaging, for a DNS provider to intervene with a domain takedown. That action comes with potentially massive financial impact and business loss, and with less quantifiable but equally tricky impacts on speech and expression. It would be unfair for liability to attach to the registry or registrar when the risk in forcing such an action is so immense.
Where the harm sits versus where the action lands
| Scenario | Is DNS-level action appropriate? | Where responsibility sits | What decides it |
|---|---|---|---|
| Domain registered exclusively to cause harm, for example CSAM dissemination | Yes, action is proportional and appropriate at the domain level | The registrant | Clear evidence threshold, no legitimate use to damage |
| Legitimate site compromised, phish buried in a subdomain | Rarely. Remediation belongs with the host or website operator | Initially nobody, then whoever fails to act once notified | Responsiveness after notification |
| Exploitable service, such as file shares or dynamic DNS, abused by its own users | No, barring extreme circumstances | The service provider, not the infrastructure provider | Third-party use is a feature of the service |
| Automated action taken without justification or record | The action itself becomes the exposure | The operator who acted | Whether the decision was non-arbitrary, necessary and recorded |
6. Regulation for online infrastructure is tightening unevenly: NIS2 and stricter registration-data obligations in the EU, very different priorities elsewhere. Working across jurisdictions, where is the biggest mismatch between where regulators are putting their attention and where the real risk actually sits?
The biggest mismatch is between the intended goal and the means of achieving it, where the purported cure makes the recovery more difficult.
I recall a “day zero” event before an ICANN meeting where European Commission officials, some with a direct hand in NIS2 Article 28, were told plainly by a group of registrars how Article 28 would put European registrars, particularly SMEs, at a competitive disadvantage. Words like “toxic legislative environment” were used. The Commission representative seemed more offended than anything, categorically stating there was no impact, oblivious to the consultation happening in front of them in real time. A prime example of the tension between top-down and bottom-up regulation in tech.
At CleanDNS we welcome interaction between the differing levels of the stakeholder chain. We have no doubt legislators have good intentions in pursuit of a broad middle ground, but that has to be supplemented by the technical depth, data and experience of those at the coalface of the issues at hand.
GDPR, though it did not really change the core principles of the Data Protection Directive, led to a far tighter compliance stance on data processing in the domain name ecosystem. NIS2 Article 28 was an attempt to put that genie back in the bottle. Instead it fractured the universal data-processing expectations set at ICANN and complicated matters for EU-resident companies, with higher costs, increased scrutiny and enhanced risks. The real risk is that these unintended consequences harm European businesses while restricting the use of data in the fight against abuse, which was one of the intended goals in the first place.
7. Last one. If you had to give a single piece of advice to a company automating more of its domain and DNS operations right now, what would it be, the thing that protects them legally before something goes wrong, not after?
Perfection is a dream. Plan instead for well-designed, well-controlled risk management. Prepare for low-risk, controllable actions to minimize the impact when things go wrong. Maintain due process, take justifiable action fitting the evidence you hold and, above all, record it. If your actions were demonstrably justifiable and reversible, then on those rare occasions when the automation goes awry, you and your business will be protected. We need to take some risks in this fight, but they don’t have to be stupid ones.
And it goes without saying: if you need a team to help you work through these topics, feel free to reach out to my team at CleanDNS.
Latest in
domains
