Shadow IT waits to be found. Shadow AI doesn’t

Ten years ago, the conversation was around shadow IT. Now, it centers around shadow AI, and that’s proving much harder to deal with.

The key difference between shadow IT and shadow AI is that the former doesn’t create more problems the longer it sits there. It simply acts as a latent liability until it is discovered by attackers.

Shadow AI, on the other hand, can result in rogue agentic actions, sensitive data proliferating throughout models, and active violations of compliance guardrails. Unlike shadow IT, which typically sits dormant until discovered or exploited, shadow AI actively interacts with data, systems, and business processes. It can make decisions, take actions, and create new exposure pathways long before a security team even knows it exists.

It therefore demands a different response. While the answer to shadow IT was “find it and fix it,” the answer to shadow AI is more nuanced. It has everything to do with balance. Security teams need AI to compete, so blocking its use completely is not useful. And yet if AI tools remain ungoverned, they can be dangerous. AI tools, both sanctioned and unsanctioned, leave leadership at a crossroads.

The questions now are: how do we govern AI while it’s in flight, and what can CISOs do to lead the race rather than just be one of the runners?

The first step is accepting reality. The question is no longer whether employees are using AI tools. They are. The question is whether security teams are close enough to that reality to shape it. Security teams that only discover AI use during audits or incidents are already behind the curve.

9 in 10 security pros use (unsanctioned) AI

Data indicates that 90% of security professionals use unapproved AI tools at work. To be clear: nine out of ten cybersecurity professionals. The problem solvers are deeply entrenched in the problem, and many organizations are caught completely unprepared.

Additionally, a recent industry report reveals that nearly half (47%) of employees are using AI apps that are unsanctioned and ungoverned. While that should be the same thing, there is a case to be made for leaders just accepting the reality and resorting to governing any form of AI in use by their employees.

The same report also showed that employees were dumping sensitive data into these apps at twice the rate they were last year, doubling the damage.

Unfortunately, irresponsible AI use by employees is only part of the problem: the other part is that autonomous agents are now engaging in unsafe practices, too.

In many ways, this is the Workforce AI challenge. Every AI tool people are using to move faster, whether approved or not, is moving data somewhere. Some organizations have one AI policy for all AI use. Increasingly, security leaders are discovering they need separate approaches for customer-facing AI, proprietary AI, and workforce AI because the risk profiles are fundamentally different and require different security strategies.

These unsanctioned autonomous AI tools are given the same permissions and identity status as human workers (or better), and trusted to take their own actions, connect systems, access data, respond to emails, handle invoice requests, and, in some cases, shut down systems.

Remember when PocketOS said that an AI coding agent operating through Cursor (via Anthropic’s Claude) deleted its entire production database, including backups, in nine seconds? When queried, it responded: “I violated every principle I was given.”

In this case, Claude did enforce guardrails. The AI just didn’t listen. Jeremy Crane, the company’s founder, reported: “We were running the best model the industry sells, configured with explicit safety rules in our project configuration, integrated through Cursor, the most-marketed AI coding tool in the category.”

Implementing guardrails, knowing their limits

We’re still operating at a time when nothing in AI can be trusted; everything must be verified. The right standards and guardrails on the side of the AI vendor are crucial, but even more so are the security controls put in place in-house. Just like the shared responsibility model of the cloud, vendor accountability for mishaps is limited: the bulk of the blame falls on the company.

These guardrails are repeats of what should already be implemented in non-AI environments: data classification, visibility into which AI tools are touching which data, and clear policies across cloud and on-prem environments.

Classification is key because organizations need to know what data is public, internal, confidential, regulated, or strategically sensitive. Without that foundation, there’s no way to determine what can safely interact with AI tools and what can’t.

Visibility means knowing which AI tools are in use, whether they are sanctioned or unsanctioned, who is using them, what data sources they connect to, and what information is flowing through them. Security teams cannot protect what they cannot see. Before they can stop sensitive data from reaching AI tools, they must first establish a baseline understanding of how those tools are being used across the business.

Clear policy includes not only laying out AI AUPs on paper but translating those into workflows.

For example, if your AI Acceptable Use Policy states that no sensitive data shall be input into public AI tools, your security stack must support that with a DLP solution that can physically prevent classified information from being copied and pasted. If your AUP forbids employees from trying to prompt models into accessing protected databases, you need to be able to flag suspicious questions submitted to those sites.

If your policy requires AI tools to operate on the principles of least privilege and zero trust, it’s not enough to simply configure the security controls; you must stress test them, just like an attacker would.

The necessity of red teaming

Regardless of what officially makes it into an AI AUP, no AI tool should be sanctioned within the company without red teaming it first.

Attackers (or AI bots being launched by attackers) are going to probe the system as soon as it goes live in your environment. Conscientious organizations are going to do it themselves. This means that red-teaming AI environments should be mandatory and ongoing. Attackers don’t attack on a quarterly cycle, so tests must be done at least before the AI is approved for company use, and then as often as possible thereafter.

Test whether the system repeats sensitive information from prompts, if it exposes hidden things like proprietary internal instructions, or if it returns data it shouldn’t have access to (APIs, plugins, RAG).

It’s also important for companies to consider potential misuse cases in which employees themselves misuse it. What would happen if someone simply copied and pasted sensitive data about the customer onto an approved AI helper program? Or what if someone had too many privileges as an agent? What if prompt injection were used on a collaborative task? Traditional security assessments often miss these misuses.

The role of CISOs as AI gatekeepers

For years now, CISOs have been in a transition role, from senior practitioners to business enablers and strategists. This change has come at a good time, because AI adoption will demand more of them along those same lines.

CISOs now find themselves as the sentries of AI adoption (or sanctioned AI adoption), and as such have the responsibility to vet the business outcomes before approving the use of AI. They must be seen as enablers of AI, not blockers, which demands an understanding of what it takes to make those AI investments safe for use.

That cannot be accomplished via policies alone. Security teams require regular engagement with business units, product leads, and staff. The organizations that have come the furthest aren’t auditing the use of AI from afar; rather, they are taking part in discussions prior to any AI decision being made.

It also requires more than a bit of creativity and the ability to think outside the box. How do you protect the company from inevitable unsanctioned AI app usage? Do you pull AI full-stop (like Samsung back in 2023?) Do you sanction bespoke AI tools for work (that may not be as fast as the latest Claude model)? Do you give up altogether and find a way to govern even ChatGPT in-house?

Addressing the challenge of shadow AI requires solutions, but the first step is to grasp the problem. This means recognizing that shadow AI is much more than just shadow IT under a different name. This means recognizing that shadow AI is fundamentally different from shadow IT.

Companies that recognize this will be well-prepared for the challenge; those that don’t may well find themselves playing catch-up.

Rohit Dhamankar, VP, M&A and AI Strategy, Fortra