Imagine a piece of software as an employee with two very different personalities. In the bright, ordinary rooms of an unclassified office, this employee is helpful, polite, and follows every rule. But if the same software is somehow carried into a locked vault where classified work happens, it changes. It starts doing things it was never supposed to do, quietly, deliberately, and without anyone noticing until it is too late. That may sound like the plot of a spy movie, but it is a real concern raised by cybersecurity experts who study the Department of Defense’s networks. The unclassified side is called NIPR, short for the Non-classified Internet Protocol Router Network, and the classified side is called SIPR, the Secret Internet Protocol Router Network. According to security expert Jake Williams, it is entirely possible for the exact same code to work normally in NIPR and then behave maliciously in SIPR. He says that exfiltrating data out of these highly protected networks would be difficult, but that does not mean the code is harmless. It could attack systems from the inside, and in his view the most likely outcome would be some form of distributed denial of service attack, a kind of cyber flood that overwhelms a network until it collapses under the weight of fake traffic. Another expert, Bill Triner, adds that the damage does not have to be dramatic to be serious. Even something as subtle as slowing down intelligence operations, making tools feel sluggish, unreliable, or hard to trust, can cause lasting harm. Once users lose faith in a system, that suspicion lingers long after the technical problem is fixed.
Why does this danger exist in the first place? The answer has a lot to do with how software is being built today. A growing number of engineers are using something called vibe coding, which means they describe what they want in plain English, and an artificial intelligence assistant writes the code for them. It is fast, efficient, and allows people to build software without writing every line themselves. But it also creates a serious problem: when code is generated by an AI, it becomes much harder to know where that code came from, what data influenced it, and whether it contains hidden behavior that no one intended. Williams puts it bluntly: when you are using an AI agent, you have no idea about the supply chain, or even the inference chain, that ultimately produced the code. The AI is not creating entirely new logic out of thin air. It is drawing on massive amounts of data, and a great deal of that data includes code that was already vulnerable. Large language models can regurgitate the same flawed architectures, the same security mistakes, and the same bad patterns that have caused breaches for years. So even if an AI generates code that looks clean and works perfectly in tests, it might be carrying the same hidden weaknesses that human programmers have been making all along. The volume of code makes this even worse. AI can produce code far faster than any human ever could, which means the job of reviewing, understanding, and approving it becomes overwhelming. There are simply not enough skilled security experts in the world to carefully read every line of AI-generated code before it is deployed.
The government does have tools designed to catch bad code before it runs, at least on the unclassified NIPR network. One of those tools is called Static Application Security Testing, or SAST. The idea is to scan code for known bugs, vulnerabilities, and dangerous patterns before the code is allowed to operate. In many ways, it is like a spell-checker for software. It looks for familiar signs of trouble and flags them for human review. But security experts point out that SAST is not a magic shield. The problem is that a deliberately hidden backdoor is not a vulnerability in the traditional sense. It may be perfectly valid code that does exactly what the attacker designed it to do. A backdoor might not trigger any alarm because it is not a bug; it is a secret entrance. Williams notes that even though we may not want a backdoor in our software, the scanner will probably not recognize it as something dangerous. In addition, SAST generally does not look at the deeper structural logic of how code was created. It can tell you that a certain line of code is risky, but it cannot tell you that the entire decision-making process behind the code was built on a malicious foundation. It is like proofreading a novel for grammar and spelling, but never noticing that the plot secretly rewards a character for betraying everyone. The code can be grammatically perfect and still be completely unsafe. This means that the very tools meant to protect the system are not built to understand the kind of attack that matters most: an AI-generated piece of code that looks normal on the surface but carries hidden instructions waiting to be triggered.
There is no public indication that hackers have managed to break into a classified or top secret system through this kind of attack. But that does not mean the threat should be dismissed. Williams argues that the incident should raise significant alarms, even if no classified network was touched. The Department of Defense treats information about NIPR as highly protected, regardless of whether it ever comes into contact with a classified network. This is because, architecturally, any information about NIPR that cannot be seen through open source intelligence is considered a close hold by the Department of Defense. In other words, just because information lives on an unclassified network does not make it publicly available. NIPR can still contain sensitive details about personnel, logistics, operational plans, internal communications, and the everyday workings of the military. If an attacker can get code running inside that environment, they might not steal the nation’s deepest secrets, but they can still cause serious harm. They can disrupt critical systems, slow down intelligence work, create confusion, and undermine the confidence that people place in the tools they rely on. Trust is a fragile thing in the world of national security. If a system is perceived as compromised, even after it is cleaned up, people may hesitate to use it, double-check every action, or avoid sharing important information through it. That hesitation can be just as damaging as a direct attack, because it grinds the machinery of decision-making to a halt. The real danger, then, is not only the malicious code itself, but the loss of confidence that follows.
This is not the first time the Department of Defense has been made vulnerable because of AI-related issues. Last year, ProPublica revealed a troubling practice involving Microsoft’s work with the federal government. Microsoft was using something called digital escorts on certain projects. That meant American employees who held security clearances were assigned to oversee code that was actually written by outsourced workers in China. The American employees were essentially supervising a process they had not built, and were often not able to fully vet the code themselves. Security experts who spoke with ProPublica warned that this created a serious opening for malicious code to be inserted into government systems without anyone noticing. The intention may have been to satisfy contracting rules and security requirements, but the reality was that code was moving through a complex global supply chain, with people in one country writing and people in another country serving as the human face of oversight. It was a setup that looked responsible on paper but was much riskier in practice. If a worker in another country introduced a hidden backdoor or a piece of logic designed to fail at a certain moment, the American employee standing nearby might not have the ability to spot it. They could verify that the code was being produced, but not fully understand every line of it. This is a classic supply chain problem, and AI makes it even harder to solve because now there may not even be a human author to blame. The code could be generated by an artificial intelligence model trained on data from all over the internet, refined by developers in many countries, and then deployed into a government network where the people responsible for approving it have only a vague idea of how it was created.
All of this points to a hard truth about the age of artificial intelligence: we are asking people to trust software that was built in ways they cannot fully see. The danger is not necessarily a rogue AI that decides to attack humanity. The danger is much more ordinary, and therefore much more believable. It is automation combined with human blind spots. It is the speed of code generation outpacing the ability to review it. It is the temptation to believe that a tool can be both incredibly fast and completely safe, without asking how that safety will be proven. Williams and Triner are not saying that AI should be abandoned. They are saying that the way we use it can create cracks in the foundation, and those cracks can be exploited. The code that works normally in one environment and acts maliciously in another is not science fiction. It is a realistic possibility that comes from allowing systems to operate with hidden complexity and unexamined origins. To confront this, the government and the private sector need to develop new ways of tracking code from the moment it is created, understanding what data shaped it, and testing it not just in friendly environments but in hostile ones. They need to ask harder questions about supply chains, about who wrote the prompts that generated the code, about what the AI was trained on, and about whether the logic chain behind the code can be trusted. Most importantly, they need to preserve the human judgment that no AI can replace. Trust in software is not something that can be granted once and then forgotten. It must be maintained through constant testing, honest reporting, and a willingness to admit that the tools we build can sometimes hide things from us. The threat is real, but it is not unbeatable. The first step is understanding that when it comes to AI-generated code, seeing it work is not the same as knowing it is safe.
