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

Why This Matters for Security Teams

Unapproved AI tools are not just another category of shadow IT. They often sit outside enterprise identity controls, data retention rules, and monitoring paths, which means sensitive input can be copied into systems that are trained, logged, or retained in ways the organisation never approved. That changes the risk profile from simple policy violation to potential data exposure, compliance failure, and loss of control over downstream use.

Traditional software use is usually easier to bound because the organisation knows the application, the vendor, and the standard data flow. With unapproved AI, the same prompt can become stored content, model training material, or a reusable output artifact. That is why questions about tool approval are really questions about governance, visibility, and data handling discipline. This is especially important where secrets, regulated data, customer records, or source code are involved, as highlighted in NHIMG research such as The State of Secrets in AppSec and the OWASP NHI Top 10.

NIST’s Cybersecurity Framework 2.0 still applies, but the operational challenge is that many AI tools bypass the controls that would normally enforce asset inventory, access management, and data protection. In practice, many security teams encounter the impact only after staff have already pasted sensitive material into an unapproved tool and the exposure has left the organisation’s control boundary.

How It Works in Practice

The practical difference is that traditional software usually processes data within a known service model, while unapproved AI tools may ingest prompts, store conversation history, retain files, or use submitted content to improve services. That creates several overlapping risks: data leakage, accidental disclosure, policy violations, and the inability to prove where information went next. Current guidance suggests treating these tools as data destinations, not just productivity aids.

Security teams should evaluate unapproved AI through the lens of data classification, identity, and retention. The key question is not whether the tool is “useful,” but whether it can be used without transferring sensitive data outside approved controls. Where business use is legitimate, organisations should prefer approved platforms with explicit retention terms, enterprise logging, and clear admin visibility. Where the tool cannot be governed, blocking or restricting its use is often the only defensible option.

• Map which data classes are prohibited from being entered into external AI tools.
• Require approved AI services to be tied to enterprise identity and logging.
• Review whether prompts, outputs, and uploaded files are retained or reused.
• Extend DLP and CASB controls to detect pasted secrets, code, and regulated data.

NHIMG’s analysis of non-human identity exposure in The 2024 ESG Report: Managing Non-Human Identities reinforces the broader issue: once control over a digital actor or tool is lost, incident volume tends to rise quickly. That is why unapproved AI should be managed as an access and data-governance problem, not only an acceptable-use issue. These controls tend to break down in bring-your-own-AI environments because the organisation cannot inspect the vendor’s retention behavior or prevent users from pasting data into unmanaged sessions.

Common Variations and Edge Cases

Tighter AI control often increases friction for employees, requiring organisations to balance productivity against confidentiality and compliance. That tradeoff becomes sharper in teams that rely on external summarisation, code assistance, or research tools to move quickly. There is no universal standard for this yet, so current guidance suggests using risk-based tiers rather than a blanket yes-or-no approach.

Some unapproved tools are lower risk if they are used only with public information and no login, but that exception is narrow and easy to misuse. The moment users begin pasting source code, customer records, or secrets, the risk profile changes materially. This is why NHIMG’s Top 10 NHI Issues and the DeepSeek breach are useful reference points: the problem is not only the tool itself, but the control gap between user intent and organisational oversight.

One practical edge case is internal experimentation by engineers or analysts. Even when the tool is not malicious, it can still create evidence problems if outputs are stored in personal accounts or copied into unmanaged repositories. Another is consumer AI embedded inside browser extensions, messaging apps, or mobile keyboards, where sensitive text can leave the enterprise without an obvious approval event. Best practice is evolving, but the safest default remains simple: if the organisation cannot see, classify, and govern the data path, it should not be treated as approved.

Related resources from NHI Mgmt Group

• Why do AI coding tools create a larger identity risk than ordinary software downloads?
• Why do SaaS tools create more access risk than traditional software?
• Why do AI assistants create more credential risk than traditional developer tools?
• Why do hidden AI tools create a governance risk beyond ordinary software sprawl?