Back to Blog Some days I feel like I’m standing on the deck of the Titanic on that foggy night. Music in the background. Dancing. Laughter. People enjoying the drinks on a luxury trip.
What sticks with me about that night isn’t the sinking. It’s the iceberg, and how much of the danger sits below the waterline. The lookouts did see something in the dark. What they couldn’t see was the other ninety percent, and that the part below the surface was the part that did the real damage.
Shadow AI has the same shape. What we can see of AI inside our organizations, the models, the subscriptions, the sanctioned tools, is the tip of the iceberg. Underneath sits everything those models can actually reach and everything they have already done with it. That’s the mass, and that’s where the damage happens.
AI isn’t just arranging our words anymore, it’s shaping our actions. Which means the risk is a lot bigger than the models you don’t know about.
There are three layers here, and most organizations have only worked the first one:
- Shadow AI : models running in places you didn’t approve
- Shadow Agents : those models holding capabilities you never inventoried
- Shadow Execution : what those capabilities actually do, in sequence, at runtime
The gap between layer one and layer three is where shadow AI presents the most profound risk.
Layer one: Shadow AI #
Back at RSA in March, I asked a friend and CISO what she took away from the week. She laughed and said, “I learned a new word I’m apparently supposed to know. Shadow AI.”
I’ve seen this movie. Shadow IT became shadow cloud became shadow SaaS became shadow AI. If I’m honest, the term annoys me a little, because it takes something very layered and flattens it into a seemingly simple sounding topic.
That doesn’t make it wrong. Find the models running across your environment. Find out whether people are bringing personal subscriptions in and putting work information into unsanctioned models. There are real data protection and privacy implications, and getting employees onto sanctioned models is a genuine part of the problem. Paul, Certiv’s CTO, wrote about exactly this:
Paul’s post on unsanctioned model use → Finding the models in use matters, and it’s work worth doing as many companies can’t detect if new models are showing up across their endpoints.
But it’s the part above the waterline. Underneath Shadow AI sits a much larger mass.
Layer two: Shadow Agents #
At Black Hat I got the same question a few times: how do you define an agent?
An AI agent is a model calling tools in a loop. That’s it. The thing that makes it different from the automation we’ve been securing for twenty years is that it’s intelligent and non-deterministic. It decides.
And to be useful, an agent collects capabilities. That’s the moment AI stops answering and starts acting on your behalf. Capability is what an agent can reach, access, invoke, create, or change.
A company may well know it has an agent, and know which MCP servers and connectors it approved. But the capability you declared and the capability the agent actually has are two different things. And the capability doesn’t grow linearly. If you add 3 tools of different varieties the combination of those tools adds an exponential capability. Effective capability grows through credentials, APIs, code execution, local tools, generated scripts, indirect tool chains, and integrations that got configured after the inventory was taken.
Stated plainly: the agents running across your organization have more capability than you can see. Don’t like the approved MCP? Ask Claude to build a connector to the API and wire up the integration. Now Claude gets around the traditional instrumented controls.
What we see in the wild through our own discovery work is consistent. People have more models running, in more places, connected to far more capability, than they realize. And the place where agents and capabilities multiply fastest is the endpoint. Users are running frontier models, local models, and open-weight models, connecting them to powerful tools, and then automating.
On average, across every environment we monitor, including our own, less than 25% of the tool calls and actions an agent takes are MCP calls. The rest are file operations, shell commands, direct API calls, local tools, and scripts the agent wrote for itself moments earlier.
Sit with that for a second. The connector inventory, the thing most organizations are building their AI governance program around right now, is describing just a portion of what agents are actually doing. More than three out of four actions happen somewhere nobody is looking.
In one customer conversation, I was told a story about a contractor who came in on an IT project. Without their knowledge he brought a local Qwen model on his laptop. To get his project done efficiently, he connected it to every other workstation in the company, and the contents of all of them were collected in an instant.
He wasn’t doing anything he thought was wrong. He was doing his job well. But shadow AI had just become a shadow agent with cross-cutting access to their systems. Nobody approved it. Nobody scoped it. Nobody saw it happen until well after the event.
The new model was just the tip of the iceberg. There was now a shadow agent with broad capabilities and data.
Not all shadow agents carry the same risk. An agent on a frontier model has a different profile than one on an open-weight model, which has a different profile again from one running an abliterated model with its refusals stripped out. The context and the connections can look identical from the outside. The behavior and the safeguards are not.
Two things follow.
The first is that organizations need to know the moment a tool turns agentic. A model that answers questions is one thing. Connect tools to it and it can act, and most security teams can’t tell you when that line got crossed, on which machine, or by whom.
The second is that once it’s crossed, much of what follows is invisible to an MCP governance layer or a gateway. Those govern the connections you declared. They don’t see an agent writing and running its own script, reading and rewriting files on local disk, or chaining a path nobody thought to watch for. A large share of agent activity never leaves the machine or the context it’s running in. If your visibility depends on traffic crossing a boundary, that activity simply isn’t there to see.
And none of this is only a shadow problem. Your sanctioned agents are running the same paths, on the same machines, with the same lack of visibility. The difference between a sanctioned agent and a shadow one is paperwork, not observability.
Layer three: Shadow Execution #
You can solve your shadow AI problem, then solve your shadow agent problem, and still have no idea what your agents are actually doing.
Shadow execution is the string of actions and outcomes you didn’t predict and didn’t see happen.
Early on I debated a security leader who held that governing capability at the integration surface was enough. Watch the connectors, control the connectors, done.
Then he spent real time using agents himself. I remember the sigh, and him looking at the ceiling: “I think you’re right. We’re going to have to watch everything an agent does.”
That’s the shift. The integration surface is real, and it’s worth governing. It’s just the portion of the problem you can already see. Because as an agent becomes useful it accumulates capability, and then it combines and executes that capability in ways nobody specified in advance. The risk isn’t in a static, centralized tool list. It’s in what gets created, chained, and executed.
The OpenAI and Hugging Face incident in July woke a lot of the industry up to this. Agents in an evaluation environment broke out of their sandbox, reached the internet, coordinated with each other through a channel they built themselves, and ran a multi-stage intrusion against production infrastructure. No human directed it.
That one happened inside a frontier lab. Most organizations don’t have that environment. But you don’t need agents that sophisticated for the pattern to hurt you. The shape is what matters, and the shape turns up on ordinary machines with ordinary tools:
- An agent asked to clean up test data enumerates its connections, finds one it holds credentials for, and drops a production table.
- An agent blocked from an API writes itself a script, schedules it, and now has a standing path into that system that nobody inventoried.
- An agent debugging a failure reads through logs, finds a credential sitting in one, and uses it to reach a system nobody scoped it for.
None of those require a novel exploit or a malicious user. They require a capable model, a few ordinary tools, and nobody watching the sequence. And notice that no individual step in any of them is something you’d write a policy against. The damage lives in the combination.
And that’s the part that matters. You can’t reconstruct these after the fact from a tool inventory, because the inventory was accurate the whole time. You have to be watching the executions while they happen, inspecting what the agent is doing as it does it. Otherwise the first time you learn what your agents are capable of together is when something has already gone wrong.
Below the waterline #
Here’s the part of that night I keep coming back to. The Titanic did have lookouts, and they did spot the iceberg. The order was given and the ship turned but it didn’t matter. By the time anyone could see the thing, there was roughly half a minute left, and the damage was done below the waterline where nobody was looking at all.
Seeing something too late is not seeing it. That is the whole difference between an inventory you run each quarter and watching executions as they happen. You can only avoid what you can see, and only if you see it in time.
With Shadow AI, detecting and finding models being run is where this work starts, not where it ends.
Finding models tells you where AI is present. It doesn’t tell you what that AI can reach. Inventorying agents and connectors tells you what you approved. It doesn’t tell you what the agent assembled once it got to work. Only watching executions tells you what actually happened.
That full picture, models, agents, tool calls, and the sequences they run, is your AI action surface. Most organizations are only looking at the tip of it.
Every workstation in your company is now an orchestration point for AI execution, and it needs to be watched at scale. You don’t need the policy framework first. Visibility is what teaches you which controls you’ll actually need, so start watching, start learning, and let what you see write the policy.
These are dangerous waters we are in. You can only avoid what you can see, and much of the risk of Shadow AI is lurking beneath the surface at the agent and execution layers.
Certiv built a platform to do exactly this. One install, and you see the whole iceberg: models, agents, tools, and the execution chains they run. If you are trying to get ahead of shadow AI in your organization, book a demo and we will show you what discovery and runtime assurance look like on real endpoints.