Are there effectives tools for AI governance and Shadow AI visibility in the workplace?

I ran into the exact same issues, our first measure was to work with HR and reinforce to everyone on the company that any scripts, tools, automations and the like are 100% their responsibility. I cannot share the exact wording but this were the main points You run it. You respond for it's impact and the results of the execution. Claude did it is not an excuse, the "AI said so" is not a valid response and we also had to be really clear that copy pasting and sending share links of chats with AI is not an accepted response in any way. TBF the HR notification was also weaponized a bit by some managers to be able to let go of some characters that where caught multiple times doing the dance of copy pasting AI responses on emails, chats and otherwise only generating slop documentation or worse kicking work down the line by just creating eternal discussions that end in a bot vs bot slop fest. We also got approved ways of interacting with AI, we have contracts for data privacy and we are working on some POCs with LiteLLM, agent_gateway and some other tools to have a local fast AI do the anonymization of information before it hits cloud providers, the idea is to have something that would sit in the middle of the conversation and replace what we would consider PII with placeholders on its way out and back to the original on its way in (fancy regexes with a conversion table really). Other than that we are doubling down on DLP and firewall rules with monitoring of known AI provider domains, IPs and doing deep traffic analisys to catch known llm api signatures. Our hope is that by first stating clear rules and then making the approved use as friction-less as possible we will remove the "convenience" reason for non compliance and then catch the ones that are really trying to circumvent the rules. I'm really looking forward to other responses in this thread as I think there is still much that can be done tech side

We've had something similar happen. The original person moved teams, and we ended up inheriting a handful of AI-generated scripts with almost no documentation. The security risk wasn't even the biggest issue. Maintaining them became the real headache.

That's exactly what we're trying to avoid, AI usage isn't going away, so having some level of governance around what gets built and shared seems a lot more practical than trying to lock everything down.

We have demoed Push Security in our environment, it will show all the applications users have signed into with their browser: https://pushsecurity.com/ Through this, you could tell who is logging into what AI services, either with their company or personal accounts, add a site banner warning them to not enter sensitive data, block uploading/downloading/clipboard actions, etc. I don't believe you can tell exactly what data is being sent, think that may require something a bit more heavy duty like ZScaler.

You are right that purpose-built shadow AI governance tools are still emerging. Most of what exists today falls into one of two categories: browser-level or network-level monitoring that tells you which AI URLs are being accessed, and data loss prevention tools that flag when sensitive content leaves the network. Neither gives you the full picture you are describing. The gap is on the asset side. Shadow AI tools are software assets. They get adopted the same way shadow IT always has...someone finds a tool that solves a problem faster than the approved process does and starts using it. The difference is that AI tools can actively pull data, generate code, and make decisions, which raises the stakes significantly compared to a rogue SaaS subscription. What has worked in practice for organisations further along on this is treating AI tool discovery as part of the ITAM programme rather than a separate security initiative. The questions you want to answer... which tools are being used, by whom, and what data are they touching...are the same questions a mature asset management programme answers for any software in the environment. The challenge is that most ITAM tools were not built to discover browser-based or API-connected AI tools the way they discover installed software. For the code and automation side specifically, the most practical control is a lightweight review gate, any AI-generated script or macro that touches production systems requires a 30-minute peer review before deployment. Not a full security audit, just a second set of eyes. That alone catches most of the year-end rush issues you described without blocking the productivity gains. The governance framing matters too. Blocking does not work and you already know that. Visibility plus accountability tends to change behaviour more effectively than restriction...people self-moderate when they know usage is visible, even without active enforcement.

I'm trying to understand whether there are many mature tools available that help organizations gain visibility into "Shadow AI" usage across teams specifically which AI tools are being used, who is using them, and ideally what type of data is being sent to those platforms. Any modern "next generation" firewall allows creating policies to block web apps and will have categories for AI and other shadow IT sites. You aren't going to be able to see the actual data unless you do TLS interception. This is a bit different from traditional shadow IT, mainly because outright blocking these tools is not a viable option for us. Well, enjoy getting breached when Chad in sales has his LLM agent install malware. LLMs are no different to traditional software in that you don't just let users run any random application they found on the Internet. Second, internal teams increasingly building quick scripts, macros, or lightweight automation tools using AI-generated code. In our experience, this often happens during busy periods (especially year-end), where tools get built without proper review, and we later run into maintenance and security issues. This has nothing to do with AI or sysadmin. This is a failure of culture and not adhering to any coherent SDLC.

One thing I'm curious about is how companies are handling AI-generated scripts and internal tools. We don't mind people using AI to build quick solutions, but six months later nobody knows who wrote them or how they work.

Firewall and proxy filtering

On your second concern, the risk is not really the code quality, it is that those scripts run as whoever wrote them. A macro or a Power Automate flow thrown together during year-end inherits that person's full permissions and keeps firing long after they change teams. Cheap first pass that needs no new tooling: enumerate scheduled tasks, Power Automate and Apps Script flows, and anything holding a stored credential, then sort the list by what the identity can reach rather than by what the script claims to do. Anything touching production data moves to a named service account with scoped permissions and a listed owner, everything else stays on the author's own account where the blast radius is their own access. That single split gets you most of the governance without blocking anyone, and it works the same whether the code came from an LLM or from Stack Overflow.

The gap is real, CASB catches sanctioned SaaS but misses browser AI and the AI baked into apps you already approved. The maturing tools watch at the browser layer or endpoint for what's being pasted rather than at the network. Cheap first step: pull your IdP OAuth grants to see which AI apps people already have connected. Mostly managed devices or a lot of BYOD?