TL;DR: Shadow AI creates three distinct risks: unauthorized AI services can exfiltrate sensitive data, employees can paste confidential material into public tools, and malware can use AI-enabled command-and-control channels, according to CyberFOX. DNS filtering adds visibility and enforcement at the connection layer, but governance still needs approved-tool inventory, policy, and monitoring.
At a glance
What this is: This is an analysis of how DNS filtering can reduce shadow AI risk by controlling which AI tools and external servers can connect, with a key focus on stopping unauthorized data sharing and command-and-control traffic.
Why it matters: It matters to IAM and security practitioners because unmanaged AI tools behave like ungoverned service endpoints, creating identity, data, and access risks that traditional endpoint or firewall controls may not see soon enough.
By the numbers:
- 38% of employees say they share sensitive work info with AI tools without permission.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
👉 Read CyberFOX's analysis of DNS filtering for shadow AI risk
Context
Shadow AI is not just an application governance problem. It is a control problem created by tools that can exchange data with external services outside approved procurement, identity, and security review. When those tools handle sensitive prompts, code, or business content, the boundary between convenience and exposure disappears quickly, especially when the organisation has no clear inventory of what is connected where.
The identity angle is direct. AI tools, API keys, tokens, and service accounts all operate as non-human identities when they access external services on behalf of users or workflows. If those connections are not governed, DNS filtering becomes a compensating control rather than a complete policy model. That is a typical enterprise starting position, not an edge case.
Key questions
Q: What breaks when shadow AI is not included in identity governance?
A: When shadow AI is excluded, the organisation loses discovery, ownership, and enforcement at the same time. Unmanaged local agents can access cloud and SaaS resources without being enrolled in policy, which means no one can attest to their privileges or revoke them cleanly. The first failure is visibility, and the second is accountability.
Q: Why do AI agents increase non-human identity risk?
A: AI agents increase non-human identity risk because they can execute many actions quickly once they inherit a credential or tool permission. That speed expands blast radius, shortens attacker dwell time, and makes weak delegation more dangerous. The remedy is tighter scoping, continuous verification, and strict separation between observation and execution privileges.
Q: How can security teams decide whether DNS filtering is enough for AI governance?
A: DNS filtering is enough only as an enforcement and visibility layer, not as a complete governance model. It can block unauthorized destinations and surface hidden AI usage, but it cannot replace inventory, data classification, or lifecycle control for secrets and delegated access. Teams should use it to contain risk while they build policy and ownership around AI integrations.
Q: What do organisations get wrong about employee use of public AI tools?
A: The most common mistake is assuming the risk begins and ends with the app itself. In reality, the exposure occurs when employees paste data into prompts, so the real control point is the combination of user behaviour, approved tool access, and data classification.
Technical breakdown
Why shadow AI turns DNS into a governance control
DNS filtering works at the resolution layer, before many application sessions are fully established. That makes it useful for enforcing destination policy when users or business units adopt AI tools outside central oversight. The real security value is not just blocking bad domains. It is creating an observable choke point for outbound AI traffic, which helps distinguish approved services from uncontrolled ones. In practice, this is closer to network-backed policy enforcement than classic content inspection. Practical implication: use DNS logs to build an inventory of AI services before trying to govern them by exception.
Practical implication: Use DNS logs to build an inventory of AI services before trying to govern them by exception.
How AI tools become non-human identity and data pathways
Many AI services rely on tokens, API keys, or delegated integrations to reach model endpoints, storage, and external plugins. Once a user or workflow connects through those credentials, the AI tool behaves like a non-human identity with delegated access. That creates a governance challenge because the risk is not only prompt leakage. It is also credential exposure, overbroad egress rights, and hidden third-party trust chains. Practical implication: classify AI integrations as NHI-bearing connections and review their secrets, scopes, and downstream destinations together.
Practical implication: Classify AI integrations as NHI-bearing connections and review their secrets, scopes, and downstream destinations together.
Why command-and-control traffic still matters in AI-assisted malware
AI-assisted malware does not remove the need for command-and-control. It changes the cadence, adaptability, and evasion characteristics of the traffic. If malware can reconfigure itself and query external instruction sources, defenders need visibility into outbound resolution patterns, not just payload signatures. DNS policy is relevant because it can break the lookup path before the malware receives new instructions or reaches its next staging server. Practical implication: pair DNS enforcement with detections for newly registered domains, unusual geographies, and rapid destination churn.
Practical implication: Pair DNS enforcement with detections for newly registered domains, unusual geographies, and rapid destination churn.
Threat narrative
Attacker objective: The objective is to extract sensitive information or sustain malicious control by exploiting unmanaged AI connections and the credentials that power them.
- Entry begins when employees or tools use unsanctioned AI services that establish outbound connections beyond approved security review.
- Escalation occurs when those tools receive prompts, code, or data through tokens and API keys that behave like delegated non-human identities.
- Impact follows when sensitive content leaves the organisation or malware uses outbound DNS paths to receive instructions from command-and-control infrastructure.
NHI Mgmt Group analysis
Shadow AI is becoming an identity governance problem, not just a content filtering problem. When users and teams adopt AI services without review, the organisation is really allowing unmanaged non-human identities to reach external systems. That means secret handling, delegation scope, and outbound trust all become part of the governance question. The control lesson is straightforward: if the AI connection is not inventoried, it is not governed.
DNS filtering is useful because it creates enforcement where AI policy often disappears. Many organisations can write acceptable-use language, but they cannot see every AI service or plugin that employees connect to. DNS adds a practical control plane for blocking unauthorized destinations and surfacing hidden dependencies. For practitioners, that makes DNS a visibility and containment layer, not a substitute for lifecycle governance.
Secret exposure is the real bridge between shadow AI and broader compromise. The article’s examples show how easily prompts, code, and credentials can leave the organisation once a tool is allowed to talk outward. That connects directly to OWASP NHI issues around secret sprawl and overprivilege. The field should treat AI integrations as secret-bearing pathways that need scoped approval, revocation, and monitoring.
AI security programmes will increasingly converge with network, IAM, and PAM controls. A point solution for AI prompts is not enough when the underlying risk involves tokens, delegated access, and outbound destinations. Governance will increasingly depend on combining policy, discovery, and identity controls around the AI toolchain. Practitioners should expect AI oversight to land in the same operational conversation as workload identity and privileged access.
Secret sprawl at the AI edge: unmanaged AI tools expand the number of places where secrets, prompts, and delegated access can leak. That creates a compounding governance burden because every extra AI service is another trust boundary to review. The practical conclusion is to treat AI service adoption as an identity and secrets lifecycle issue, not a convenience decision.
What this signals
Secret governance will increasingly be judged by what can be blocked, not just what can be detected. DNS-based enforcement gives teams a practical way to stop unmanaged AI traffic before policy exceptions are fully mapped. That matters because leaked secrets can persist for weeks after exposure, which means containment speed is now a governance metric as much as a security metric.
AI adoption will keep expanding the NHI estate unless teams inventory the connection layer. Every new assistant, plugin, or embedded copilot can create another delegated identity and another external trust path. Practitioners should expect their secrets management, IAM, and network policy teams to converge on shared visibility over AI connections.
The control gap is not the model, it is the path around the model. If a user can connect an AI tool to an external server without central review, the organisation has already lost part of the decision boundary. Teams should prepare for policy enforcement that spans DNS, secret lifecycle, and outbound access controls rather than relying on a single security layer.
For practitioners
- Inventory every AI service and plugin Build a live register of approved and unapproved AI tools, including browser-based services, embedded copilots, and developer assistants, so policy starts from observed use rather than procurement records.
- Block unauthorized AI destinations at DNS Use DNS policy to stop connections to unknown or high-risk AI services, while allowing only destinations that have been reviewed for data handling, geography, and logging expectations.
- Treat AI integrations as NHI-bearing pathways Review tokens, API keys, and delegated access used by AI tools with the same scrutiny applied to service accounts, including scope, revocation, and downstream trust chains.
- Monitor for unusual outbound AI behaviour Flag sudden destination changes, high-volume data transfers, and newly registered domains so AI tools that drift beyond normal use can be contained before sensitive data leaves the environment.
Key takeaways
- Shadow AI creates a governance problem because unmanaged tools can move data and secrets outside approved controls without visible review.
- DNS filtering is a useful containment layer, but AI security still depends on inventory, policy, and identity-aware control over tokens and delegated access.
- Organisations that cannot see and govern their AI connections will struggle to stop both accidental data leakage and malware command paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret sprawl and unmanaged AI connections create the leakage path this article warns about. |
| NIST CSF 2.0 | PR.AC-4 | Outbound AI access should be governed as part of access control and approved service use. |
| NIST SP 800-53 Rev 5 | AC-4 | The article centres on controlling information flow to external AI services. |
| CIS Controls v8 | CIS-5 , Account Management | AI integrations rely on credentials that need governance like any other account. |
| MITRE ATT&CK | TA0011 , Command and Control; TA0010 , Exfiltration | The article describes malware command links and data leakage through AI services. |
Map DNS detections to command-and-control and exfiltration tactics, then tune blocks accordingly.
Key terms
- 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.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Command-and-control: Command-and-control is the communication channel an attacker uses to issue instructions to malware and receive results back from a compromised host. For XWorm, the channel is encrypted and used for session management, payload delivery, surveillance, and modular expansion of capabilities after compromise.
What's in the full article
CyberFOX's full article covers the operational detail this post intentionally leaves for the source:
- Specific DNS filtering workflows for identifying shadow AI destinations and blocking unknown services.
- Practical examples of how AI tools leak data through unsanctioned prompts, plugins, and external connections.
- The article's guidance on balancing user productivity with policy enforcement and approved-tool access.
- Operational examples of why AI-assisted malware still depends on external command-and-control lookups.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls with the broader security programme they already run.
Published by the NHIMG editorial team on September 3, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org