Citizen-Developer Secret Sprawl: 1.27 Million Exposed Credentials and the Prototype Ladder

If you run security or compliance at a regulated mid-market organization, a behavioral health provider, a healthcare nonprofit, a property management firm, a PE portfolio company, a regulated SaaS vendor, your audit program rests on one assumption: that code touching regulated data was written by someone who knew it would be reviewed. That assumption is now wrong often enough to matter. The fastest-growing source of credential exposure in your environment is not your engineering team. It is the operations lead, the analyst, the program coordinator who used an AI assistant to vibe-code a "quick internal tool," wired a live credential into it, and shipped it somewhere your controls never look. A citizen-built tool holding a credential to a system with regulated data is, by definition, an ungoverned exposure, and right now most of them are invisible to you. What changed: 1,275,105 exposed AI secrets, up 81 percent GitGuardian's scan of public GitHub repositories found 1,275,105 AI-related secrets leaked in 2025, API keys, model-provider tokens, and the credentials those tools carry to reach the rest of your stack. That is up 81 percent year over year. And it is only the visible tip: these are the secrets that reached public repos. For every one that surfaces there, more sit in private repos, shared drives, chat threads, and the local folders of people who would never call what they built "an application." The driver is the same shift your board has heard about, seen from a new angle. AI coding assistants made it trivial for a non-engineer to produce a working script in an afternoon. Frontier labs are shipping on a roughly six-week cadence, Claude Opus 4.8 landed on 2026-05-28, about 41 days after 4.7, and each release lowers the skill floor again. The person building the tool is not malicious and, by their own lights, not careless. They simply do not know that pasting a token into a config file, or letting an assistant generate one inline, is a reportable event. And because the tool "just works," it never crosses an engineer's desk, never enters source control you scan, and never gets a credential rotation. Why your old control model misses it Your existing secrets controls assume a pipeline: code flows through a repository you own, a CI system you instrument, and a review gate staffed by people trained to spot a hardcoded key. Citizen-developed tools route around all three. They are born outside the pipeline and frequently die outside it too, abandoned, but still holding a valid credential. This is where the regulated-data dimension turns a nuisance into a finding. A leaked marketing-analytics key is an embarrassment. A leaked credential to a system holding PHI, behavioral health records, tenant financial data, or anything in scope for your regulator is a different conversation. The tool does not have to be sophisticated to be dangerous; it only has to hold one credential that reaches one regulated system. Standing tokens make it worse, because the same long-lived secret keeps working long after the tool and its author are forgotten. The control model that catches your engineers' mistakes was never built to see the analyst's spreadsheet-replacement script, and that is precisely the population growing fastest. What the audit and the board will ask Examiners and boards have caught up to this faster than most security teams expect, because the frameworks now name it. The US Treasury's Financial Services AI RMF, published 2026-02-19, lays out 230 control objectives across seven domains, several landing squarely on credential governance and access scope for AI-enabled tooling. The EU AI Act's GPAI obligations begin enforcement on 2026-08-02, with fines up to 3 percent of global turnover. NIST's preliminary Cyber AI Profile (IR 8596, 2025-12-16) gives auditors a vocabulary for exactly this gap. And OWASP's 2026-06-11 update, mapping prompt injection to 6 of its 10 agentic-AI Top 10 categories, underlines that these tools are not just credential holders, they are attack surface. So the questions are predictable. Show me the inventory of internally built tools that touch regulated systems. Show me which credentials they hold and when those credentials were last rotated. Show me the control that stops a non-engineer's tool from reaching regulated data without review. "We have a policy" will not survive contact with any of the three. The honest answer for most mid-market orgs today is that the inventory does not exist, and the absence of an inventory is itself the finding. The artifact: a prototype promotion-and-demotion ladder The fix is not to ban citizen development; that drives it underground. The fix is to give it a defined path with a hard gate, and to make the gate cheap to pass. Build a three-rung ladder. Rung one, prototype. Anyone can build here. The rule is simple and absolute: a prototype gets no credential to any system holding regulated data, period. It uses synthetic data, a sandbox, or a read-only test endpoint. Most tools live and die at this rung and never need to go further. Rung two, reviewed. To leave prototype, the tool passes automated secret scanning and a short human review. No hardcoded secrets. Every credential is short-lived and scannable, the kind of token that can be detected in transit and auto-revoked if it leaks. Cloudflare's scannable API tokens, shipped 2026-04-14 with auto-revocation and resource-scoped RBAC, are the model: a token that announces itself when exposed and dies on detection beats a static key that lives forever. Scope every credential to the minimum resource and the minimum verb. Rung three, production with regulated data, the hard gate. Nothing reaches a system holding regulated data without clearing this rung: named owner, scoped and rotating credentials, secret scanning in the path, logging, and a demotion trigger. Demotion matters as much as promotion. If a tool's owner leaves, if it goes unused for a defined window, or if a scan fails, it drops a rung and its production credentials are revoked automatically. The ladder runs in both directions, which is what keeps abandoned tools from becoming standing exposures. Feed the ladder with a one-line intake form. Not a committee, not a ticket queue, one line: "I built a tool that touches [system]." That single sentence converts an invisible exposure into a tracked asset and gives you the inventory the auditor will ask for. Where regulated data genuinely cannot leave your perimeter, open-weight options like Gemma 4 (released 2026-05-01) plus steadily cheaper accelerators make in-perimeter inference increasingly viable, run the payback math for your own environment rather than trusting a vendor's number. What we recommend First, run the discovery you have been avoiding: ask every non-engineering team, in plain language, what tools they have built and what those tools connect to. The one-line intake form is your standing version of this; the first pass is a one-time sweep. Second, implement the hard gate before promotion, not after incident. The rule that no prototype gets a regulated-data credential is the single highest-leverage control here, and it costs nothing to declare today. Third, move every credential a citizen tool holds to short-lived, scannable, resource-scoped tokens, and put secret scanning in the path so a leak is detected and revoked rather than discovered in a breach report. Fourth, write the demotion triggers down, owner departure, disuse window, failed scan, and automate revocation. A ladder you cannot climb down is just a slower way to accumulate risk. If you want this scoped to your regulators and your stack, Securem's fixed-scope Diagnostic maps your citizen-developer surface and the gates that close it; the companion field guide, "The AI Governance One-Page Policy a Mid-Market Org Can Defend" (/blog/ai-governance-one-page-policy-mid-market-can-defend), gives you the policy language to sit on top of it. Stop trusting that the dangerous code came from someone who knew it would be reviewed, and build the rung that catches the code from everyone who didn't.