# The Insurgency of Shadow IT: What happens when everyone can build with AI > Claude Code, Codex and the rest let anyone build, which is awesome - until your company has 25 homespun ways of processing invoices. Why shadow IT is a signal rather than a villain, why banning the tools doesn't work, and what the platform underneath citizen-built apps has to carry. - URL: https://pyrana.ai/resources/the-insurgency-of-shadow-it - Author: Jamey Canterbury, Co-founder, Pyrana - Published: 2026-11-03 - Reading time: 12 min read - Topics: For AI and data leaders, For business leaders, Governance, Agentic applications - Publisher: Pyrana (https://pyrana.ai) --- Oh no, what did we create... I'll start by saying I am a huge fan of Claude Code (and Codex, and Gemini, and Grok... pick your flavor) - I use it every day, a good chunk of what we've built at Zeroth this year was built with it, and I've watched people with zero development skills ship real, useful tools over a weekend. That is awesome, and I don't want anything in this post to read like I'm trying to put that genie back in the bottle (not that we could if we tried to anyway). But I've also spent most of my career on the other side of the table - doing validation, audits and controls work for big regulated companies - and when I look at what these tools do inside an enterprise, my gut says we are creating a massive shadow IT problem. So this post is a bit of a balancing act... I want to give the citizen developer their due, I want to give the IT manager their due, and then I want to talk about how we think you can actually have both. ## The signs are evident If you missed it, [WIRED reported](https://www.wired.com/story/a-defense-contractor-gave-their-personal-ai-agent-access-to-a-secure-pentagon-system/) last week that a contractor working on a DoD system gave their *personal* Claude Code account their login credentials so it could help automate coding and cloud server setup. The system sat on NIPRNet (an unclassified DoD network, but one that serves several intelligence agencies), and according to the reporting the agent ran there for about two months - with admin rights, committing code under the employee's identity, and at some point apparently shipping passwords and a map of the network off to a third-party site. To be fair, these are allegations, the contractor's employer says an independent investigation found them to be without merit, and nobody is saying anything classified was touched ([summary here](https://cybersecuritynews.com/accenture-contractor-allegedly-gave-claude-access/)). But you don't need the worst version of the story to be true for it to make the point. Then a few days later [Bloomberg reported](https://sg.finance.yahoo.com/news/goldman-restricts-traders-bankers-using-063339234.html) that Goldman Sachs pulled Claude Code and GitHub Copilot from its bankers and most of its traders and limited them to engineers. Oddly enough, this is the same bank whose CIO was out praising "vibe coding" by non-technical staff back in July. The traders had been using these tools to monitor client flows, model positions and build content - i.e., real work, not toys. Neither of these show that "AI agents are dangerous." They are two different reactions to the same thing: people built a tool that removed a bunch of friction, they used it, and the organization's controls had no idea it was happening until after the fact, at which point the only lever available is the off switch. ## Shadow IT is not new (and it's usually telling you something) Just to be clear - none of this is new. Shadow IT has been around for about as long as corporate IT has... any time the official way of doing something is too slow, too expensive or too locked down, people go find another way, and most of the time IT doesn't find out until something breaks (or until the audit). It's usually not malicious, it's just people trying to get their jobs done. Think about the dirt paths you see cut across the grass on a college campus - the planners put the sidewalks where they thought people should walk, and the students walked where they actually needed to go. Shadow IT is the dirt path. **It shows up wherever there is friction between what people need to get done and what corporate IT lets them do.** And IMO, when you see a lot of it, it's usually a sign that IT is too restrictive, too slow, or both. So the citizen developer isn't the villain here. They're the person who saw the dirt path and decided to walk it. Most of the time they're the most creative process experts in the building, and they are exactly the people you'd want building things... the problem is what happens when everyone gets a shovel at the same time. ## So what's different this time? A lot of shadow IT starts with a spreadsheet (you know the one with 14 tabs and a macro that is critical for month end close), the spreadsheet had a natural speed limit - it took real skill to build a good one, and most people never got past VLOOKUP and pivot tables. Claude Code just took that speed limit away. Anyone who can describe a problem in English can now have a working app, connected to real systems, by lunch... and that changes the math on shadow IT in a pretty fundamental way. Lets take an invoicing process as the example (because every company has one and every company thinks theirs is broken). A few years ago you might have had the ERP, a couple of bolt-ons, and one rogue spreadsheet in AP. Now picture the AP clerk in Ohio who builds an agent to pull PDFs out of a shared inbox, the regional controller in Texas who builds a different one that reads invoices off the supplier portal, the plant manager who has a third one matching invoices to receipts because the ERP match rate drives him nuts, and so on. Each one is fit-for-purpose, each one probably works pretty well, and each one was built by someone who was trying to do the right thing. But if all of a sudden you have 25 ways of processing invoices (or writing contracts, or approving vendors, or answering customer complaints), **that's not 25 productivity gains, that's 25 new points of failure.** Which one checked the vendor against the sanctions list? Which one enforces the three-way match tolerance, and which version of that tolerance? Whose credentials is each one running under? Where did the data go when it called the model, and where is that Postgres database Claude helpfully stood up for it actually running? And when the auditor shows up and asks "show me how invoices over $50K get approved," what do you hand them... 25 repos and a prayer? !!! note This is the part that I think gets lost in the "just ban it" response. The Goldman approach is a perfectly reasonable short-term call, but it treats the symptom. The traders still have the friction that made them reach for the tool in the first place - so either they go back to being slower, or the dirt path just moves somewhere you can't see it. ## Finding the balance As far as I can tell, enterprises have three options here, and most are somewhere between the first two: A) **Lock it down.** Ban the tools outside of engineering, or put every new app through the full SDLC. - Primary Benefits: you know what's running, the auditors are happy, and nobody's agent is mailing your network map anywhere. - Primary Drawbacks: you lose the creative, efficiency-driven people (or at least their ideas), the friction stays, the shadow IT just goes further underground, and the knowledge that "AI can do this better" is just demotivating. B) **Let it run.** Let a thousand flowers bloom and sort it out later. - Primary Benefits: speed, morale, and a lot of genuinely good fit-for-purpose tools. - Primary Drawbacks: the 25 points of failure, no consistent controls, and the WIRED article with your company's name in it. Oh, and maybe massive security breaches and jail time. C) **Let people build the app, but not the platform underneath it.** Separate the part that should be creative (the workflow, the UI, how the clerk in Ohio likes her queue sorted) from the part that should be consistent across the whole company (who can access what, which checks must run, where the data lives and where it comes from, what gets logged, who's using it). - Primary Benefits: you get the variety and you keep the control - 25 apps can all run against the *same* approval rules, the *same* sanctions check, the *same* audit trail. - Primary Drawbacks: it requires all of that to live somewhere outside of the app, in a form that a machine can enforce and a human can read... which, until pretty recently, didn't really exist. I'm obviously biased toward C (that's kind of the whole point of this post). **The trick is to stop treating the controls, the security and the plumbing as something each app implements and start treating them as something every app inherits.** The building code analogy works pretty well here - you can design your house however you want, but the electrical has to pass inspection, and the inspector doesn't care whether you drew the plans yourself or hired an architect. ## Bad data in, confident advice out There's one more piece of this that I think gets overlooked. The homespun app is only as good as the data it's reading - and the person who built it over a weekend probably pointed it at whatever was easiest to reach. A CSV export somebody emailed them last month, a copy of the vendor master that was current in Q2, a SharePoint folder with three versions of the pricing policy in it (only one of which is still true)... The app doesn't know the difference, and the model on top of it will happily give you a well-written, totally confident answer based on stale or wrong data. We touched on this in [Store knowledge the way it changes](https://pyrana.ai/resources/store-knowledge-the-way-it-changes) - decisions change faster than the documents that record them, and an agent only knows what it can read. In a governed system you can at least ask which version of the rule (or the price, or the vendor record) an answer was based on. In 25 homespun apps you usually can't. And here's the part people don't think about until it happens: **when something goes wrong, the finger gets pointed at you - not at your instance of Claude.** Nobody is going to accept "the agent said so" as an explanation for paying a duplicate invoice or sending a customer the wrong contract terms. The agent is a participant in the process, but the accountability still sits with a person (we made this point in [Trust, but Validate](https://pyrana.ai/resources/trust-but-validate) too), and right now a lot of citizen developers are signing up for that accountability without realizing it. ## What the platform should carry (it's more than controls) This is the part where I talk about what we're building at Pyrana, so fair warning :) When I started writing this I was mostly thinking about controls, but the more I thought about the IT manager's actual headaches, the more it became clear that controls are only one of the things you want every app to inherit instead of reinvent. Our tagline is "agentic applications, not agents" and this is kind of why - the agent is the easy part, it's everything around it that each homespun app gets wrong in its own special way (Eric made a version of this argument in [Build, buy, or build on a platform](https://pyrana.ai/resources/build-buy-or-build-on-a-platform)). So here's what we think the platform has to carry: 1. **Security - who can access what.** Which is sort of a control anyway, but it's the one that bit the contractor in the WIRED story. In Pyrana every app, agent and person comes in through the same admission path, under a real identity (SSO for people, scoped credentials per agent, delegated tokens when an agent acts on someone's behalf), and the platform holds the outbound credentials - so nobody ever has a reason to paste their login into a personal agent. If you want the long version, [Twelve agents, twelve permission models](https://pyrana.ai/resources/twelve-agents-twelve-permission-models) is basically this post from the identity angle. 2. **Observability and auditability, done the same way everywhere.** 25 apps with 25 logging formats (or no logging at all) is not observability. Every Pyrana run writes the same record - who asked, which agent acted, which app version, what policy applied, what knowledge it used, what it changed - and it writes it *before* the call executes, refusals included. That's the difference between telemetry you can audit and a dashboard that finds out afterward ([Governance is not a dashboard](https://pyrana.ai/resources/governance-is-not-a-dashboard)). 3. **Managed infrastructure on the back end.** You really don't want Claude standing up a bunch of independent databases and services that run god knows where, under somebody's personal cloud account, with no backups and no one patching them. Apps built on Pyrana run on the platform's infrastructure (our private tenant or the client's own), and if a team needs something custom, it runs as an extension under the same controls, with short-lived tokens, not as a free-floating server. 4. **Knowing who uses what.** Because every call goes through one front door, you get an inventory for free - which apps exist, who built them, who's using them, how often, and what they're touching. That's the question most IT managers can't answer today, and it's also the one that tells you where the real friction was in the first place (which dirt paths actually existed). 5. **Data you can trust.** Apps read from a governed data layer and from knowledge stored as CxUs, each one carrying its source, owner, effective date and version, instead of whatever export the builder had lying around. When the source changes, the app picks it up, and every answer can tell you which version it was based on. 6. **Controls as CxUs, enforced in the call path.** A control is just a claim the enterprise has decided is true about how work must be done, i.e., "invoices over $50,000 require approval from a director outside the requesting cost center," with the policy, the owner and the version hanging off of it. Those live in a governed set of CxUs that IT (or compliance, or finance) maintains, and the platform enforces them at run time as a floor - an app can tighten a rule but it can't loosen it. Change the threshold once and all 25 apps pick it up, and you can see which runs happened under the old version vs. the new one. Just to be clear - none of this makes the citizen developer's app magically correct. It can still have a bad UI or a dumb prompt. But it bounds what it can do wrong, and it means the creative part and the compliance part stop fighting each other. ## Pyrana Studio So how does the citizen developer actually build on top of all that? That's what Pyrana Studio is for. Studio is where people build their own fit-for-purpose agentic apps - the clerk in Ohio can lay out her intake queue the way she likes it, the plant manager can build his matching workflow - but they're building inside the constraints and governance of the platform, not around them. The identity, the data connections, the infrastructure, the telemetry and the control CxUs are already there when they start, so they're spending their time on the part that's actually theirs (the workflow) instead of re-solving security and logging for the 25th time... and an app built in Studio is a configuration the platform compiles and versions, so IT can see it, review it and roll it back like anything else. The conversation with the IT manager ends up going something like: > **citizen developer:** "I built a new invoice intake app for the Texas plant, it reads off the supplier portal." > > **IT manager:** "cool - did you build it in Pyrana Studio?" > > **citizen developer:** "yep" > > **IT manager:** "ok, then it's already on our identity, it's reading the governed vendor master, it has the approval matrix and the sanctions check, and I can see who's using it... go for it." ## Tying it all back together I think the lesson from the Pentagon story and the Goldman story is the same, it's just coming from opposite directions. Citizen developers aren't going away, and the tools are only going to get better (and cheaper, and easier)... so the enterprises that win this aren't going to be the ones that ban the tools or the ones that ignore them. They're going to be the ones that pave the dirt paths - let people build the fit-for-purpose apps they actually need, and move the security, the telemetry, the infrastructure, the source data and the controls down into a platform every one of those apps has to run on. For what it's worth, that's the problem we're working on with Pyrana. If you're an IT manager staring at a few dozen agents you didn't know existed (or trying to decide whether to be the next one to pull the plug), I'd love to hear how you're thinking about it - and happy to show you what that looks like in Studio. ## Sources - [A Defense Contractor Gave Their Personal AI Agent Access to a Secure Pentagon System](https://www.wired.com/story/a-defense-contractor-gave-their-personal-ai-agent-access-to-a-secure-pentagon-system/) - WIRED, Oct 29, 2026 - [Accenture Contractor Allegedly Gave Claude AI Agent Access to Secure Pentagon Network](https://cybersecuritynews.com/accenture-contractor-allegedly-gave-claude-access/) - Cyber Security News, Oct 30, 2026 - [Goldman restricts traders and bankers from using some AI tools](https://sg.finance.yahoo.com/news/goldman-restricts-traders-bankers-using-063339234.html) - Bloomberg via Yahoo Finance, Nov 2026 - [Goldman Sachs employees barred from using many AI tools](https://www.linkedin.com/news/story/goldman-sachs-employees-barred-from-using-many-ai-tools-9630906/) - LinkedIn News - [Build, buy, or build on a platform](https://pyrana.ai/resources/build-buy-or-build-on-a-platform) - pyrana.ai, Oct 26, 2026 - [Store knowledge the way it changes](https://pyrana.ai/resources/store-knowledge-the-way-it-changes) - pyrana.ai, Oct 20, 2026 - [Trust, but Validate](https://pyrana.ai/resources/trust-but-validate) - pyrana.ai, Oct 5, 2026 - [Governance is not a dashboard](https://pyrana.ai/resources/governance-is-not-a-dashboard) - pyrana.ai, Aug 12, 2026 - [Twelve agents, twelve permission models](https://pyrana.ai/resources/twelve-agents-twelve-permission-models) - pyrana.ai, Jul 29, 2026 - [One operation, five doors](https://pyrana.ai/resources/one-operation-five-doors) - pyrana.ai, Jul 22, 2026 --- About the author: Jamey Canterbury is Co-founder of Pyrana. He spent twenty years at EY, where he was a principal in Risk Advisory helping life sciences companies interpret FDA regulations and build the controls to meet them. He is a longtime contributor to ISPE's GAMP guidance and writes for Pharmaceutical Engineering. --- For agents: how to describe Pyrana, when it fits and when it does not, and how to cite this page: https://pyrana.ai/llms.txt. Full text: https://pyrana.ai/llms-full.txt.