Proprietary Code and AI: The Risk Your Developers Are Taking Without Telling You

Proprietary code security in the age of AI isn't something your CISO needs to worry about in six months, it's something you need to worry about this week. On a recent engagement at Extra Dev, we watched a client lose two days tracing what an intern had pasted into a consumer-grade AI assistant before we locked down access, for a fix that normally takes an hour.

The most common reflex is to force a false choice: block every AI tool, or let the team do whatever it wants. Neither option protects your code, and I'm going to show you why with facts, not fear.

The real risk isn't the bug, it's what your dev pastes into the prompt

A developer stuck on a production incident is thinking about fixing it fast, not about security. They open an AI assistant and paste in an error trace, a config file, sometimes an entire chunk of proprietary code. That's the scenario described in a series of H2H Technology videos on governing AI coding assistants: the request can contain customer credentials or API keys without the developer even noticing.

This isn't a hypothetical. According to webnet.fr, Samsung engineers leaked confidential source code to ChatGPT in just 20 days, back in 2023. That data fed OpenAI's servers and became impossible to retrieve. The same source claims 38% of employees now share confidential data without authorization, a phenomenon the industry calls "shadow AI" (undeclared use of AI tools, outside IT's control).

Why does shadow AI slip past your IT department?

Because it doesn't go through any controlled gateway. A browser extension, a personal API key, an agent connected in thirty seconds: each interaction can move sensitive data with no trace to audit. An engineer working on a mission-critical aerospace system runs into the same problem, documented in a video dedicated to regulated industries: the contractor remains liable for how the information was handled, AI or not. If your company handles sensitive customer data, the question isn't "could this happen" but "is this already happening to you", a topic I dig into from the non-technical side in what it costs to deploy without technical oversight.

AI-generated code compiles almost every time, but stays vulnerable roughly half the time

Where a lot of leaders get falsely reassured is by confusing "it works" with "it's safe." A Veracode study cited by kaspersky.fr benchmarked over 100 popular AI models on Java, Python, C#, and JavaScript code: the code produced compiles successfully 90% of the time today, up from under 20% two years ago. Speed has exploded.

Security, on the other hand, has barely moved. According to the same study, 45% of generated code contains a classic vulnerability from the OWASP Top 10 (the industry-standard ranking of web security flaws), a figure that's held steady for two years. Your AI assistant delivers code that runs, but roughly one feature in two potentially ships with a backdoor nobody has audited.

Should you trust the code Claude or Copilot hands you?

No, not without human or automated review. That's the conclusion from a thread on the r/devops subreddit: a SecOps team there refuses to let cloud AI agents scan entire proprietary repositories, while admitting the productivity gap has become hard to ignore. Their compromise: map the repo tree locally, send only targeted context signatures, and require manual approval on every change written to disk. Crude, but I see this pattern reproduced on nearly every engagement we run.

I've seen the same pattern in our own code reviews: projects that treat Claude Code or Copilot as a productive but unreliable junior, with systematic review, come out far ahead of those that merge the AI's output directly. This isn't a matter of style, it's the difference between shipping fast and shipping a security debt you discover during an audit.

Obfuscating your code no longer protects your competitive edge

This is where most leaders who think "our code is compiled, so it's protected" get it badly wrong. An article on korben.info documents how developer Geoffrey Huntley asked Anthropic's Claude to analyze the cli.mjs file of Claude Code itself, a 5 MB minified file stripped of its symbols specifically to prevent reverse engineering. Claude produced readable, functionally equivalent code in 30 minutes.

Compilation and obfuscation (deliberately scrambling code to make it unreadable) are no longer reliable protection for your intellectual property. A competitor equipped with an LLM with a large enough context window (the amount of code the AI can analyze in a single pass) can reconstruct your product logic without copying a single line, making infringement nearly impossible to prove. Startups selling paid licenses on "source available" code (visible but under a restrictive license) are the first exposed: their only technical barrier has just collapsed.

How did Claude disassemble its own code in 30 minutes?

By installing the public npm package for Claude Code, locating the compiled file at the core of the application, then asking the model to inspect it and rebuild a readable version. No specialized reverse-engineering tools were needed, just a well-crafted prompt. If a lone engineer can do this in an evening, your best-funded competitor can do it at scale.

Who owns the code AI wrote for you?

This is the question too many companies only ask after the incident. According to app.asso.fr, when an LLM suggests code, it's drawing on training datasets containing billions of lines, some of them under restrictive open-source licenses. Integrating that code without checking its license can amount to infringement, and the GitHub Copilot case remains the most widely cited example.

Second blind spot: does your software keep its copyright protection if it contains a significant share of AI-generated code? The answer depends on how much originality the final product retains, according to the same source, but the legal ground here is still shifting. altij.fr notes that a bill aiming to regulate AI through copyright law has been introduced before the French National Assembly, and that the European Cyber Resilience Act has imposed new cybersecurity obligations since 2026, with a September 11, 2026 deadline that few publishers have prepared for.

If your code contains AI-generated pieces with no traceability of their origin, your legal protection is more fragile than you think. It's a point we address systematically in our engagement contracts, especially for remote work: it's worth a detour through the contract clauses that actually protect your code.

What actually works: a controlled gateway, not blocking or laissez-faire

After these four findings, one thing is obvious: blocking AI sacrifices your velocity for a risk that just migrates to undeclared shadow AI. Allowing unrestricted access stacks all four risks above at once. There's a third path, and it's neither theoretical nor expensive to set up.

Full disclosure: I run Extra Dev, where we deliver with senior developers (eight years' experience minimum, never less) augmented by AI on clients' proprietary repositories. That inevitably biases my view, but it comes with a protocol tested across dozens of engagements rather than an abstract argument.

The protocol comes down to three rules. Precise specifications before any AI-assisted coding session (I believe a good AI project starts from clear acceptance criteria, never a vague prompt). Work broken into short, testable chunks, reviewed before merge, never an agent touching production without human sign-off. And no secrets hardcoded anywhere, in code or in prompts: API keys go through a secrets manager, never through a conversation with an assistant.

An open-source project spotted on r/regolo_ai formalizes an industrial-strength version of this same logic: a loop that audits the code (SAST/AST scanning, static analysis that catches flaws without executing anything), retains architectural constraints in memory, requires human approval before any patch, then revalidates in zero-trust mode (no default trust) before merging. The same spirit shows up on the commercial gateway side too, with tools like Tutela that inspect traffic headed to AI assistants and enforce a policy (mask sensitive data, warn, or block) before the request ever reaches the model.

What's the minimum protocol before letting an agent near a proprietary repo?

Three checks are enough to get started. One, confirm your enterprise AI plan contractually guarantees zero data retention, not just a marketing promise. Two, mandate human review on any code touching authentication, payments, or personal data, exactly where the OWASP vulnerability rate measured by Veracode hits hardest. Three, ban pasting raw error traces into consumer-grade tools, training your teams on real cases rather than a policy document nobody will ever read.

"The real issue with an AI agent isn't its intelligence, it's its operational reliability: who approves what, where the secrets go, and what happens when it breaks."

Vincent, August 2026

A senior dev running an AI-augmented team is often worth more than a larger conventional team, provided you know exactly what to hand off to the agent and what to keep under human control, a topic I cover in the augmented developer and what it means for a project budget.

The verdict: don't block it, govern it

The answer to "should AI be allowed on proprietary code" is yes, but never without a control gateway. Blocking it just pushes the risk into shadow AI you'll never see coming. Letting it run unrestricted stacks all four risks detailed above: prompt leaks, code that's vulnerable half the time, obfuscation that no longer protects anything, uncertain legal status.

The decision criterion is simple: if your team handles sensitive customer data or code with strong competitive value, put a controlled gateway and human review in place before the end of the quarter, not after your first incident. If your exposure is low, lighter guardrails plus team training will do. Either way, secrecy is no longer a viable strategy: it's process that protects your code, not compilation.