Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Shadow IT used to mean an employee paying for a SaaS subscription that IT had never approved. The newer form is an employee building the tool: a spreadsheet connected to a database through an API, a low-code internal app, a script generated with an AI coding assistant, or an agent that acts on company email and files. The shift is real and visible in vendor and survey data, but it is a trend rather than a settled condition inside every organization. The numbers come mostly from software vendors and from surveys of specific populations, so they show direction more than prevalence.
What shadow IT means when the tool is built in-house
Shadow IT describes technology used for work without the knowledge or review of the people responsible for security, data, and support. A built tool becomes shadow IT on the same terms as a purchased one. It is a problem when it runs outside IT review, has no clear owner, uses accounts or credentials nobody manages centrally, handles data nobody has classified, or depends on maintenance that stops when the person who wrote it changes role. The fact that the tool solves a real business problem does not change that picture.
As an Amazon Associate I earn from qualifying purchases.
Three kinds of built tools account for most of the change:
- AI-assisted builds, where a non-developer describes a workflow and an assistant produces working code, often deployed quickly to a shared environment.
- Low-code and app-generation platforms, where forms, dashboards, and workflows are assembled visually on top of existing data sources.
- Agents and API-connected automations, which read, write, or send on a person’s behalf across systems such as email, calendars, repositories, and business databases.
The common thread is that the person defining the workflow is also the person building the software. That removes the procurement step that used to give IT a natural checkpoint.
#1 Best Overall
What the figures show, and who produced them
Four sources carry most of the weight in current discussion. They measure different things, use different samples, and are not interchangeable. Two of them are vendors with commercial interests in this market: Retool sells an app-building platform, and Torii sells SaaS discovery and governance tooling. Their numbers are useful evidence of behavior and scale, but they are not neutral censuses.
| Source and date | Population | Figure reported | What it does not show |
|---|---|---|---|
| Retool, 2026 Build vs. Buy Report (survey fielded late 2025) | 817 Retool customers and builders across roles and company sizes | 35% of surveyed teams had replaced at least one SaaS tool with a custom build; 78% expected to build more custom internal tools in 2026; 60% said they had built software outside IT oversight in the past year, and 25% said they did so frequently | Not a sample of all enterprises. Respondents are Retool’s own customers and builders, a population already using a build platform. |
| Cloud Security Alliance, The State of SaaS Security: 2025–2026 (survey fielded January 2025) | 420 IT and security professionals | 63% of organizations reported external data oversharing; 56% said employees upload sensitive data to unauthorized SaaS apps; 55% reported employees adopting SaaS without security’s involvement | Focuses on SaaS, not employee-built software. These are survey responses, not incident rates. |
| Torii, SaaS Benchmark Annual Report 2026 | Vendor benchmark of application inventories | An average of 831 applications per organization, with 61.3% of applications classified as shadow IT under the report’s classification rule | The sample frame was not stated in the public excerpt reviewed, so it should not be read as a representative global census. |
| OneTrust and Sapio Research, The OneTrust 2026 AI-Ready Governance Survey Report (fielded June–July 2026) | 1,200 senior decision-makers at organizations with at least $100 million in revenue, in Australia, Canada, France, Germany, Singapore, Spain, the UK, and the US | 48% reported clear visibility into both sanctioned and unsanctioned AI use; 46% said visibility was good for approved AI but limited for employee-led or unsanctioned use | Measures self-reported visibility, not the volume of unsanctioned AI activity. |
Read together, these figures support three claims. Employees are building software outside formal review at meaningful rates in the Retool population. Organizations in general report weak visibility into SaaS and AI use. And the number of applications in a typical inventory is large enough that discovery is itself a hard problem. None of them, on its own, establishes that built tools are replacing SaaS across the economy.
Why people build around IT
The UK National Cyber Security Centre’s shadow IT guidance is direct on motive. It states: “Most shadow IT is typically not the result of intentional rule-breaking, rather the result of staff trying to ‘get their job done’ where corporately-provided equipment and services are not adequate.” That framing matters for the response. Workarounds usually trace back to a gap: a capability the approved product lacks, a request process that takes weeks, or a set of approved services that does not fit the job.
Built tools are attractive for the same reasons. A team that needs a intake form, an approval queue, or a reporting view tied to one internal process can often produce it faster than it can get a procurement decision. Retool’s CEO and founder, David Hsu, put the vendor case this way in the 2026 report release: “SaaS products force you to work their way. Now that vibe coding’s gone mainstream, businesses that can custom-build their value drivers will have a competitive edge.” That is a promotional statement from a platform vendor, not independent evidence, but it describes the pull that makes building attractive to the people doing the work.
Rank #3
Where built tools create new exposure
Data leaving sanctioned systems
A built tool often needs data from several places at once. Copying a customer list into an unreviewed app, pasting contract text into an assistant, or syncing a CRM table to a personal automation moves data across a boundary that no one drew on purpose. The CSA survey figures above describe the same pattern at the SaaS level, and the risk is larger when the tool is custom, because there is no vendor security page, certification list, or standard data-processing agreement to check against.
AI assistants and agents with account access
The Cloud Security Alliance’s AI Safety Initiative paper, “Shadow AI Infrastructure: The Invisible Enterprise Attack Surface,” describes employees deploying agents, private model endpoints, low-code workflows, and AI connected to corporate data without procurement or security review. An agent granted OAuth access to email, calendars, document repositories, or internal databases can act autonomously, retain state between sessions, and, if compromised, serve as a pivot point into other systems. The paper frames these as plausible system risks. It does not show that every employee-built agent is compromised, and most built tools carry none of this access.
Familiar infrastructure risks
The NCSC guidance lists the older problems that shadow IT has always carried: inadequate security controls, uncertainty about where data is processed or stored, backup gaps, legal and reputational exposure, malware and ransomware, and lateral movement. Built tools inherit all of these, and they often add one more: the person who built the tool may be the only one who knows how it works.
Build or buy: the questions that decide it
“Build versus buy” is a decision to be made tool by tool, not a slogan. The questions below draw on the NCSC guidance and on the replacement categories in Retool’s survey. They are a working checklist, not a validated scoring model.
Best Value
| Question | What to check before deciding |
|---|---|
| Fit | Does the workflow need something the sanctioned product cannot reasonably do, or is the gap only in configuration or training? |
| Delivery | Can the custom tool be built and reviewed quickly enough to matter to the team that needs it? |
| Data and access | Which sensitive data sets and system permissions will the tool touch, and at what privilege level? |
| Integration and identity | Will accounts, credentials, API keys, and access removal be managed centrally, or stored inside the tool? |
| Ownership | Who is accountable for support, security fixes, backups, and offboarding when the builder changes role? |
| Lifecycle cost | What do updates, monitoring, and maintenance cost over time, not just the initial build or the license? |
| Exit path | Can the data be exported and the tool replaced if the builder leaves or the need changes? |
A tool that scores well on fit and delivery but fails on ownership and exit is usually a candidate for a supported platform, with the workflow kept intact. A tool that works and has a named owner, central identity, and a documented exit can reasonably stay in-house.
A governance response that does not rely on bans
The NCSC guidance and the CSA work point toward the same sequence. Prohibition alone pushes building out of view, which makes discovery harder.
- Discover what exists. Inventory SaaS, AI tools, scripts, and automations, including those connected through single sign-on, API tokens, and OAuth grants. Review OAuth consent grants and API token inventories, not just expense reports.
- Ask what need each tool meets. Interview the people who built or use it. Record the workflow, the data involved, and what the approved alternative lacks.
- Offer a fast, controlled route. Set a review path with a defined turnaround for new tools, and approve sanctioned platforms that cover the most common needs.
- Assign an owner. Every tool in use should have an accountable person who handles support, access reviews, and retirement.
- Apply least privilege and central identity. Use managed accounts and scoped OAuth permissions. Remove standing access that the workflow does not need, and revoke it when the owner leaves.
- Bring useful work under control. When an unsanctioned tool proves valuable, migrate it to a supported system with its data and logic intact rather than shutting it down abruptly.
- Make reporting safe. Staff who disclose a workaround should not be punished for it, or the inventory will stay incomplete.
What the evidence cannot tell you
- None of the surveys reports how many built tools in a given organization operate without review, or how many have caused an incident. The figures describe behavior and perception, not losses.
- The CSA survey predates the 2026 surge in AI-assisted building that the Retool and OneTrust material describes, so its figures should be read as a baseline for SaaS governance rather than a measure of built-tool risk.
- The OneTrust figures measure how confident leaders feel about their visibility. They do not count the AI tools in use.
- Vendor inventory averages depend on how each vendor defines an application and what counts as shadow, so they are not directly comparable with one another.
The defensible conclusion is narrower than the headline. Built software is a growing share of how work gets done outside IT’s view, and governance that only watches SaaS contracts will miss it.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
