Artificial Intelligence

Visibility and the shadow AI crisis

Enterprises are in the middle of a global AI gold rush. Development teams are scrambling to work Large Language Models (LLMs) and generative AI into their products and workflows at a breakneck pace. For many, that pressure is piling even greater pressure onto already strained security practices. IBM found that in 2025, one in five organisations reported a security incident tied to shadow AI. What’s more, those with high levels of shadow AI were found to have paid an average of $670,000 more per breach than those that kept it under control.

While that number is striking, the AI-Native Application Security report suggests it’s only the surface of a deeper problem. Shadow AI isn’t just a new risk category – it’s a symptom of organisations losing sight of where their software components live, how they behave, and who is responsible for securing them. Meanwhile, structurally siloed development and security functions and manual reporting and communication processes are allowing that gap to widen by the day. Without addressing these issues, organisations risk trading short-term innovation speed for a security posture they can no longer see or defend.

Shadow AI as the invisible attack surface

AI-native applications have moved from experiment to enterprise standard faster than most security teams can react. Today, 61% of new enterprise applications are being designed with AI components baked in from the start. However, as these applications flood the enterprise, teams are struggling to keep track of where AI technologies are used or the vulnerabilities they bring. This visibility gap is giving rise to shadow AI, with 62% of security practitioners admitting they have no way to tell where LLMs are deployed across their organisation.

Governance frameworks weren’t built for systems that learn, adapt, and evolve daily – they were built for static code and predictable systems. This mismatch is making shadow AI increasingly difficult to maintain. Untracked models, unsanctioned tools, and undocumented integrations have embedded themselves across the enterprise, invisible to the teams responsible for securing it. The result is an attack surface that is expanding faster than anyone has mapped it.

Organisations are already reporting security incidents tied to the use of these AI capabilities: 76% of enterprises have experienced prompt injection incidents, 66% have been hit by vulnerable LLM code, and 65% have seen jailbreak attempts. These aren’t theoretical risks in a future threat landscape; they are incidents that security teams are actively responding to right now, often without visibility into where the exposure originated.

The development-security divide

The visibility gap points to a more stubborn issue beneath the surface. In the rush to deploy AI, a structural disconnect has formed between security and development teams – and it starts long before any code reaches production.

When creating a new application, security is usually brought in only if developers choose to engage them – making oversight dependent on manual hand-offs, rather than built in processes. For security teams, that means consistently arriving after the risk has already been introduced – inheriting systems they had no hand in shaping, and with no context to work from when something goes wrong. In an AI-driven world, that dependency becomes the flaw.

In many cases, there is also no clear owner for AI security, and the pace is amplifying that ambiguity. Developers are under pressure to ship quickly, so governance processes are treated as roadblocks and sometimes bypassed entirely. The result is a cycle in which AI components enter production ungoverned, security teams inherit the exposure, and the window to catch problems before they become incidents keeps shrinking.

This problem is only compounded by a skills gap that neither side has fully resolved. Nearly two-thirds (62%) of enterprises say developers don’t have time to implement comprehensive AI security or the training to support it. Even if they wanted to embed security in AI applications, they wouldn’t know how. Meanwhile, 75% of security leaders say applications evolve faster than they can keep up. This is widening the gap between the speed at which teams can build and secure their software.

Embedding security without slowing down

Without tighter collaboration and clear responsibilities, organisations risk a cycle in which speed accelerates innovation but also amplifies vulnerability. The answer isn’t slowing development down, but making security a native part of how AI applications get built, rather than a checkpoint at the end of the process.

Security should be embedded across the entire software development lifecycle – before, during, and after code. That starts with discovery, but not as a manual or periodic exercise. Visibility into AI components must be system-generated, continuously and automatically captured at the point they are created, integrated and deployed.

From there, teams can gain visibility into AI components, the APIs that connect them, and the outputs they produce. When such insight is embedded into the delivery pipeline itself, anomalies can be detected early – before they escalate into incidents.

Testing and runtime protection can help to further close the loop. Dynamically testing applications against AI-specific threats before they reach production, and actively inspecting prompts and monitoring responses once they’re live, shuts the door that attackers are currently walking through. Yet, enterprises must remember that none of this will hold if the underlying model remains the same. The problem isn’t simply that developers are failing to involve security early enough – it’s that the system relies on them to do so. Governance must be embedded into the delivery workflow and not be dependent on human handoffs, with risk mitigation built directly into how AI systems are developed.

To get ahead of shadow AI, organisations must take a holistic approach that treats visibility, governance, and security not as constraints on innovation but as conditions for it. That means embedding security into every stage of the AI development lifecycle whilst ensuring developers and security teams operate from the same playbook.

The organisations that thrive will be the ones that stop treating security as something to bolt on at the end. It’s time to start building the kind of resilience that lets developers move faster without breaking things.

Martin Reynolds is Field CTO at Harness

Main image courtesy of iStockPhoto.com and Shutter2U

Please take 30 seconds to register

Already have an account? Sign in