Policy and DNS filtering are central to safer generative AI use

At a glance

What this is: This article argues that generative AI safety depends on combining enforceable policy with DNS-level controls to restrict unapproved tools and surface usage visibility.

Why it matters: For IAM and security teams, the key issue is governance of who can use which AI services, what data they can send, and how those access decisions are monitored.

Context

Generative AI has moved from experimentation into day-to-day work, which means the risk is no longer just model quality but uncontrolled access to external services and the data users send there. The governance gap is simple: organisations often have policy intent without an enforcement layer, so shadow AI and unverified domains remain reachable.

The practical problem is access governance, not AI novelty. Once employees can reach unapproved tools from managed and remote devices, IT loses visibility into data flows, and the control model starts to resemble unsanctioned application use rather than managed enterprise access.

Key questions

Q: What breaks when generative AI policy is not enforced technically?

A: A policy that is not enforced technically leaves users free to reach unapproved AI services, which means shadow AI, uncontrolled data sharing, and inconsistent compliance become operational realities. The control fails at the point of access, so the organisation can document rules without actually limiting behaviour. Network enforcement is what turns intent into governable access.

Q: Why do unapproved AI tools create more risk than traditional software use?

A: Unapproved AI tools can process user input in ways traditional applications do not, including storing prompts, retaining outputs, or reusing data to improve services. That creates exposure when employees paste regulated or sensitive information into systems the organisation does not oversee. The risk is not only misuse, but also loss of visibility into where data goes next.

Q: How do security teams know whether AI access is actually working safely?

A: Look for three signals: complete discovery of the AI estate, clear mapping of source data to each system, and logs that prove what was accessed and why. If any of those are missing, the control environment is incomplete. Safe AI access is evidenced, not assumed.

Q: How should organisations govern generative AI use across hybrid workforces?

A: They should apply the same approval rules, filtering controls, and monitoring standards on office and remote networks so location does not change the security posture. Hybrid work increases the chance that users will bypass informal controls, so governance has to travel with the user. Consistent enforcement is the only reliable way to keep policy aligned with real usage.

Technical breakdown

Why policy without enforcement fails for GenAI access

A written AI policy defines allowed use, but it does not stop a browser or application from reaching an unapproved service. In practice, the control fails when users can still resolve and connect to unsafe domains, because the policy has no technical checkpoint. DNS filtering and Protective DNS shift enforcement earlier in the connection path, so the organisation can block risky destinations before data leaves the environment. That matters because AI use cases often occur outside traditional application approval workflows, especially when users adopt tools through browser sessions and embedded copilots. See the AI Acceptable Use Policy Template.

Practical implication: Pair acceptable-use policy with network enforcement so the allow list is technically enforced, not just documented.

How DNS filtering changes the AI access control point

DNS filtering operates at the name-resolution layer, which makes it useful for controlling which AI services are reachable regardless of the application being used. Instead of trying to inspect every prompt or every SaaS session individually, the organisation can deny resolution to domains that are unapproved, high risk, or known to impersonate legitimate AI services. Protective DNS extends that idea by adding threat intelligence and safer default handling for suspicious domains. The result is a control that acts before the session is established, which is especially valuable for remote work, unmanaged browsers, and rapid tool adoption.

Practical implication: Use DNS control to reduce exposure to shadow AI, spoofed AI sites, and unsanctioned data sharing.

Why observability is part of AI governance

Visibility tools matter because AI safety is not only about blocking access. Teams need to know which services are actually being used, how often they are accessed, and whether usage patterns match policy. Reporting and query logs provide the evidence trail needed to review exceptions, identify repeat misuse, and refine the approved toolset over time. Without that observability, organisations cannot tell whether policy is working or whether employees have simply shifted to other tools. This is where governance and telemetry meet: access control sets the boundary, while reporting shows whether the boundary is holding. See the Data Security Guide.

Practical implication: Use reporting and logs to review AI usage, validate policy decisions, and investigate repeated access to unapproved services.

NHI Mgmt Group analysis

Policy is only governance theatre until it has an enforcement plane. Generative AI use becomes risky the moment employees can reach unapproved services through ordinary web access while policy lives only in documents. DNS-level controls turn policy into an operational control by making allow or block decisions at the point of resolution, which is where many shadow AI behaviours actually begin. Practitioners should treat this as an access-governance problem, not just a user-awareness problem.

Shadow AI is an identity and access issue as much as a data issue. The article correctly frames the problem around unseen tools, but the deeper issue is uncontrolled access to external services that can accept corporate data. Where AI tools are accessed without inventory, approval, or monitoring, the organisation has lost track of who can send what to which service. agent identity and access becomes relevant as AI use matures, because unmanaged service access is the first step toward unmanaged AI behaviour. Practitioners should align AI tool governance with access governance, not separate them.

Observability is the difference between policy intent and policy assurance. Reports, logs, and usage data do not prevent every misuse, but they reveal whether approved tools are actually being used and whether exceptions are becoming normalised. That is the point where governance stops being static and becomes measurable. For security programmes, the lesson is to treat AI telemetry as part of control validation, not as an afterthought. Practitioners should make usage reporting a standing input to policy review and exception management.

Named concept: AI access boundary control. The article points to a practical model in which AI safety is governed by the boundary between reachable and unreachable services, not by promises of responsible use alone. This is consistent with NIST-CSF access control thinking and with the basic IAM principle that governance must be enforceable at the control point. Practitioners should define and monitor the boundary, then adjust it as approved AI usage changes.

From our research library:

• According to Gartner, worldwide spending on generative AI is set to reach $644 billion in 2025, a nearly 77% year-over-year increase.

What this signals

AI access governance is becoming the practical control plane for enterprise GenAI. As approved and unapproved tools proliferate, teams will increasingly need to manage reachability, logging, and exception handling as a single governance workflow rather than three separate tasks. Generative AI data loss prevention is the natural next control domain when organisations move from blocking risky destinations to managing what users can safely share.

Policy design will matter less than enforcement quality. The organisations that get better outcomes will be the ones that can prove their allow lists are enforced on every network path, including remote access. That shifts AI governance from policy publication to control assurance, which is where security programmes can actually measure whether generative AI use remains inside approved boundaries.

For practitioners

• Define an approved AI service list Document which generative AI tools are permitted, which data classes may be shared, and which use cases are prohibited so users have an explicit boundary for daily work. See the AI Acceptable Use Policy Template.
• Enforce access with DNS filtering Block resolution to unapproved, high-risk, or spoofed AI domains so policy decisions are enforced before a connection is established.
• Extend controls to remote users Apply the same AI access rules on managed and off-network devices so hybrid work does not create a policy gap.
• Review AI usage telemetry routinely Use reporting and DNS query logs to identify repeated access to unapproved services, validate exception handling, and adjust policy as tool usage changes.

Key takeaways

• Generative AI safety depends on controlling which services users can reach, not only on telling them what they may use.
• DNS filtering and Protective DNS create an enforcement layer that policy documents alone cannot provide.
• Visibility into AI usage is what lets security teams validate policy, spot shadow AI, and adjust controls as adoption changes.

Related NHI Mgmt Group resources: Generative AI Data Loss Prevention Guide · AI Acceptable Use Policy Template · Agentic AI Security Policy Template

Key terms

• Generative AI Security Risk: Generative AI security risk is the chance that a generative model, its prompts, outputs, training data, or integrations will cause harm to systems, data, or people. It includes prompt injection, data leakage, unsafe code generation, model manipulation, and misuse of generated content across identity, cloud, application, and SOC workflows.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• DNS Filtering: DNS filtering is a control that blocks, allows, redirects, or reroutes traffic based on domain resolution requests. It reduces exposure to phishing, malware, and unwanted destinations by applying policy at the point where devices attempt to resolve names into reachable internet endpoints.
• Protective DNS: Protective DNS is the use of DNS policy and intelligence to prevent access to harmful or non-compliant destinations. It combines domain resolution with security controls such as threat blocking, category filtering, and reporting, giving organisations an early checkpoint that works across devices, locations, and work models.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is suited to practitioners who need to connect identity governance to emerging AI access and control patterns.