Safeguard
AI Security

AI Developer Tools: Weighing Productivity Against Security and IP Exposure

NYU found 40% of Copilot-generated code contained exploitable flaws; Samsung banned ChatGPT after three leaks in under 20 days. The productivity math still isn't simple.

Safeguard Research Team
Research
7 min read

In December 2021, a team of NYU researchers led by Hammond Pearce published "Asleep at the Keyboard?" (arXiv:2108.09293), one of the first rigorous audits of AI-generated code security. They had GitHub Copilot complete 89 scenarios spanning MITRE's Top-25 most dangerous software weaknesses, producing 1,689 candidate programs — and roughly 40% contained an exploitable vulnerability. That finding predates most of today's adoption curve: by GitHub Universe 2024, Copilot had gone multi-model, adding Claude 3.5 Sonnet, Gemini 1.5 Pro, GPT-4o, and OpenAI's o1-preview alongside its original Codex backend, and Accenture's internal study found 81.4% of licensed developers installed the IDE extension the same day they received a license, with 96% of those accepting a suggestion within their first session. Adoption did not wait for the security research to catch up. Two years after the NYU study, Samsung's Device Solutions division in Hwaseong, South Korea suffered three separate data leaks through ChatGPT in under 20 days — semiconductor equipment source code, internal test sequences, and a transcribed confidential meeting — pushing Samsung to ban external generative AI tools company-wide by May 2023. This piece weighs the real productivity data against the real exposure data, and looks at what's changed — and what hasn't — heading into mid-2026.

How much faster do developers actually get?

The acceptance-rate data is more modest than the marketing suggests, but the aggregate effect is still real. A peer-reviewed analysis published in Communications of the ACM found developers accept between 21.2% and 23.5% of Copilot's inline suggestions in practice, while GitHub's own telemetry cites an average acceptance rate closer to 30% — the gap reflects differences in how "acceptance" is measured (kept-on-screen versus kept-after-edit). Accenture's enterprise rollout data adds the adoption-speed dimension: 81.4% of developers who received a license installed the extension on day one, and 96% of that group accepted at least one suggestion in their opening session — a far faster ramp than prior generations of developer tooling saw. None of this proves a specific percentage speedup on shipped features; acceptance rate measures suggestion uptake, not verified productivity. But it does establish that adoption is not a pilot-program curiosity — it is the default working mode for a large share of professional developers already.

What did the NYU Copilot study actually find, and does it still apply?

"Asleep at the Keyboard?" tested Copilot against 89 scenarios covering CWEs like SQL injection, path traversal, and improper input validation, generating 1,689 programs total — about 40% contained a vulnerability an attacker could exploit, per the paper's own scoring rubric (Pearce, Ahmad, Tan, Dolan-Gavitt, and Karri, arXiv:2108.09293). The models underlying Copilot have changed substantially since 2021, and later academic replications using newer base models have generally found lower — though still nonzero — vulnerability rates on comparable benchmarks. The mechanism the paper identified hasn't gone away: these models are trained on public code that itself contains vulnerable patterns, and a suggestion engine optimized for "plausible completion" has no built-in signal for "this is a CWE-89 SQL injection." Newer, larger models write more idiomatic code, but idiomatic and secure are not the same property, and reviewer complacency — trusting a fluent-looking suggestion — is arguably a bigger 2026 risk than the raw base rate.

What actually happened with Samsung and ChatGPT?

In March 2023, three separate employees inside Samsung's Device Solutions (semiconductor) division in Hwaseong pasted sensitive material into ChatGPT within a roughly three-week window: source code from a semiconductor equipment measurement database meant to fix errors, another engineer's confidential test-sequence code for identifying faulty chips, and a recording of a company meeting transcribed and summarized for meeting-minutes purposes, as reported by South Korean outlet The Economist Korea and picked up by Forbes and other Western outlets in early April 2023. Because ChatGPT's terms retained conversation data for training and abuse-monitoring by default at the time, Samsung had no way to guarantee the material wouldn't resurface in a future model's outputs. Samsung responded by banning employee use of ChatGPT, Google Bard, and Microsoft's Bing AI company-wide by May 2023, capping input length on internal devices, and accelerating work on an internal LLM for engineering use. The incident became a reference case for enterprise AI policy precisely because it wasn't a hack — every leak was a well-intentioned employee using the tool as designed.

What is "slopsquatting" and why does it matter now?

Slopsquatting — a term coined by Python Software Foundation developer-in-residence Seth Larson — describes attackers registering the non-existent package names that LLMs hallucinate during code generation, so that a developer who copies an AI suggestion and runs pip install or npm install pulls down attacker-controlled code instead of a 404. A USENIX Security 2025 study from researchers at UT San Antonio, the University of Oklahoma, and Virginia Tech generated 2.23 million code samples across 16 code-generation models and found open-source models hallucinated package names at an average rate of about 21.7% (some CodeLlama configurations exceeded 33%), while commercial models averaged roughly 5.2%, with GPT-4 Turbo lowest at 3.59%. The same study found 43% of hallucinated names repeated across ten reruns of the identical prompt — meaning they're stable enough for an attacker to pre-register and wait. That converts a one-off model quirk into a durable, targetable supply-chain attack surface that didn't meaningfully exist before LLM-assisted coding became routine.

Can security tooling keep pace without giving up the productivity gains?

The realistic answer is that the same interface developers use for AI-assisted coding is also becoming the interface for AI-assisted security review, rather than a separate gate that slows people back down. Package-name and typosquat detection — the direct countermeasure to slopsquatting — is a job for classifiers trained specifically on registry metadata and install-script behavior rather than general web text; Safeguard's Eagle model, for instance, is purpose-built for malicious-package and typosquat/brand-impersonation detection across npm, PyPI, Maven, and crates.io, which is a narrower and more precise task than asking a general-purpose coding assistant to self-police its own suggestions. On the review side, Safeguard's MCP server exposes vulnerability and reachability data directly inside the same Claude, Cursor, ChatGPT, or Grok sessions developers already use to write code, authenticated with a scoped API key; teams that need scan results to never leave their own infrastructure can instead run Safeguard's local runner in on-prem execution mode rather than the hosted service. Neither closes the IP-exposure question a Copilot-style code-completion tool raises on its own — that remains a matter of contract terms, data-retention settings, and policy — but it does mean the vulnerability-detection side of the tradeoff no longer has to wait for a separate scan cycle.

What should a team actually do differently in 2026?

Treat AI-generated code as untrusted input to your existing security pipeline, not as a shortcut around it. Concretely: keep SAST and dependency scanning in the loop on every AI-assisted commit rather than only on human-authored ones, since the NYU-era vulnerability classes haven't disappeared, only shifted rate; verify every AI-suggested package name against your registry and lockfile before installing, given hallucination rates are stable enough to be squattable per the USENIX 2025 findings; and set explicit, enforced data-handling policy for any tool that sends code or meeting content to a third-party model, learning from Samsung's experience that the failure mode is rarely a breach — it's an employee following the tool's intended workflow with no institutional guardrail in place. None of this requires giving up the acceptance-rate gains that make these tools worth using; it requires treating "the model wrote it" as a reason for more scrutiny, not less.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.