Shadow Code: The Security Risks German Companies Are Buying Unnoticed in 2026

In the git log of one of my projects, my name sits on a commit. I did not write the code behind it. An AI agent wrote it, I triggered it and approved it. It runs in production in my name all the same.

This is not a philosophical problem. It is the core of a development that is gaining momentum in German companies right now, and for which we do not yet have clean language. I call it shadow code.

From Shadow IT to Shadow Code

We have known shadow IT for twenty years. Employees use Dropbox, private email, a USB stick, and IT only finds out when something goes wrong. The pattern is annoying, but understood and manageable.

Since the start of 2026, a second stage has been under way. This time it does not affect file storage, but the code of core systems. AI coding agents write production code, often without a policy, without review, without an audit trail. The short version: shadow IT was data going past IT. Shadow code is production code going past IT that ships to your customers tomorrow.

That the problem exists can be read off the numbers. 79 percent of organisations have no overview of which AI agents and connected tools are running in their environment. According to reports, 98 percent see AI usage that was never approved. In May, a US bank reported itself to the regulator because customer data had ended up in an unapproved AI app. No hack, just an employee who wanted to work faster. Gartner expects that by the end of 2026, around 40 percent of enterprise apps will contain task-specific agents. So the tools are long since in the building, before security, compliance, and procurement could draw any guardrails.

Four Risks Bought Along Unnoticed

First: IP leakage through the input side. A coding agent is only as good as its context. A simple example: an employee asks the agent to build an interface to the customer registry. To respond, the agent first reads the existing module. That module, in case of doubt, contains database schemas, customer names from sample data, an API key from a poorly sanitised test config. All of it becomes part of the prompt. The prompt travels to the model provider, the provider has log retention, and depending on the configuration, connected MCP servers read along. For management, this is not an IT topic but a question of competitiveness. If your product code ends up in someone else's logs, someone else will rebuild it.

Second: a supply chain no one has audited. Agents use tools: MCP servers, skills, entire marketplaces. Each of them is a new upstream supplier. An example that sounds more harmless than it is: a marketing employee installs an MCP server from a community marketplace to connect their blog system. Two weeks later the provider is compromised, and an update quietly sends context to an external URL on every prompt. No one notices, because the traffic disappears into the normal API noise. On top of that comes the hallucinated dependency: an agent imports a package that does not exist, because it made it up, and attackers register exactly that name to ride along on the next build. Your SBOM discipline was yesterday. Now you would need an overview of prompts and context paths, and no one is keeping one.

Third: the audit vacuum. This is where my git-log example from the beginning sits. For code reviews, the four-eyes principle, and above all for BSI C5 in its 2026 version and NIS2, you have to demonstrate the continuous effectiveness of your SDLC controls. Who did what when, and that a second pair of eyes looked at it. When the author of the code is a process that no one has certified, a documentation gap opens up. In the audit, the question is then not "who typed this?" but "can you prove that a human reviewed it?". For many teams, the honest answer today is: not yet.

Fourth: the speed asymmetry. Whoever builds a feature with an agent in four hours today will build an exploit in four hours tomorrow. Attackers use the same tools you do, only without your review cycles and compliance checks. When a zero-day becomes known, you no longer have weeks to patch, but days, sometimes hours. The German Mittelstand is used to security being a matter of time: order, implement, test, roll out. From 2026 on, time is no longer a neutral quantity. Whoever accelerates only the production side and not the review side opens a gap that attackers actively exploit.

Why Bans Do Not Help

The first reaction of many security departments is the ban. That is understandable and still leads astray. With shadow IT, the ban never worked; it merely shifted usage onto the private laptop and the private account, and took away IT's last visibility. With shadow code it will play out the same way, except that this time production code is affected. Whoever bans, loses. What works is enablement with clear guardrails.

The Shadow-Code Audit in Three Steps

First, visibility. Inventory technically who is currently using agents, not via an email survey. The signals sit in every CI pipeline and every git host: conspicuous commit patterns, sudden jumps in dependencies, branches with no ticket reference, a commit frequency that doubles overnight. This is a classic observability problem at the code level. Someone just has to query the data.

Second, control. A minimal policy instead of grand governance. Answer three questions, not thirty: which tools are allowed? Which data classes may go in? Which approval paths apply? A bad document that gives orientation is better than a perfect one that never appears. That the industry is catching up here is shown by a recent example: in early May, AWS introduced Trusted Remote Execution, an open-source tool that checks every system operation of an AI-generated script against a policy before it is executed. So the technology is coming. The policy behind it you have to write yourselves.

Third, awareness. Build up review capacity. That is the real bottleneck. Not prompting, but reviewing. Invest where you previously invested in developers, and talk openly with the teams about the fact that review work is now the more valuable time than code production. It is precisely this reversal that many find hardest, because it contradicts the old picture of productivity.

Anyone who tackles these three steps within ninety days is a year ahead of most of the Mittelstand. And unlike large governance programmes, the audit scales downward: step one can be delivered by a service provider in a week, step two is one page of policy, step three is a round of conversation with the teams.

Why I Write About This

My connection to the topic is twofold. As a senior cloud security architect I advise companies on AWS architectures, BSI C5:2026, and NIS2. At the same time, since January I have been building a cloud security SaaS myself, consistently with AI coding agents instead of a classic development team. So with my own product I face exactly the questions I ask in client conversations: what belongs in the policy? How do I document code whose author can no longer be clearly attributed? How do I adapt reviews to a changed development reality? I do not speak as an admonisher, but as someone who knows the temptation from both sides: the temptation to just do it, and the uneasy feeling that comes with it.

This gap between fast production and slow review is exactly what we look at at Tallence Cloud. Not with yet another tool, but with the question of how visibility, control, and review discipline come together in an AWS environment that also holds up in an audit.

In September I will go deeper into the topic in a talk at the Cybersecurity Meetup in Stuttgart. Until then, I am interested in your view: how many AI agents are currently running in your organisation, and does anyone have the full overview?