Shadow AI starts with visibility, but securing it means understanding what agents actually do.
As we speak with CISOs, CTOs, and AI leaders every week, Shadow AI keeps coming up as a top concern. Shadow AI goes beyond employees using unapproved AI tools. Agents can now execute actions, retain state, and operate across systems without security teams having a clear view of what they’re doing.
One CISO put it simply:
“I know AI agents exist in my environment. What I don’t know is how many there are, where they’re running, what they’re connected to, who’s using them, or why.”
And that’s really the challenge. AI agents are showing up everywhere, from hyperscalers and SaaS platforms to developer machines and third-party systems. As adoption grows, so does permission sprawl, often faster than security teams can gain visibility or control.

Most security tools were designed for a pre-agentic world, where users, applications, endpoints, and networks had relatively clear boundaries. Security tools were created to protect a user, application, endpoint, network from any unauthorized activity, access attempts etc., However, agents operate differently.
Firstly, an agent might initiate activity on the developer's laptop, execute a local skill, access credentials, communicate with an MCP server, interact with a SaaS application and hand off some work to another agent. Thus, one single task could cross multiple security boundaries within seconds.
Secondly, unlike humans, who follow a particular plan in advance, agents do not have any set path. They dynamically choose actions and API calls that they want to perform, depending on the task to be accomplished, context and received data.
To an endpoint or network security tool, much of this can look perfectly normal: an authenticated API call, a connection to an approved service, or access using valid credentials. What those tools may not see is the bigger picture: why the agent is taking those actions, how one action led to the next, and whether the overall behavior still matches the original intent.
That’s where visibility starts to break down. Each sees a piece. No single view tells the security team what the agent is actually doing across the full chain.
The harder problem is what the agent carries with it as it moves across these systems. Agents don’t start fresh with every action. They rely on context and memory: what they’ve learned, what they’ve been asked to do, what tools they can use, and what happened earlier in the workflow.
That context can follow an agent from a developer’s machine to an MCP server, a SaaS application, or another agent. So securing each surface independently only gets you so far. If you can’t see the context driving the agent’s actions, you can’t fully understand or control what the agent is doing.
In many ways, that context and memory becomes part of the organization’s new security boundary.

If agents move across endpoints, cloud, SaaS, MCP servers, and developer environments, security needs to follow their behavior and context across those boundaries.
That is the approach we are taking at Metano.
We combine endpoint presence, gateway visibility, and SDK instrumentation to connect activity across the environments where agents operate. We want to see how those actions connect and what context is driving them.
An agent might start on a developer’s machine, invoke a local skill, call a remote MCP server, access a SaaS application, and interact with another agent. Each step may look legitimate on its own. The security context becomes clearer when you can connect the full chain.
There are boundaries to that visibility. If an agent operates entirely within another vendor’s infrastructure, we can see its presence and activity where Metano has visibility, but we don’t claim enforcement inside infrastructure where we aren’t present.
For us, coverage means following as much of the agent’s execution path as possible, connecting those signals, and being clear about where visibility and enforcement begin and end.
It is not only about identifying what kinds of agents are out there, but about the blast radius of these agents – what they can access, which tools they can invoke, what context they carry, and how one action leads to the next.
This means tracking down an agent through its execution process, rather than looking at each endpoint, API calls, or SaaS interaction individually.
You don’t get visibility into Shadow AI by counting agents. You get it by understanding what they’re doing, in context, while they’re doing it.
How are you thinking about Shadow AI in your environment? Reach out to us at info@metano.ai