It is 11pm on a Saturday. A developer is two hours into a weekend project a small AI assistant that reads their calendar and drafts meeting summaries. The scaffolding is done. They need an MCP server to wire the LLM to their Google Calendar. They pull up the quickstart docs, copy the configuration example, replace the placeholder API key with the real one sitting in their .env file, and push to GitHub. The project works. They go to bed. Three days later, an anomalous API bill arrives. Someone has been running completions against their OpenAI key since Sunday morning. By then, the charges are four figures.
This is not a horror story. It is a Tuesday. The credential was live for 72 hours before anyone noticed. It required no social engineering, no phishing, no sophisticated intrusion a scanner found it in minutes. The developer was competent and building something genuinely useful. They just moved fast, which is what you do with weekend projects, and the tooling made it trivially easy to commit a configuration file containing a real secret. Speed culture is not going away. The velocity gains from AI-assisted development are real and documented. But speed has always had a price, and right now that price is being paid in credentials millions of them, every year, at an accelerating rate.
The term was coined by Andrej Karpathy in a post on X in February 2025. His description was precise: “There’s a new kind of coding I call ‘vibe coding’ … fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Karpathy contextualized the approach as suited to “throwaway weekend projects,” not production systems a nuance that got lost as the term spread and the tools matured. The workflow itself is straightforward: describe what you want in natural language, accept the generated code, and iterate through conversation rather than manual writing. Prompts replace syntax. The developer’s attention shifts from implementation details to intent and direction, with the AI handling the boilerplate, the scaffolding, the API integration code, and increasingly the architecture itself. The productivity gains are genuine and measurable: 84% of developers now use or plan to use AI tools in their development process, up from 76% the prior year, and among those using AI agents, 70% report reduced time on tasks while 69% report increased productivity. These are not marginal improvements.
The problem is not the tooling. It is the culture the tooling produces when applied without discipline. There is a meaningful distinction between experienced developers who use AI as a force multiplier reviewing every suggestion, treating output as a draft and developers who treat AI-generated code as production-ready by default. The latter group is growing. Karpathy himself noted that vibe coding “empowers trained professionals to write a lot more (vibe coded) software” while also enabling people who previously could not code at all to ship working applications. That democratization is valuable. It also creates a large cohort of builders whose mental model of credential security was formed by copying a quickstart doc, not by a decade of production incidents. A 2024 GitHub survey found that nearly all enterprise developers 97% report using generative AI coding tools. The ship-fast-review-later culture inherits every old security risk inside new packaging. It just does so at higher velocity and at a scale that earlier security frameworks were not designed to absorb.
The data that describes this problem is neither hypothetical nor static. In 2025, 28.65 million new hardcoded secrets were exposed in public GitHub commits a 34% year-over-year increase and the largest single-year jump in GitGuardian’s five-year reporting history. Public GitHub commits themselves grew 43% year-over-year in the same period, and the developer base grew 33%. Secrets, in other words, are growing 1.6 times faster than the population of developers creating them. GitHub’s own independent security report, using different methodology, counted 39 million secrets leaked across the platform in 2024. Two major independent sources, different counting approaches, same direction: sharply up, every year. This is a structural trend, not a measurement artifact.
Buried inside the GitGuardian dataset is a data point that deserves more attention than it has received. Commits co-authored by Claude Code measurable because the tool can co-sign commits with identifiable metadata leaked secrets at a 3.2% rate in 2025, compared to a 1.5% baseline across all public GitHub commits. This is not evidence that Claude Code is uniquely careless or badly designed. It is evidence of a workflow pattern. When Claude Code signs the commit, the developer has likely let the AI generate the code, run a quick functional test, and merged without credential review. The tool producing the code is also the tool accelerating the rate at which credential-bearing artifacts reach the repository. Speed in, secrets out. The composition of leaked secrets has shifted alongside these volume increases: AI-service credential leaks grew 81% year-over-year in 2025, reaching 1,275,105 detected exposures. Twelve of the top 15 fastest-growing leaked secret types were AI services. Among the more striking individual figures: 113,000 DeepSeek API keys appeared in public repositories in 2025 alone, from a service that barely registered as a developer tool the prior year, and OpenRouter credential leaks grew more than 46 times year-over-year.
The credential exposure problem does not exist in isolation. Veracode’s 2025 GenAI Code Security Report, which tested over 100 large language models, found that AI-generated code introduces known security vulnerabilities in 45% of cases. A December 2025 CodeRabbit study compared 320 AI-authored pull requests against 150 human-only pull requests and found the AI-authored ones generated 2.74 times more security issues. CVEs formally attributed to AI-generated code jumped from 6 in January 2026 to 35 in March 2026 and Georgia Tech researchers estimate the true count is 5 to 10 times higher than the formal tally, because most AI tools leave no identifiable commit metadata. These are two parallel failure modes: credentials appearing in code at accelerating rates, and code shipped as production-ready before it is security-ready. Both are downstream of the same cultural pattern, and both are worsening simultaneously.
What makes the current moment qualitatively different from earlier credential-leakage eras is the structure of what developers are building. A leaked AWS key in 2018 was a serious incident. It typically meant an attacker had access to one account’s cloud infrastructure which could be devastating, but the scope was bounded and the remediation path was reasonably clear. A leaked AI stack configuration in 2026 is categorically worse, not because the platforms involved are less secure, but because one developer now routinely holds credentials for five to eight interconnected services simultaneously.
Consider the typical stack for a developer building an AI application today. A complete working setup commonly includes an LLM provider API key for model inference, an embedding service credential for generating vector representations, a vector database token for storing and querying those embeddings, orchestration layer configuration potentially containing multiple service tokens, an MCP server configuration with multiple service credentials embedded in a single file, experiment tracking credentials with access to model training runs and data pipelines, and voice or agent infrastructure tokens for customer-facing deployments. Each represents a service that can be accessed directly and autonomously once the credential is compromised. A developer who commits a single configuration file may not realize they have simultaneously exposed access to their production database, their customer-facing voice agent, their model fine-tuning pipeline, and their billing account. The blast radius is not one system. It is the entire autonomous surface area.
The category-level growth rates make the scale of this credential surface concrete. Vector database platforms the storage layer for embedding-based retrieval systems saw credential leak rates jump nearly 1,000% year-over-year in 2025. Agent-building platforms that help teams construct agentic systems without writing orchestration from scratch showed leak growth of 500 to 600%. Voice infrastructure platforms for AI agents grew nearly 800% year-over-year. Supabase, a widely-used database platform that has become a common default for AI projects requiring fast on-ramps to vector workflows, saw its credential leak rate grow 992% year-over-year. That figure reflects the adoption curve turning directly into a leakage curve the more teams reach for a convenient, well-documented database service, the more likely a developer new to the platform is to follow the documentation exactly and leak the key in the process.
The security community has converged on a useful framing for this problem: non-human identities, or NHIs. These are the service tokens, machine credentials, and LLM platform keys that let AI systems act autonomously on your behalf. Unlike human credentials, they typically carry broad permissions, have no natural expiration, and are created at a rate that outpaces any manual governance process. When a human credential leaks, an attacker can impersonate that person. When an NHI leaks, an attacker can operate as your AI agent making model inference calls, querying your vector database, triggering your voice agent, and accessing whatever your orchestration layer touches. The blast radius extends well beyond billing. Long-lived secrets account for 60% of policy violations in GitGuardian’s dataset, and more than 64% of valid secrets from 2022 are still active and exploitable as of January 2026. The leak problem and the remediation problem are both accelerating, and organizations that cannot answer basic inventory questions who created this credential, what can it access, when does it expire are in a structurally weak position when those credentials surface publicly.
Model Context Protocol is a standard for connecting large language models to external tools and data sources. It emerged in early 2025, primarily through Anthropic’s specification work, and spread rapidly across the developer ecosystem. The appeal is clear: a single standardized interface for giving an LLM access to your file system, your APIs, your databases, your calendar. The security implications were less immediately apparent. In the first year of the protocol’s existence, 24,008 unique secrets were exposed in MCP-related configuration files on public GitHub. Of those, 2,117 remain valid roughly 8.8% of all MCP-related findings. The most common types break down as Google API keys at 19%, PostgreSQL database connection strings at 14%, Firecrawl at 11.9%, and Perplexity at 11.2%.
The root cause is not developer carelessness in the ordinary sense. Official MCP quickstart documentation presented API keys hardcoded directly in configuration examples. Developers copy examples, replace placeholders with real keys, and commit the config exactly as instructed. When documentation teaches insecure patterns, insecure patterns scale at documentation speed. MCP is not uniquely flawed; this dynamic plays out with every new integration standard, from cloud SDKs to database connectors. It is typical. It is also newly consequential at a scale that did not exist five years ago, because the credentials now embedded in these configuration files carry access not to a single service but to an entire interconnected stack.
Credentials do not stay in code repositories, and the exposure surface is wider than most teams account for. Sixty-seven percent of developers have accidentally exposed secrets in code at some point in their careers. Beyond repositories, 2.4% of Slack channels contain at least one leaked secret, and 6.1% of Jira tickets expose credentials, typically embedded in bug report logs or stack traces that contain connection strings. The Cursor AI code editor was documented to have a behavior where .env file contents were accessible to the agent’s tool-use layer for tab completion even when listed in .cursorignore a gap between indexing-level ignores and agent tool-level ignores that left credentials intended to be off-limits reachable in practice. The broader point is not about any specific tool. It is that in the current ecosystem, the boundary between what your AI coding assistant can access and what you intend it to access is imprecise and often wider than the developer assumes. Every surface that can receive a credential is a surface that can leak one.
Large language models hallucinate package names. This is documented, repeatable, and non-random models tend to hallucinate plausible-sounding package names that follow the naming conventions of the ecosystem they are generating code for. A 2023 study found that leading AI models of that period including GPT-3.5, GPT-4, and Cohere hallucinated package references roughly 20% of the time in certain contexts. Slopsquatting is the attack that exploits this behavior systematically. Attackers monitor AI coding tool outputs, identify the hallucinated package names that appear consistently across multiple models or queries, and register those names on PyPI, npm, or other package registries with malicious payloads. A developer in vibe coding mode runs npm install without verifying the package exists in any legitimate registry. The package resolves. The malicious code enters the build. The mechanism requires no vulnerability in the developer’s systems only a hallucinated dependency name and a developer who did not check. Trend Micro’s analysis of agentic coding workflows found that even reasoning-enhanced agents can reduce but not eliminate phantom package suggestions, and that MCP-augmented workflows performing live package validation still miss edge cases. The attack surface exists as long as AI tools suggest dependencies without real-time registry verification, which is to say it exists now and will for the foreseeable future.
AI coding tools use rules files to configure behavior: coding standards, architectural conventions, project-specific instructions. In Cursor these live in .cursorrules; in GitHub Copilot, in .github/copilot-instructions.md. Developers share these files through open-source communities, project templates, and internal repositories, where they are typically treated as harmless configuration data rather than executable artifacts. Pillar Security researchers demonstrated in March 2025 that malicious instructions can be embedded in these files using invisible Unicode characters readable by the AI model processing the file, invisible to human code review scanning the same text. When a developer incorporates a poisoned rules file and initiates code generation, the AI silently follows the embedded malicious instructions without any indication in its chat history that it has done so. In the Pillar demonstration, a simple prompt to create an HTML page produced output that included a malicious script tag sourced from an attacker-controlled server. Cursor responded to the disclosure by stating it was users’ responsibility to vet the files they incorporate; GitHub implemented a warning for hidden Unicode text in rules files in May 2025. The persistent, transferable nature of rules files makes this a supply chain attack that survives project forking once a poisoned file is in a repository, it affects every developer who works from that codebase until the file is audited and cleaned. Most developers do not audit their rules files.
There is also a subtler risk embedded in the ordinary act of debugging with AI assistance. When developers paste configuration details, stack traces, or architectural descriptions into AI prompts for help, that information shapes the AI’s output and transits the AI provider’s infrastructure. If the prompt includes real credentials embedded in a connection string or a log output, those credentials have now left the developer’s environment. The secondary risk is quieter still: an AI assistant that receives a prompt containing a real API key may suggest code that embeds that key “for convenience,” because embedding the key produces code that will functionally run. The suggested code looks plausible and correct. A developer moving fast and trusting AI output may not notice the difference between an environment variable reference and a hardcoded string. The credential moves from the prompt to the generated code to the commit, completing a circuit that no one deliberately designed and no one explicitly approved.
The discipline that matches the velocity does not require slowing down. It requires building habits that run in parallel with speed rather than against it. The first and most basic principle is that secrets do not belong in code. They belong in environment variables or in dedicated secrets management services HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or lighter-weight options like Infisical or Doppler for smaller teams. The list of files that must be treated as credential containers is now longer than it used to be. .env is obvious. Less obvious: claude_desktop_config.json, .cursorrules, any MCP server configuration file, any file that an AI quickstart doc told you to edit with your real credentials. The practical rule is simple: if an official documentation example asked you to paste a key into a file, that file belongs in .gitignore before the first commit.
Pre-commit hooks with tools like TruffleHog or git-secrets scan for credential patterns before code reaches the remote repository. GitHub Secret Scanning is enabled by default on new public repositories. These are not substitutes for manual review, but they catch the category of error most common in high-velocity development: the credential that was never intended to be there. The 84% of developers now using AI tools in their process include a significant cohort operating with mismatched trust calibration 46% of developers actively distrust the accuracy of AI output, yet a meaningful proportion ship code without the review infrastructure to backstop that distrust. Security review at the pull request level should treat AI-generated code as it would treat externally sourced library code: with the working assumption that vulnerabilities may be present. That calibration matches the actual rate of vulnerability introduction, which the data places at roughly double the baseline for AI-authored commits.
API keys should carry the minimum permissions required for their specific function. An LLM inference key does not need write access to your vector database. Long-lived secrets account for 60% of policy violations in the dataset, and the damage from a credential leak is often extended not by the initial exposure but by the failure to rotate afterward a dynamic confirmed by the fact that more than 64% of valid secrets from 2022 remain active and exploitable today. For teams using MCP servers, credentials belong in environment variables injected at runtime, not embedded in server configuration files. Any rules file incorporated from an external source a public repository, a project template, a community forum warrants the same scrutiny as any other executable artifact. Audit for invisible Unicode characters. A configuration file that guides your AI coding assistant shapes every line of code that assistant produces. It deserves the same care you would give a third-party dependency, because in practical terms it functions as one.
The vibe coding wave is not going back in the bottle. The velocity gains are real, the tooling is maturing, and the developer experience improvements are meaningful. The Stack Overflow data shows that adoption continues to climb even as trust in accuracy falls a combination that describes not recklessness but a genuine gap between how developers want to work and how the security infrastructure surrounding that work has kept pace. Karpathy’s observation that this approach will terraform software and alter job descriptions is already proving accurate, and the 52% of developers who agree AI has had a positive effect on their productivity are not wrong. The question is not whether to use these tools. It is whether the security practices surrounding them are evolving at the same rate.
By every measurable signal, they are not. The credential exposure data is unambiguous: 28.65 million new secrets in a single year, the largest annual jump on record, AI-assisted commits contributing at double the baseline rate, and the remediation problem deepening alongside the exposure problem. The developers who will build sustainably in this environment are not the ones who move fastest. They are the ones who build security habits that match their development velocity treating .gitignore as a security document, treating AI-generated code as a draft, treating credential governance as an architectural concern rather than an afterthought that someone else will handle later. The front door metaphor is overused in security writing. Here is a more precise one: leaking your AI stack credentials is not like leaving a door open. It is like handing a stranger a master key to every system your AI agents can touch your database, your model pipeline, your customer-facing voice infrastructure, your billing account and then waiting three days to wonder why the bill belongs to someone else.
Source Intelligence Layer: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13
Follow the SPIN IDG WhatsApp Channel for updates across the Smart Pakistan Insights Network covering all of Pakistan’s technology ecosystem.
