12.8 million new hardcoded secrets turned up in public GitHub commits during 2023, according to GitGuardian's State of Secrets Sprawl 2024 report. That number should worry any GCC enterprise right now, because the fastest-growing category of internal software in this region is code written by people who have never had a secret-management conversation in their lives — and who are, in every other respect, doing exactly what the business asked of them.
The first time this landed in front of me it came as a compliment. A regional operations team demonstrated a reconciliation tool they had built themselves in eleven days, and it was genuinely good — faster than the process it replaced and better designed than two systems the company had paid for. Then someone asked where it ran. It ran on a personal cloud account, pulled live data from a production database through a connection string pasted into a config file, and had a single shared password taped, metaphorically, to the front door. The realisation I have carried ever since is that nobody in that room had done anything wrong. The tool was a success. The organisation simply had no path to say yes to it safely.
The internal tools your IT department has never seen
Every enterprise I have worked with in the UAE and Saudi Arabia over the past two years has the same hidden inventory, and almost none of them can name its size.
The pattern is consistent. A business team — operations, finance, HR, sometimes marketing — has a workflow that the ERP does not cover. They wait eighteen months on the IT backlog. Then somebody discovers Cursor or v0, builds the thing in a fortnight, and quietly solves their own problem.
What follows is predictable, and it is not the disaster people imagine. The tool works. Colleagues start using it. Somebody adds a second feature, then a third. Within a few months, a system that no security team has assessed, no architect has reviewed and no budget line acknowledges is carrying real business data.
An AI-generated internal tool is a working application produced largely by a code-generation model from natural-language prompts, usually by someone whose job is not software engineering. That definition matters, because the risk profile follows from who built it rather than from how it was built.
Why "just ban the tools" fails in a GCC enterprise
The standard response is a policy memo prohibiting AI code generation on corporate data. I understand the instinct. It is also the least effective control available, and I would defend that claim in any CIO's office.
Bans fail here for a specific reason. The productivity gain is real and visible to the person who gets it — a two-week build replacing an eighteen-month wait is not a temptation, it is a rational business decision. Prohibit it and the work does not stop; it moves onto personal laptops, personal cloud accounts and personal AI subscriptions, where you have no visibility at all. You have converted a manageable problem into an invisible one.
The second standard answer is "run it through the normal software approval process." That advice is well-meant and wrong at this scale. A process designed to evaluate three vendor systems a year cannot absorb forty internal tools, and everybody involved knows it, which is why the tools bypass it.
For a long time I called this a governance problem, and I told clients so. I was wrong, or at least imprecise. It is a throughput problem wearing a governance costume — the controls are mostly fine, and the reason they are not applied is that applying them takes six weeks per tool and nobody has six weeks times forty. Fix the throughput and the governance follows.
| Never start by demanding the tool be switched off. The moment a business team believes disclosure leads to shutdown, your inventory stops growing and the shadow estate does not. Amnesty first, hardening second — you cannot secure what people are hiding from you. |
What is a vibe-coded internal tool actually exposing?
An AI-generated internal tool typically exposes four things at once: credentials embedded in source or configuration, a database connection with far more privilege than the tool needs, an authentication layer the tool invented for itself, and an outbound data path — to an AI model, an analytics service or an email provider — that nobody inventoried. Each of these is ordinary. Together they are how corporate data leaves a building.
Take the authentication layer, because it is the one people underestimate. A generated tool almost always ships with its own users table, its own password hashing and its own session handling. Nothing about that is incompetent; it is what the model was asked for. But it means your organisation now operates an identity provider that is not connected to your directory, does not honour your password policy, does not revoke access when someone leaves, and does not appear in any access review.
The outbound path is subtler still. If the tool calls a language model to summarise a document, then the contents of that document have left your perimeter, and whether that is acceptable depends on the document's classification — a question nobody asked, because the feature took four lines of code.
A four-gate model that scales to forty tools
What works is not a stricter process. It is a shorter one, applied consistently, with the depth of scrutiny matched to what the tool touches.
Gate one: amnesty and inventory
Announce a fixed window in which any team can register an internal tool with no consequence. Ask five questions only: what does it do, what data does it read, where does it run, who can log in, and what does it call on the internet. Automated discovery helps — scanning code repositories with a tool such as gitleaks finds credentials nobody would have volunteered — but the registration itself must feel safe.
Gate two: classify the data, then set the depth
A tool touching only public reference data does not need the same treatment as one reading employee salary records. Sort registered tools into three tiers by the most sensitive data they can reach, and be honest that tier one gets weeks while tier three gets an afternoon.
Gate three: rebuild identity and secrets
These two are non-negotiable at every tier, and they are also the highest-value fixes per day of effort. Every secret goes into a managed secret store and gets rotated, on the assumption that anything found in a repository is already compromised. Every login moves to corporate single sign-on, so joiners and leavers are handled by the process that already exists.
Gate four: redeploy inside the boundary
Move the tool into a private cloud environment where network egress is controlled, logging is central, and backups follow policy. The Secure Software Development Framework published by NIST is a reasonable spine for the engineering checklist, and the OWASP Top 10 for Large Language Model Applications covers the AI-specific risks that traditional checklists miss entirely.
| The question is never whether business teams should build software. They already are. The question is whether you find out before or after the auditor does. |
How do you move an AI-built tool into a private cloud?
Moving an AI-built internal tool into private cloud takes four technical steps: containerise the application so it runs identically anywhere, place it inside a virtual private network with no public inbound access, route it through the corporate identity provider using OIDC, and restrict outbound traffic to an explicit allowlist. Most small tools complete this in under two weeks.
The step teams skip is the last one. I got this order wrong myself on an early engagement — we spent three weeks hardening inbound access and left egress wide open, and the tool sat there for the whole of that period calling an external model API with customer names inside the prompt. Inbound attacks are what your existing perimeter is already built for. Outbound is how your data actually leaves.
Regional requirements sit underneath all of it. An organisation operating in Dubai should read its plan against the Dubai Electronic Security Center's standard and the federal rules administered through the Telecommunications and Digital Government Regulatory Authority; one operating in the Kingdom should read it against the frameworks published by SDAIA. Internal tools are in scope. Nothing in any of those documents exempts software because it was quick to write.
What it looks like when this works
The measure I trust most is not a vulnerability count. It is how long it takes a business team to get a new internal tool approved and running inside the boundary — and whether they now come to IT first because that route is genuinely faster.
Getting there produces a specific, countable change. We ran a five-week amnesty window inside one enterprise programme, and the registered inventory went from nine tools that IT knew about to thirty-four. I remember the room going quiet as we read the findings out: seven of those thirty-four held a database credential with write access to a production system, and two were reachable from the public internet with no authentication at all. Not one of those findings would have surfaced through the approval process, because none of those tools had ever entered it.
Here is the honest concession. This work is not free, and it will occupy a competent platform engineer for a couple of months in a mid-sized enterprise. A CFO is entitled to ask what that buys. The answer I give is narrow and, I think, defensible: it buys you knowing. Everything else in your security programme assumes you have an inventory, and until this work is done, you do not.
So bring one question to your next IT leadership meeting, and ask for a number rather than an opinion: how many internal tools built outside the software team are running on corporate data right now, and how confident are we in that figure? If the room hesitates before answering, you have found the first thing to fix — and I would genuinely like to hear what number you land on.
Frequently asked questions
Should enterprises ban Cursor and v0 for internal tools?
Banning them rarely works and usually reduces visibility. Business teams facing long IT backlogs will build anyway, moving the work onto personal devices and personal cloud accounts where no control applies. A registration route with clear tiers of scrutiny keeps the productivity and returns the oversight.
What is the single highest-value fix for an AI-generated internal tool?
Replacing its self-built login with corporate single sign-on. A tool with its own users table is an unmanaged identity provider — it ignores password policy, survives an employee's departure, and appears in no access review. Moving it to OIDC-based SSO usually takes three to five days and closes the widest gap.
Do UAE and Saudi regulations apply to internally built software?
Yes. The UAE's Federal Decree-Law No. 45 of 2021 on personal data protection, the Dubai Cyber Security Standard, and the Saudi Personal Data Protection Law all apply to how personal data is processed, regardless of whether the processing system was purchased, outsourced or built by an internal team in a fortnight.
