From Sanskriti Khandelwal | Product & Market Analysis
Internal Tools Built Overnight: The Approval Path That Does Not Kill the Benefit
On this page
Veracode's July 2026 testing put the average security pass rate for model-generated code at 56%. That leaves 44% of generation tasks introducing a known flaw. Non-engineers now ship internal tools built exactly that way, in an afternoon, with no review and no record. The code quality is the smaller problem. The larger one is that nobody knows the application exists, who owns it, or whose credentials it runs as.
Key takeaways
- The security debt is measured, and it is not improving. Veracode's 2026 report puts the average security pass rate at 56%, against 55% the year before, while the volume of model-written code entering pipelines rose sharply.
- Speed and defect count scale together. Apiiro's analysis inside Fortune 50 enterprises found AI-assisted developers committing 3 to 4 times more code and producing 10 times more security findings, with privilege escalation paths up 322%.
- Live apps are already leaking. A single-day scan of 5,600 publicly reachable applications built on prompt-to-app platforms found more than 2,000 vulnerabilities, 400 exposed secrets and 175 instances of personal data.
- Tier by blast radius, not by who built it. A tool touching sample data needs no gate at all. A tool writing to a system of record needs a service identity and a named owner, whether a developer or a finance analyst built it.
What "built overnight" actually means in 2026
The impulse is old. Someone in operations gets tired of a manual process and builds a workaround. For 30 years that workaround was a spreadsheet, then an Access database, then an Airtable base with a form on the front.
Two things changed, and only one of them gets discussed. The obvious change is speed. A prompt-to-app platform turns a paragraph of description into a working application in minutes rather than weeks.
The change that matters more is what the artefact is. A spreadsheet sits on a drive. A prompt-built internal tool is a deployed web application with a public URL, a login page, a database behind it and API keys inside it. It has an attack surface. A spreadsheet does not.
This is why the old shadow IT playbook fits badly. That playbook was written for unapproved software purchases, and its remedy was procurement control. You cannot procurement-control something an employee built themselves in 40 minutes on a corporate card that was already approved.
Three different artefacts wear the same label
Most policy failures here start with treating all of these as one category.
| What was built | Typical build time | What it touches | The gate it actually needs |
|---|---|---|---|
| A prototype used by the person who built it | An afternoon | Pasted or sample data | None. Leave it alone. |
| A team tool with a handful of internal users | 1 to 3 days | Read access to a live system | A record of it and a named owner |
| A tool another department now depends on | 1 to 2 weeks, then years | Write access, customer or employee data | Review, service identity, an on-call owner |
Build times are illustrative and reflect what these platforms advertise, not measured data. The risk column and the gate column are the editorial argument of this post.
Gartner's survey work has been pointing at the underlying trend for years. It found that 41% of employees qualify as business technologists, meaning they create technology or analytics capability while reporting outside IT. That figure predates the current generation of tools by three years, which is the point. The demand was always there. The supply constraint moved.
What the code these tools produce actually contains
Two claims circulate and only one survives contact with the evidence. The first is that model-generated code is now fine. The second is that it is uniformly dangerous. Neither holds.
Security pass rates have not moved in two years
Veracode's 2026 GenAI Code Security Report put the average security pass rate at 56%, against 55% in the previous edition. The strongest model tested reached 68%. More than half the models scored between 50% and 53%.
The distribution by flaw type is the useful part, and it is wildly uneven. Cryptographic algorithm choices passed 87% of the time and SQL injection checks passed 83%. Cross-site scripting passed 15% of the time. Log injection passed 12%.
Read that as a map rather than a verdict. Models have learned the flaw classes that appear constantly in training data with obvious fixes. They have not learned the classes that depend on knowing where the output goes.
Speed and findings scale together
Apiiro analysed code across tens of thousands of repositories inside Fortune 50 enterprises. Developers using assistants committed 3 to 4 times more code than peers who did not. They also produced 10 times more security findings.
The composition of those findings is worse than the count. Syntax errors fell 76% and logic bugs fell 60%. Privilege escalation paths rose 322% and architectural design flaws rose 153%.
That is the inversion nobody planned for. The defects that got rarer are the ones a test suite catches. The defects that got commoner are the ones only a person who understands the system catches, and that person is not in the room when a non-engineer ships a tool. The same squeeze is showing up inside engineering teams, where review capacity has become the binding constraint on AI-assisted delivery.
What a scan of live applications found
Escape took a one-day snapshot on 29 October 2025 across 14,600 internet-reachable assets built on Lovable, Base44, Create.xyz, Bolt.new and Vibe Studio. Within that set, 5,600 were web applications.
The scan surfaced more than 2,000 vulnerabilities, more than 400 exposed secrets and 175 instances of personal data including medical records, IBANs and phone numbers. Domains identifiable as educational or health-related were excluded before scanning, so the real figure is higher than the published one.
These are public applications, which is a genuine limitation and I return to it below.
The governance failure is not in the code
Security teams keep reaching for scanners, and scanners are the wrong first instrument here. The recurring failures in this category are configuration and identity failures, not memory-safety failures.
OWASP catalogued them before the current tool generation arrived. Its citizen development and low-code risk lists are short, readable in 20 minutes, and describe almost every incident I have seen written up since.
Whose credentials is the application running as?
OWASP calls the top risk account impersonation. The builder connects the application to a data source using their own login. Every end user then reaches that data with the builder's identity attached.
Three consequences follow immediately. Users inherit permissions they were never granted. The audit log cannot distinguish legitimate use from abuse. And the application breaks the day the builder leaves, or silently keeps running with a departed employee's access.
The fix is boring and it is the single highest-value control in this whole post. Applications run under a service identity with an explicit, minimal permission set, never under a person. The same principle is doing heavy work in the wider debate about how non-human accounts get provisioned and revoked, and it applies unchanged to a tool a marketing manager built on a Thursday.
The second OWASP risk, authorization misuse, is the same mistake in a different costume. Builders choose broad sharing scopes because narrow ones make the tool fail during testing. The permission inheritance problem this creates is the one that turned enterprise search deployments into unplanned data exposure, and internal tools reproduce it at smaller scale and greater volume.
Month four, when the builder changes team
Ownership decay is the failure mode nobody puts in the risk register, and it is the one that actually bites.
The tool works. It gets used. The builder moves to another team or another company. No handover happens because no record ever existed that the application was a corporate asset. Twelve months later something breaks, and the only person who understood it is gone.
This is not a hypothetical inconvenience. It is how an organisation accumulates applications holding live customer data that no team will claim. The rationalisation problem this produces is the same one behind the average enterprise carrying hundreds of overlapping applications, except these ones are not in any procurement system to find.
Platform vulnerabilities compound it. Wiz Research disclosed an authentication bypass in Base44 on 9 July 2025. Two unauthenticated endpoints let an attacker register a verified account on any private application using only the app_id, a value published in the application's own URL and manifest. Single sign-on restrictions did not help. Wix patched it within 24 hours and found no evidence of abuse.
The applications Wiz found in scope are the detail worth keeping: internal chatbots, knowledge bases, and tools handling HR data and personal information. If your organisation had one of those running, the question is whether anyone in security could have named it that morning.
Why the ban does not work, and what IT leaders get wrong about it
The reflex response is a prohibition. No prompt-built applications without IT approval. I have watched this policy issued three times and I do not believe it has ever held.
It fails for a structural reason. The tools cost 20 dollars a month on a personal card, run entirely in a browser, and require no installation for anyone to reach the result. There is no chokepoint to enforce at. A prohibition without an enforcement point converts visible activity into invisible activity, which is a strictly worse position than the one you started from.
It also fails on merit, and this is the part security teams resist. Someone who understands a process end to end can now build the thing that fixes it, without a two-quarter queue in front of a development team. Refusing that is refusing the productivity, not the risk.
The Cloud Security Alliance reached a similar conclusion in its April 2026 research note on AI-generated vulnerabilities. Its estimate is that confirmed CVEs attributed to AI coding tools, 35 in March 2026 alone, understate the true count by a factor of 5 to 10. The recommendation is not prohibition. It is mandatory review proportional to what the code touches.
My position is that the ban is not a governance strategy, it is a liability transfer. It moves the blame from the organisation to the employee without changing the probability of an incident.
Tier by blast radius, not by who built it
The workable middle path rests on one substitution. Stop asking who built the application. Start asking what it can reach.
That substitution does most of the work, because it is objective and the builder can answer it honestly in under a minute. Author identity is a proxy for risk and a poor one. A staff engineer's weekend script with production write access is more dangerous than a finance analyst's dashboard over sample data.
| Tier | Test that places an app here | Required before it runs | Cost to the builder |
|---|---|---|---|
| 0. Sandbox | No production data, no users outside the builder, no write access anywhere | Nothing at all. Build it. | Zero |
| 1. Registered | Reads production data, or has internal users beyond the builder | A register entry, a named owner, an expiry date, a service identity | About 5 minutes |
| 2. Reviewed | Writes to a system of record, holds personal data, or is reachable from outside the network | Security review, scoped credentials, documented access list, named on-call owner | 1 to 5 working days |
This tiering is an editorial proposal, not a published standard. The tier tests draw on the OWASP low-code and citizen development risk lists. The time costs are targets to design against, not measured averages.
Tier 0 has to be genuinely free, and this is where most implementations break. If registering a sandbox prototype costs a form, people stop registering and the whole scheme collapses into the ban you were trying to avoid. Make the cheapest path the compliant one and the policy enforces itself.
Tier 2 is where the real cost sits, and it should be rare. If more than about one in ten tools lands in tier 2, either your tier tests are too broad or your organisation has a data access problem that predates any of this. The promotion decision from tier 1 to tier 2 is the same judgement engineering teams already make when moving a proof of concept into production.
The registration gate is four questions, and the wording matters
Tier 1 needs a register. A register that takes 5 minutes gets filled in and a register that takes 30 minutes gets avoided, so the question design carries the whole scheme.
Free-text fields are the common mistake. They feel thorough and they produce a database nobody can query. Every question below should resolve to a list selection, because the point of the register is to answer "which of our tools touch payroll" in one query at 2am.
| Question | The weak version | The version that works |
|---|---|---|
| What does it do? | A free-text description box | One sentence, plus the source system chosen from a list |
| Who owns it? | The builder's name, captured once | A named owner and their manager, both notified at every renewal |
| What data does it touch? | A checkbox marked "internal data" | Named systems from a list, and a yes or no on personal data |
| What happens if it stops? | Not asked at all | One of three options: nothing, work slows, work stops |
The fourth question is the one most registers omit. It is also the only one that tells you what to restore first during an incident, and it costs the builder 4 seconds.
Add one more field that is not a question: the connectors and packages the tool pulls in. Roughly 20% of model-generated code samples reference packages that do not exist, which is exploitable by anyone who registers the hallucinated name. The same exposure runs through the connector layer these tools install without asking, and a list of what is installed is the only cheap defence.
Expiry does the enforcement you will never staff
Every registered tool gets an expiry date at creation. Six months for tier 1, twelve for tier 2. On expiry, the owner and their manager get one message with one button. Renew, or the tool is archived.
The behavioural design is the point. Enforcement models require someone to go looking for violations, and nobody has that headcount, so enforcement quietly stops in month three. Expiry inverts the default. Doing nothing removes the application rather than preserving it.
Three things fall out of this for free. Abandoned tools disappear without anyone deciding to kill them. Ownership gets re-confirmed by a human twice a year, which is the only reliable defence against ownership decay. And the manager who signs the renewal now knows what their team is running, which is usually news to them.
Archive rather than delete, and keep the archive for a year. The failure case you are protecting against is a quarterly process that runs on a tool nobody used in the intervening five months. Archive makes that recoverable in an hour. Deletion makes it a rebuild.
Renewal is also where you catch tier drift. A tool that entered as tier 1 in January has usually acquired write access by June. Ask the four questions again at renewal rather than assuming the original answers still hold. This is the same logic behind staged governance maturity models for autonomous systems, applied to a much smaller object.
Where this argument is weakest
The evidence base is about public applications
The Escape scan covers internet-reachable apps. That population is self-selecting: it skews toward hobbyists, launch-directory submissions and people who did not know their app was public. An enterprise tool behind SSO on a private network is a different risk profile and the scan says nothing directly about it.
What transfers is the failure class, not the rate. Exposed secrets, over-scoped credentials and missing row-level security are configuration defaults, and a private network does not change a default. Treat the Escape numbers as a demonstration of what goes wrong, not as a prediction of how often it will go wrong inside your perimeter.
Tiering can be gamed by the person filling in the form
Self-declared tiers depend on honest answers. A builder who wants to skip a five-day review has an obvious incentive to describe write access as read access. No form design fixes that.
Two partial answers exist and neither is complete. Sample the register against platform audit logs quarterly, which catches systematic under-declaration but not one-off cases. And make tier 2 fast enough that gaming it is not worth the effort, which is a resourcing decision dressed as a policy one. If your security review takes six weeks, your register will be full of tier 1 entries that are not tier 1, and the failure will be yours rather than the builders'.
Frequently asked questions
What is shadow IT in the age of AI app builders?
Shadow IT traditionally meant software bought without IT approval. Prompt-to-app platforms changed the object. Employees now create deployed web applications with their own databases, login pages and API credentials, without any purchase to intercept. The governance problem shifted from controlling procurement to maintaining a record of applications that already exist, along with who owns each one and what data it can reach.
How risky is AI-generated code compared with human code?
Veracode's July 2026 testing found an average security pass rate of 56%, meaning 44% of generation tasks introduced a known flaw. Performance varies sharply by flaw class: cryptographic choices passed 87% of the time, cross-site scripting only 15%. Apiiro separately found AI-assisted developers producing 10 times more security findings than unassisted peers, with privilege escalation paths up 322%.
Should we ban employees from building internal tools with AI?
A ban is unenforceable and counterproductive. These platforms cost about 20 dollars a month, run in a browser and need no installation, so there is no chokepoint to enforce at. A prohibition converts visible building into hidden building, which is worse. Tier the applications by what data they can reach, make the low-risk path completely free, and reserve review for tools that write to systems of record.
What is the biggest security risk in low-code and no-code apps?
Account impersonation, which OWASP lists first among low-code risks. The builder connects the application using their own credentials, so every user reaches the data with the builder's permissions attached. Users inherit access they were never granted, audit logs cannot separate legitimate use from abuse, and the tool keeps running under a departed employee's identity. Service identities with minimal scoped permissions are the fix.
How do you govern citizen development without slowing it down?
Put the friction where the risk is. Applications touching only sample data get no gate at all. Applications reading live data get a five-minute register entry with a named owner and an expiry date. Only applications writing to systems of record or holding personal data get a security review. Tier on what the tool can reach, never on who built it.
Who should own an internal tool built by a non-engineer?
The builder's manager, not the builder. Individuals change teams and leave, and ownership attached to a person disappears with them. Recording both the owner and their manager, then re-confirming both at every renewal, keeps the accountability inside a function rather than inside an inbox. Expiry dates force that re-confirmation to happen without anyone running an audit.
Where to start this week
Start with discovery, because you cannot tier what you have not found. Pull the expense reports for the last six months and search for the four or five prompt-to-app platform names. Every charge is one application and one person who can tell you what it does. That list took an hour and is more accurate than any survey you could send.
Then run the four questions against whatever that search turns up, and resist the temptation to review any of it yet. The first pass is a census, not an audit. Publish the count to your leadership team without naming anyone, because the number itself is the argument for funding the register.
Related on governance
The identity half of this problem is covered in more depth in the piece on non-human access, and the review-capacity half in the analysis of where AI-assisted delivery actually jams.
References
- Veracode, 2026 GenAI Code Security Report, 28 July 2026. Used for the 56% average security pass rate and all pass rates by flaw class.
- The Register, AI code assistants improve production of security problems, 5 September 2025. Used for the Apiiro findings on commit rate, security findings and privilege escalation.
- Escape, Methodology: how we discovered over 2k vulnerabilities in apps built with vibe coding platforms, October 2025. Used for the scan population, vulnerability, secret and personal data counts.
- Wiz Research, Critical vulnerability in AI vibe coding platform Base44, disclosed 29 July 2025. Used for the authentication bypass mechanism, timeline and affected application types.
- OWASP, LCNC-SEC-01: Account Impersonation. Used for the account impersonation and authorization misuse definitions and mitigations.
- Cloud Security Alliance AI Safety Initiative, Vibe coding's security debt: the AI-generated CVE surge, 4 April 2026. Used for the March 2026 CVE count, the under-count estimate and the hallucinated package figure.
- Gartner, Rise in business technologists is driving funding for tech purchases outside of IT, 13 March 2022. Used for the 41% business technologist figure.
The weakest thing about this source base: three of the seven sources are published by security vendors with a product in this market, including the two largest datasets. Their methodologies are stated and checkable, which is why they are cited, but the incentive to find a problem is real. The Gartner figure is four years old and predates the current tool generation. The three-tier path itself is an editorial proposal, not a standard, and no measured outcome data supports it.
Related reading