AI! It's in everything, everywhere, all at once! It’s reading emails, summarising meetings, drafting documents, and writing code, and it’s no longer just giving us answers. We now also have agents that act on their own, access other systems, and make decisions with little to no human oversight.

From a capability standpoint, it’s amazing. However, from a security, governance, and compliance standpoint, it’s a bit of a nightmare, as adoption often ploughs ahead of our ability to govern it.

Here, I’d like to talk about that gap. Where it shows up, why the controls we’ve always relied on keep missing it, and three key risks I think deserve the most attention right now: agent security, data exposure, and shadow AI.

AI is now everywhere, in almost every organisation. It’s reading emails, it’s sending emails, it's summarising Slack channels, its transcribing calls, drafting documents, and spotting trends across core business data. Just about every form of knowledge work now has some form of AI bolted onto it, and on top of that, most of the tools we already use are now embedding AI features.

There’s no denying that the productivity gains are very real, but the problem is that each productivity gain comes with a new risk, and often, these two things are not weighing evenly against each other. Ultimately, when forced to choose between productivity and policy, people will choose productivity almost every time.

If adoption were low, this wouldn't be too alarming, but 

 found that 67% of organisations were already using AI widely across their teams, with 91% expecting its use to grow even further. Even if we look back at Microsoft's 

 report, it painted a similar picture, showing that 75% of knowledge workers were already using AI, 78% were bringing their own AI tools, and 52% were reluctant to admit using AI on their most important tasks. Now in 2026, the emphasis has shifted from whether employees are using AI to how integral it has become, with the latest 

 finding that 66% of users claim AI allows them to spend more time on higher-value work, 58% report producing work they couldn't have produced a year earlier, and 65% fear they'll fall behind if they don't use AI.

This has fundamentally flipped the usual order of things. Historically, standards were developed, frameworks were wrapped around those standards, organisations pursued compliance using these frameworks, and then users adopted whatever policy allowed. This flow ran top down, allowing for controlled rollouts of emerging technologies.

With AI, however, it’s flown the other way: user adoption has been so massive it's forced organisational change on mass, which in turn has driven expedited compliance and standard evolution. Governance used to lead. Now it follows, and unfortunately, it’s following at a distance.

But what are some of the actual risks that come with this shift?

Let’s start with the thing everyone’s excited about at the moment, AI agents.

Traditional software was static. It did exactly what it was built to do, no more and no less, but agents aren’t like that. They make their own decisions, take their own actions, and you simply can’t reason about them the way you reason about a normal application, when considering their risk profile and security implications.

Really, AI agents should be treated like new employees rather than technology. If you hired someone new on Monday, you wouldn’t hand them unrestricted access to all your files, production data, codebases, secrets, and intellectual property, then tell them to make any decision they liked. I mean, there is no way!

What you’d do is limit their access, supervise them, and keep an eye on what they’re actually doing. So, we should do the same for agents by establishing controls like:

On top of this, if we consider coding agents, we need to be even more wary about biases they may have inherited from training. Much like the opinion bias we worry about in general-purpose models, a coding agent is only ever as good as the code it learned from, and that’s basically decades of often flawed human work.

Because of this, coding agents will happily solve a problem by generating code from the 1990s that concatenates raw input into a SQL query, uses MD5 hashing for passwords, and leaves secrets hardcoded in the source code, just as reliably as it would write something in a modern and safe manner. When left unsupervised, you don’t get a clean codebase; you get one absolutely riddled with holes, if it works at all.

Then there’s the runtime risk, which is where things get genuinely uncomfortable. An agent simply reading upstream issue comments can be coerced into merging a malicious pull request, simply because it can’t reliably tell the difference between the data it was given and the instructions it should follow. This is a fundamental flaw in existing AI technology and is the reason prompt injection exists.

The scenario isn’t far-fetched either. For example, 1Password tested eight models across 30 scenarios and found that every one committed a critical failure in every run. Even when they could spot a phishing page with near-perfect accuracy on request, as autonomous agents they still entered real credentials into attacker-controlled pages.

Ultimately, when considering AI agents, autonomy without controls isn’t a capability or a productivity boost. It’s a significant exposure.

When discussing AI risks, it seems people love talking about poisoned training data, rogue agents, and new attacker capabilities, and the simple risk of data exposure seems to take a back seat in people's minds, despite being omnipresent. It is by far the most abundant threat organisations actually face day to day, as their employees are pouring massive amounts of sensitive data into thousands of AI tools.

It is also often contrasted with using search engines, and how we don’t police that or stress about that so much. However, the difference is that, unlike search engines, these AI technologies are designed to be most useful when fed the most context, actively encourage mass data sharing.

Also, on top of this, employees tend to assume that if they’ve been allowed access to use a tool, they’re also allowed to put anything they want into it.

 found that around 55% of content submitted to public AI tools is sensitive, demonstrating that there is indeed a continuous, voluntary, high-bandwidth stream of corporate information flowing into systems that organisations neither own nor audit.

What makes this so hard to control is that these risks often look completely ordinary:

None of those prompts would likely trigger a traditional data loss prevention tool, because DLP was built around pattern-matching on consistent structured content like credit card numbers and classification labels, not on the broad context wrapped around a perfectly normal-sounding request.

This is why visibility matters more than almost anything else when faced with the data exposure challenge of AI. Even whilst talking to organisations, the same line comes up again and again:

“We think we know what AI is being used, but we don’t know what’s going into it.”

And well, you can’t govern what you can’t see, and you definitely can’t judge or understand the risk correctly without the full picture in front of you.

This brings us nicely on to “shadow AI”. A term I’m sure we’ve all heard plenty by now.

Ultimately, the objective here is to answer one simple question: What tools are our employees actually using? Are they using the tools you’ve approved, or a whole suite of others you’ve never heard of?

Perhaps you have robust controls for (and visibility) over ChatGPT, because you’ve inventoried and approved it. But this tells you nothing about whether Bob in finance is feeding sensitive documentation into a random AI PDF generator he found last Tuesday, or if Alice in HR is submitting CVs to unapproved AI recruitment software

 has made this gap between perception and reality clear, with 72% of security leaders believing they have full visibility into AI usage, 65% simultaneously claim they still uncover unauthorised or shadow AI, 91% expect that usage to grow, and over half claim that data leakage and compliance violations are their concerns. 

It’s clear that even in highly regulated industries, shadow AI persists because actual behaviour simply does not align cleanly with their policy.

One of the most frustrating aspects of this is that a lot of it is simply reinventing the wheel. People are running for AI tools to do things we solved years ago! Generating PDFs, spellchecking, and information gathering. Word does this. Google does this. But, well, it’s got “AI” in the name, so it must be better! And so, we end up with a long list of obscure tools people are using that nobody has vetted or approved or has oversight into.

The instinct, of course, is to block access. And we saw this a lot in the early days of AI. However, in practice, blocking makes the problem worse as banning the tool doesn’t stop the activity; it simply moves it over to personal accounts and unmanaged devices. And here we have absolutely no visibility at all, which is the worst outcome of the lot.

The way to combat isn’t simple prohibition, but to build an inventory of what’s genuinely in use, understand why people reached for those tools in the first place, and then offer a better way to reach the same outcome with something you actually monitor and have some control over.

So, having discussed some of the risks we’re trying to get on top of, where does governance go from here, as the speed of AI evolution and adoption has outpaced it so much that by the time there is a plan in place its often no longer fit for purpose?

I think it will likely change shape, shifting from restriction towards deliberate enablement.

As we’ve seen with simple blocking, restriction is a poor tool for governing human behaviour. Enabling the right behaviour has a far higher chance of success than trying to clamp down on the wrong one, because people don't like to think they are being restricted. One of the jobs of a security team is to become a secure enabler rather than a simple barrier, and the distinction really does matter in practice. It means:

If we get this foundation right, then visibility controls become possible. And once you can actually see what’s happening, you can implement real-time enforcement where the risks live: catching and preventing a data leak as it occurs, securing how one model talks to another, and intervening at the moment of action, rather than discovering the problem in an audit months later when it's too late.

That’s governance designed for systems that move with AI speeds, rather than governance that simply hopes the world will slow down for the paperwork to catch up.

AI itself isn’t really the risk we face, per se. AI is a fact now. It’s omnipresent. The true risk is the gap between how fast users adopt these capabilities and how fast organisations can govern that adoption. If we can close that gap, the technology is an enormous asset, but if we leave it open, it’s a business-ending disaster waiting to happen.

I was asked recently to comment on the idea of making a frontier model like 

 completely jailbreak-proof. The honest answer was that with AI technology as it stands today, that’s essentially impossible, and the simple fact is, we’re all building on foundations that are inherently flawed, leaving a very real gap underneath everything we put on top. But that gap is exactly where the work needs to happen. With the right visibility, guardrails, and governance wrapped around how AI is actually being used, you can take a flawed foundation and still build something an organisation can actually trust.

The real challenge is to secure our environments in a way that still preserves the freedom and innovation that made this technology worth adopting in the first place. That’s genuinely hard, and probably one of the most interesting challenges in AI security right now.

You can't govern what you can't see. If you don't know which AI tools your teams are using, what data they're feeding into them, or where the risky prompts are happening, you're managing AI security on guesswork.

 gives you the real picture: shadow AI usage, sensitive data exposure, and where your current stack has blind spots. 

No agents, no proxies, no weeks of deployment.

The Risk Isn't AI

Recommended for you

Pixels, Polygons, and Payloads:Malware delivery in 3D software pipelines

6 Strategic Implications of AI for Security Leaders in 2026

The AI Hunger Games: The Rapid Adoption of DeepSeek: A Security Nightmare