DNS for AI Governance : Your AI program Isn’t Stuck on Technology

There is a meeting happening in your organization right now, and it is going badly.

A business unit has an AI initiative that works. The pilot was successful. The efficiency numbers are real. They want to expand it, and to expand it they need sign-off from risk, legal, or security, and somebody in that room has asked a version of this question:

What data does it touch, what is it connected to, and who else is already using something like it?

Nobody has an answer. Not because the team is careless, but because the question is genuinely unanswerable with the tooling most enterprises have. So the initiative goes into a committee, and the committee meets monthly, and four months later a competitor ships the thing.

That’s the AI governance problem as executives actually experience it. Not a breach. A stall.

And the reason I want to talk about DNS is not that it will stop an attack, though it will. It’s that the inability to answer that question is what’s costing you speed, and the answer has been sitting in infrastructure you already own, unread, the entire time.

There’s a second question the same logs answer, asked by a different part of your organization and arguably more urgent. I’ll get to it.

Key takeaways

• AI governance fails at the identity layer by construction. Identity and access tooling governs principals it already knows about; shadow AI consists entirely of things nobody enrolled. The gap is categorical, not a coverage problem you can buy your way out of.
• DNS is the only pervasive, pre-connection control point. Everything resolves before it connects, including what you’ve never heard of, which makes resolver logs the one telemetry source covering attempts rather than enrollments.
• This is a speed argument, not a safety one. The organizations that can answer what is our AI touching move initiatives out of committee faster. Governance capability is throughput.
• The same logs answer an operations question. With one application per host-name, resolution data gives you a ranked hypothesis about which applications are live and which are dormant, the triage input that AI-accelerated delivery has made urgent and that AI-built applications rarely instrument themselves.
• Know the limits before you build on it. DNS shows a requested name and, if logged, the client that asked. Not content, not intent, not proof a connection followed. It does not see locally-run models or stdio MCP traffic, and it complements DLP and egress inspection rather than replacing them.

The gap is structural, not a tooling failure

The instinct is to buy something that discovers AI usage. It’s reasonable and it’s usually a wasted quarter, because the discovery problem is not a coverage problem. It’s a category problem.

Identity and access governance, the layer everyone reaches for first, governs principals it already knows about. It is very good at this. It is also, by construction, incapable of seeing something nobody onboarded. And the entire shadow AI problem consists, by definition, of things nobody onboarded.

An employee pasting customer data into an unsanctioned model produces no IAM event. An agent reaching for an endpoint nobody registered produces no IAM event. You cannot govern these at the identity layer because at the identity layer they do not exist. You will not fix this by enrolling harder, either. A principal specifically designed to find paths you didn’t anticipate cannot be governed by a list of paths you anticipated. The exploration is the product. If your allowlist were complete, you wouldn’t need the agent.

So the governance point has to be one that requires no prior knowledge of the thing being governed. It has to see attempts, not enrollments.

In the modern stack there is exactly one control that is both pervasive and pre-connection. Everything resolves before it connects, including the things you have never heard of. Especially those.

Which is why this number should bother you. In a 2025 Forrester Consulting study of 218 senior security decision-makers, 90% now rate DNS monitoring as important as their firewall, and 67% report limited visibility into DNS traffic, with insufficient analytics and threat intelligence to interpret what they can see. Ninety-five percent had faced a DNS-related attack or vulnerability in the preceding year.

Nine in ten say it matters as much as the firewall. Two in three can’t see it. The telemetry is already being produced by infrastructure you already run and already pay for.

This is a velocity argument, not a safety argument

Here’s where I’d push back on how DNS usually gets sold, including by people who agree with me.

Foundational technology is not a lesser category than identity or endpoint. It’s a different category, and treating it as a lower rung is why it never gets funded properly.

Foundational done right is tires on a Formula 1 car. Nobody puts tires on the poster. But they are frequently the limiting factor on how fast the car can go, more than anything else on the vehicle. That’s the part people miss when they file DNS under risk reduction. Tires are not a safety feature. They’re a performance feature. They are what lets you take the corner at speed instead of braking for it.

Governance capability works the same way. The organizations that can answer what is our AI touching are not merely safer. They are faster, because the answer is what gets an initiative out of committee. Every AI project in your portfolio is going to hit that gate. You will hit it repeatedly, for years. You can hit it with an evidence-backed answer that takes an afternoon to produce, or you can hit it with a four-month discovery exercise every single time.

That compounds, and it compounds in both directions:

Deals. Enterprise customers are now sending AI-specific security questionnaires. What AI systems process our data? What third-party models have access? How do you detect unsanctioned AI use? If your answer is “we’re developing that capability,” you’re not managing a risk posture. You’re losing revenue to a competitor whose answer is a report.

Audit. EU AI Act obligations, sector regulation, internal audit. Someone will ask what AI touched what and when. That record exists at the resolver or it doesn’t exist anywhere.

The shadow AI you didn’t sanction proceeds regardless. This is the part executives underrate. Slowing the approved program does not slow the unapproved one. It accelerates it, the same dynamic that produced shadow IT, for the same reason. Employees weren’t reckless then and they aren’t now. They were pragmatic, and approved tooling couldn’t match business velocity. Every month your AI program sits in committee is a month your staff solves the problem themselves, on tools you haven’t evaluated, with data you haven’t classified.

The governance gap and the adoption gap are the same gap. Closing it is how you go faster.

The argument that actually gets this funded has nothing to do with security

If you are the person who has to sell this internally, lead with this one instead. It lands with stakeholders who do not attend your threat briefings.

AI compressed the distance from kickoff to MVP. It did not compress day 1 and after, not by a minute. Provisioning, access reviews, patching, dependency upgrades, the ticket at 4:45 on a Friday: none of that got faster. So if your organization now ships ten times the applications with the same operations headcount, throughput did not increase. The bottleneck moved downstream, and the team it landed on will solve it the only way they can, by slowing intake.

Here’s how that surfaces:

“We deployed seventy-three new applications this month. You need to support them all.”

Nobody in that room knows which of the seventy-three matter, so it gets settled by whoever escalates hardest. Now the version with data:

“Yes, and three of them have sustained user interaction. That’s where the support resources go. Here’s the evidence, and here’s the review date for the other seventy.”

And raw usage counts don’t settle it either, because support profile isn’t user count. An app used by 80% of the company one day a quarter is a burst-capacity problem: flawless on the last day of the quarter, ignorable otherwise. An app used by 1% for six hours a day, every business day, is a sustained-reliability problem with a pager attached. A headcount metric ranks those two backwards.

The catch is that answering this needs usage telemetry, and AI-accelerated apps are the least likely to have any. Instrumentation is a phase-two concern, and in a build cycle measured in days, phase two often never arrives. The faster it was built, the less likely it can tell you whether anyone uses it.

DNS doesn’t need the application’s cooperation. A client reaching an app by name has to resolve it first, and that lookup is recorded whether or not telemetry was ever scoped. What you get is distinct clients, the spread of activity over time, and the shape of the drop-off after launch.

Be precise about what that supports. A lookup is not a session, a user, or a transaction. It says a name was requested, not that the app was opened or by whom. Clients that resolved something in week one and never again are a strong indication that nothing is happening there, though not proof; they might be reaching it through a proxy resolving on their behalf, or from a cached record. Reaching it by raw address is a thinner escape than I’d assumed: for anything served over HTTPS, certificate validation generally needs the host-name, and on dynamic cloud addressing the IP isn’t stable enough to hardcode. So for hosted applications, absence of resolution is better evidence than I gave it credit for. What this gives you is a ranked hypothesis: these three look alive, those sixty look dead, and a list of owners to go confirm it with.

Still a categorically better position than no data, which is where most organizations are. Not an analytics platform, and don’t present it as one.

The data is also retroactive, within whatever your retention allows. It was accumulating before anyone thought to ask.

That’s an operations win with a security substrate underneath it, which means the budget conversation doesn’t have to start in the security column. Use that.

What this does not do

Before anyone builds on the above, the limits, which are real and which I would want stated by anyone selling me something.

DNS shows a requested name and, if your resolver logs it, the client that asked. Not content, not intent, not proof that anything followed. A lookup for a model provider’s API is identical whether an employee is drafting an email, an agent is walking a customer database out the door, or a link preview fired and nothing happened. A resolution is a request for an address, not evidence of a connection, a transfer, or a human.

Resolution count is not call count. Client-side caching and connection reuse sit between them, so an agent working over one persistent connection may resolve a name once an hour behind ten thousand calls. Distinct clients is a sturdy number. Volume is not.

Local transport is invisible. A model running locally resolves nothing, and neither does a stdio tool call between an agent and a server on the same machine. What you can still see is what that server reaches for next, because an onward connection to a named data source does resolve.

This is not your AI governance program. It’s the substrate underneath it. You still need policy, ownership, and an answer for what happens when someone violates it. Pair it with DLP and egress inspection rather than instead of them.

What DNS uniquely provides is pervasive, pre-connection coverage of things nothing has onboarded yet, which is precisely the population your identity layer is structurally blind to. A bounded claim, and enough to make this the first move rather than the fourth.

Where this goes next

Everything above is the case for doing this. The sequence for actually doing it, the discovery query and what it costs, closing the resolver bypass surface, graduated policy, audit evidence, and the portfolio triage query, is in the companion piece: How to Use DNS Resolver Logs for AI Governance.

Two things worth knowing before you go there. Most of the first steps are configuration and query work against infrastructure you already own rather than new licence spend. And the parts that do cost money, log retention in particular, cost more than the usual pitch admits, which is why Part 2 puts real numbers on them.

WHAT TO DO ABOUT IT

TO CIOs AND CTOs: Ask your operations lead which applications shipped in the last ninety days, and which of them anyone is using. If the second half of that question can’t be answered, you don’t have a support prioritization problem. You have a measurement problem, and it’s cheaper to fix than the headcount you’re about to be asked for.

TO CISOs: Stop funding this out of the risk budget. It loses there, every time, because it isn’t the scariest line on the page. Move it to the column where it belongs, the capability that decides whether your AI initiatives clear governance in a week or a quarter. Then go and ask how much of your estate resolves through something you don’t operate.

TO BOARDS: When someone presents your AI strategy, ask one question. What is it touching, and how do we know? If the answer takes a quarter to produce, that’s your actual constraint, and it has nothing to do with models.

TO ANYONE ABOUT TO BUY SOMETHING FOR THIS: Read Part 2 and run the discovery query first. You may find you already own the answer, and you will certainly negotiate better knowing what your own data looks like.

About Howard Holton

Howard Holton is Founder and Chief Analyst of Phronia Counsel. This piece was produced in connection with a sponsored engagement with EfficientIP. EfficientIP had no editorial control and reviewed the draft only for factual accuracy regarding its own products

Howard Holton Founder & Chief Analyst at Phronia Counsel

Howard Holton is the Founder and Chief Analyst of Phronia Counsel and former CEO of GigaOm. With over 40 years of experience in technology, including 20 years in executive roles as CIO, CTO, and CEO, he brings extensive expertise in network infrastructure, DNS, DDI, cybersecurity, and AI. His work focuses on the importance of foundational technologies in supporting enterprise operations, security, and digital transformation.

See Full Bio

DNS IPAM Cybersecurity