The Hidden Risk of AI-Powered Rogue IT
by Brian Pollack
Nobody hands out cordless saws at orientation.
Think about the building you work in. Somebody designed the way people get into it. There is one main entrance where visitors sign in, badge readers on the doors that matter, cameras on the parking lot, a fire marshal who signed off on the exits, and an insurance company that priced the whole arrangement. None of it is convenient. The badge reader is on the opposite side of the building from where you park, and the loading dock door that would save you four minutes every morning stays locked.
Now picture the company setting out a table of power tools in the lobby and telling everyone to help themselves. Give it a month. Somebody cuts a door out to the employee lot. Somebody in shipping frames in a window because that room gets hot. Every one of those changes is a real improvement for the person who made it, and the building’s security is now worth nothing. Nobody has to beat the badge reader when there is a hole in the back wall.
That is rogue IT. Technology that gets built, bought, or wired up outside the people responsible for keeping the company safe. It is not new, but what people can now build without permission is new, and the gap between “it works” and “it is safe” has never been wider.
The tools really are that good
I want to be upfront, because the rest of this is going to sound like fear. These tools are remarkable and I use them every day. Claude, Copilot, Power Apps, Power Automate, n8n, Zapier, and an MCP server somebody published on GitHub last Tuesday. Someone in finance who has never written a line of code can stand up a working approval workflow in an afternoon. That used to be a multi-week project for my team, with a requirements doc and a budget line. The productivity is not imaginary and I am not going to pretend otherwise.
We have reached a point where anyone can build tools. This is true the same way that I can use my beloved Milwaukee tools to frame a deck without any clue about the codes, local ordinances, and structural integrity. YouTube and the power of M18 have given me an unreasonable amount of confidence with woodworking. I would trust myself to build something small for myself, but I’d be the wrong person to hire to add a deck to your mansion.
The risks are not the ones you would guess
Most people assume the danger here is someone doing something reckless on purpose. It almost never is. The dangers come from things the builder had no reason to think about, and they don’t announce themselves.
You hired a vendor and never met them. Every one of these tools is a company you now do business with. Somebody signed up with a work email and clicked through terms nobody read. Your legal team has never seen the agreement, your security team has never asked where the servers are, and nobody has asked the questions we ask every vendor: who can read our data, how long do they keep it, what happens to it if they get acquired or shut down, and who do we call at 2am when something is wrong. A lot of these companies are eighteen months old. Some of them are three people. That may be perfectly fine. The point is that nobody made the decision.
Data leaves in ways that surprise everyone. This is the one I wish more executives could see in action. A person needs a summary, so the customer list goes into a chat window. Somebody wires up a helpful little report and, to make it work, it quietly pulls live rows out of your production database every hour and drops them somewhere easier to reach. An attachment gets handed to a tool so it can be read, and that tool hands it to a second service you have never heard of to do the actual reading. Each step is one person solving one problem in front of them. Nobody sees the whole path, and the data does not come back.
It is somebody else’s code, running inside your building. This is the part that worries me most right now. A plugin, an extension, or one of those MCP servers is not a document. It is a working program, written by a stranger, running with your people’s access, inside your network. Nobody reviewed it and nobody signed for it, and most of them update themselves whenever the author feels like changing something. The closest thing in your building is a contractor you have never met, who has a key, and who occasionally sends coworkers you have also never met. When one of those turns out to be malicious, and this happens regularly now, it does not need to break in. It is already inside.
Every one of these tools works by skipping a step. This is worth reading twice, because it is the whole article in one sentence. The reason the new tool feels so much better than the official process is almost always that it goes around something. An approval that used to need two people now needs none. A report that three roles were allowed to see now emails itself to a list every morning. The tool signs in as the person who built it, so it can see everything they can see, and then it gets shared with the whole department, and now forty people have that person’s reach. Those steps were not bureaucracy. They were the controls, and they were the reason the last audit passed.
Your assistant can be talked into things. Here is the front door in the title. When you give an AI assistant the ability to act, read your files, send mail, update records, it does that work by reading. And what it reads does not have to come from you. It can come from a web page, an email, a PDF, a vendor’s invoice, a comment on a ticket. If an attacker can get words in front of your assistant, they can try to give it instructions, and the assistant has no dependable way to tell your instructions from theirs. Nobody has to steal a password to do this. They just have to send you a document. Most of the people connecting these tools have never heard of this, and there is no reason they would have.
When it goes wrong, nobody can tell you what left. This is the part that turns an incident into a crisis. The systems your IT group runs keep records, so after a bad day they can tell you what was touched and by whom. A tool nobody knew about keeps nothing. You will not be able to tell your board, your customers, or your regulator what was taken, because there is no way to find out. In my experience the breach is rarely the expensive part. Not being able to describe it is.
The compliance part, which almost nobody understands
Every company answers to something. SOC 2, HIPAA, PCI, GDPR, state privacy laws, or a contract with a customer bigger than you. All of it rests on a written description of how your environment works, and every rogue tool quietly makes that description wrong.
Two things follow, and neither one is theoretical. Your cyber insurance was priced against controls you told them you had, so there is a real chance the policy does not cover whatever goes wrong. And responsibility for the answer does not sit with the person who built the tool. It sits with whoever signed the attestation. Uber’s former security chief was criminally convicted over how a breach was handled, and an appeals court upheld it in 2025. He avoided prison, but “avoided prison” is not a phrase any executive wants in their own story. Nobody discovers this during a good quarter. They discover it during the audit, or during the claim.
So what do you do with this
I am not going to tell you to lock the tool table. That fails, and it fails in the worst direction. People have company cards, personal accounts, and a real deadline, and the tools are too useful to give up. Ban them and the building still gets new doors. You just stop being told where they are.
I am also not going to hand you a five-item checklist and imply you can sort this out on a Tuesday afternoon. Every item above is a judgment call about your data, your obligations, and your actual risk, and getting those calls wrong quietly is exactly how companies end up here in the first place.
My bias is on the table. I consult for a living, so weigh this accordingly. What I do not sell is the idea that your people are the problem. They are not. The person who built that Power App solved a real problem that your roadmap was never going to get to, and they deserve better than a policy violation letter.
They just should not have been handed a saw and pointed at a load-bearing wall.
If you work in IT or security, this is the argument you have already tried to make and lost. Send it to the person who needs to read it. If you are that person, and you are not sure what has already been built inside your company or which of it is actually dangerous, connect with me here. You won’t get a sales pitch, I just like talking about this stuff.
For the IT and security folks: what is the wildest thing you have found running in production that nobody told you about?
Originally published on Protovate.AI
Protovate builds practical AI-powered software for complex, real-world environments. Led by Brian Pollack and a global team with more than 30 years of experience, Protovate helps organizations innovate responsibly, improve efficiency, and turn emerging technology into solutions that deliver measurable impact.
Over the decades, the Protovate team has worked with organizations including NASA, Johnson & Johnson, Microsoft, Walmart, Covidien, Singtel, LG, Yahoo, and Lowe’s.
About the Author
Share article
