Every few weeks I talk to a security leader who tells me they have shadow AI in progress. They wrote an acceptable use policy. They published a list of approved tools. They blocked the rest at the proxy and ran a training session on not pasting sensitive data into chatbots. And they will tell you, without hesitation, that this is not enough. They know there is more work to do. What most of them do not yet have is a clear picture of what that next layer actually looks like.
That gap is where the real risk lives, and closing it requires a different frame entirely. Shadow AI is not primarily a policy problem. It is an identity problem. The policy is a reasonable place to start. But it is not a place to stop.
We have seen this movie before
A decade ago, we called this shadow IT. Employees were standing up unsanctioned SaaS apps faster than IT could track them, and the first instinct was to ban everything. That instinct failed. The companies that tried to block their way out of shadow IT just pushed it underground, where it got harder to see and more dangerous. The companies that succeeded did the opposite. They accepted that the demand was real, gained visibility into what was being used and what data it touched, and brought that usage under management. Policy was part of that story. Visibility and active management were the part that actually worked.
Shadow AI is the same story playing out again, with one important difference that changes everything about the response. With shadow IT, the thing you ultimately had to get control of was the application. With shadow AI, the thing you have to get control of is the identity.
Here is why that distinction matters. When an employee adopts an AI service on their own, the risk is not that the tool exists. The risk is the access that tool inherits. The employee signs in with their corporate credentials because that is the fastest way through the login screen. An OAuth token gets issued, usually with broad scopes nobody reads. From that moment on, a third-party AI service holds a durable, machine-usable key to corporate data. That key keeps working long after the employee forgets the tool exists, long after they change roles, and entirely outside the view of any policy document.
What sits beyond the policy layer
It is worth being specific about where policy ends and the next layer has to begin, because the gaps are not subtle once you look for them.
Policy cannot see authentication. When a developer signs into an AI coding assistant with their corporate identity, nothing in your acceptable use document records that it happened. The connection is made identity to service, and unless you are watching identity behavior, you have no idea it exists.
Policy cannot see delegation, and delegation is the real mechanism of shadow AI. OAuth is invisible to the policy layer. A user clicks allow, and an AI service now holds delegated authority to act on their behalf across the systems that identity can reach. Your policy was never part of that transaction.
Policy cannot see what the AI does after it connects, and this is where the exposure compounds. An AI agent operating through a corporate identity does not behave like the person who authorized it. It runs continuously, makes decisions at machine speed, and chains access across systems in ways nobody anticipated when they clicked allow. Your policy described what people are supposed to do. The agent is doing something else entirely, and without runtime visibility, you have no record of it.
And when something goes wrong, policy cannot revoke anything. Someone has to find the offending connection first, which requires exactly the visibility the policy assumed you already had. Teams can spend days trying to answer a simple question after an incident: what did this AI service actually have access to, and is it still connected? If the only artifact is a document telling people what they should have done, that question has no answer.
The visibility layer that has to come next
If shadow AI is an identity problem, then the response has to operate where identities live. In practice that means building the visibility layer that sits on top of whatever policy you have already shipped. There are four things that layer has to give you.
The first is discovery. You have to know which corporate identities, human and non-human, are connecting to AI services, sanctioned or not. Every team that runs this exercise honestly comes away surprised. The number of identities touching AI tools is always larger than leadership believed, and a meaningful share of those connections were established through OAuth grants nobody approved. That first inventory is often the moment the scope of the problem becomes concrete.
The second is grant visibility. Every OAuth token issued to an AI service is a standing grant of access, and it deserves the same scrutiny as any other privileged access decision. Which identity authorized it. What scopes it carries. When it was last used. Whether it should exist at all. A token that gives an AI notetaker full access to an executive’s mailbox is not a footnote in a usage report. It is an access decision that should have been reviewed.
The third is runtime behavior. Discovery and grant inventory give you the static picture, but they do not tell you what an AI identity is actually doing once it connects. That is the difference between knowing an agent has access to a system and knowing the agent just pulled forty thousand records from it at three in the morning. Static permissions describe what could happen. Watching behavior at runtime is the only thing that tells you what is happening.
The fourth is the ability to act at the identity layer. When you find a connection that should not exist, or an AI identity behaving in a way it should not, you need to revoke that access directly, at the source. Containment has to happen where the access actually lives.
It is about to get harder
Everything described so far assumes a human is doing the signing up. A person adopts a tool, clicks allow, and grants access. That is the version of shadow AI most organizations are currently managing, and it is already more complex than policy alone can handle. The next version is harder.
We are moving quickly into a world where the thing connecting to AI services is not a person but an agent, acting on a corporate identity, spinning up its own connections and spawning sub-agents that inherit access nobody granted directly. An employee who signs up for a tool at least made a decision you can trace afterward. An agent operating at machine speed makes thousands of those decisions an hour. If you do not have visibility into how your identities connect to AI services now, while humans are still in the loop, you will have no footing once they are not.
The shift worth making now
Shadow AI is not a genuinely new category of risk. It is the same identity risk we have always had, arriving faster and through a new door. People are granting corporate access to third-party services through credentials and tokens, at a scale and speed that policy was never built to track. The AI part is what makes it urgent. The identity part is what makes it solvable.
The organizations that understand this will not stop at policy. They will treat it as the foundation for something more operational. They will build the visibility to see how their identities actually interact with AI services. They will treat every OAuth grant to an AI service as an access decision worth monitoring, and every AI agent as an identity worth attributing and, when it matters, containing.
Shadow IT taught us two things that apply directly here. You cannot govern what you cannot see, and you cannot ban what people have already decided they need. Shadow AI is that same lesson, moving faster and routed through identity. The policy is not the mistake. It is the starting line. The race is in what you build next.
About the Author
Jason Martin is Co-Founder and Co-CEO of Permiso Security, a leader in identity security, providing advanced solutions to help organizations detect and respond to threats targeting human and non-human identities across cloud environments. Prior to establishing Permiso, Jason served as the Executive Vice President of Products and Engineering at FireEye/Mandiant, where he played a pivotal role in shaping the company’s product strategies and engineering initiatives. Beyond his executive roles, Jason is an active contributor to the cybersecurity community. He organized Shakacon, a prominent cybersecurity conference, and has authored various works in the field. Additionally, he is an investor and has provided advisory services to companies like NightDragon.
Jason can be reached via email, or on LinkedIn, X, and at the Permiso website: https://permiso.io
