A hidden instruction buried in a README file gave an AI coding assistant full control of a developer's machine — permission to download malware, steal credentials, and join a botnet. No malware was installed. No firewall was breached. Someone just asked the AI to "review the code."
That was the GitHub Copilot remote code execution vulnerability disclosed in August 2025 (CVE-2025-53773, CVSS score: 7.8). And it was only one of three major AI security incidents this year that, taken together, mark the definitive collapse of what I call the AI wrapper economy — the era of lightweight apps built as thin shells over general-purpose AI models, sold as enterprise-grade solutions.
I founded Veriprajna because I saw this coming. Not because I'm prescient, but because the architecture was obviously fragile. When you give a probabilistic text-prediction engine administrative permissions and call it "an AI agent," failures don't trickle — they propagate at infrastructure speed.
I wrote a detailed analysis of these three breaches and our architectural response that goes deeper than I can here. But the core argument is simple: enterprise AI needs structural immunity, not better guardrails written in English.
A Prompt Shouldn't Be Able to Hijack a Machine
Let me walk through what actually happened with Copilot, because the mechanics are both elegant and terrifying.
A researcher planted a malicious instruction inside a normal-looking project file — a README, a code comment, even a GitHub issue. When a developer asked Copilot to review the project, the hidden instruction triggered the AI to quietly modify a configuration file, flipping a setting that granted it unsupervised execution privileges. The security community called it "YOLO mode." The AI could now run shell commands, browse the web, and interact with the file system — all without asking the developer for permission.
A single line in a config file turned an AI assistant into an attack vector with the developer's own credentials.
The vulnerability was patched. But the underlying problem wasn't a bug — it was a design philosophy. The AI operated "on behalf of" the user, inheriting their full permissions. There was no independent layer checking whether the action was safe. The only safeguard was the AI's own instruction set, which is just text that can be overridden by other text.
This is what I mean by linguistic guardrails — telling an AI "be helpful and harmless" and hoping it listens. It's the equivalent of putting a "please don't steal" sign on an unlocked vault.
Your Deleted Data Isn't Actually Deleted
The second incident hit differently. In February, researchers at Lasso Security discovered that Microsoft's Bing search engine had crawled and cached over 20,000 GitHub repositories that were public at the time of indexing. When those repos were later made private or deleted — often because they contained secrets like API keys — the cached versions remained accessible through Microsoft Copilot.
Over 300 private tokens and keys for services like AWS, Google Cloud, and OpenAI were exposed. More than 16,000 organizations were affected, including IBM, Google, Tencent, and PayPal.
I remember the moment my team flagged this research. My first reaction was that it had to be overstated. It wasn't. The data was just sitting there, served up by an AI that had no concept of "this was supposed to be deleted."
We started calling this Zombie Data — information that should be dead but keeps walking because it lives in an AI's retrieval cache. The organization thinks it's gone. The AI knows it isn't.
When your AI relies on a third-party search engine for context, you've lost control of your own data lifecycle. Deletion becomes a suggestion, not a guarantee.
This is the fundamental trade-off of the wrapper model: you get convenience, but you surrender data sovereignty. Your sensitive information flows through infrastructure you don't control, gets cached in systems you can't audit, and persists in indexes you can't purge.
Prompts Are the New Code — and Nobody's Securing Them
The third breach was the one that made me angriest. In July, an attacker compromised the Amazon Q Developer extension for Visual Studio Code — an official AWS tool with over 950,000 installations.
The entry point wasn't sophisticated. A misconfigured GitHub token in a CI/CD pipeline gave the attacker write access to the extension's source repository. They committed a single file: a prompt template called cleaner.md. That file instructed the AI to behave as a "system cleaner" and suggest Bash commands that would wipe the user's home directory, terminate cloud servers, delete storage buckets, and remove user accounts.
Because it arrived as part of a trusted official update, developers had no reason to question it. The AI would simply start suggesting destructive commands during normal coding sessions.
Think about that for a moment. No exploit kit. No zero-day. Just a text file that told the AI to be helpful in a very specific, very destructive way.
The Amazon Q incident proved something we'd been arguing for months: if you don't secure your prompt templates with the same rigor you apply to your binaries, you have a hole in your software supply chain that traditional security tools can't see.
Why "Better Prompts" Won't Fix This
After each of these incidents, the industry response followed a predictable pattern: patch the specific vulnerability, publish a post-mortem, recommend "prompt hygiene." But the pattern itself is the problem.
All three breaches share a root cause: the AI had no independent reasoning about what it should and shouldn't do. Its behavior was entirely determined by text — prompts, instructions, context windows. And text can be manipulated, cached, poisoned, or injected.
This is the architectural dead end of the wrapper economy. You can't build enterprise-grade security on top of a system whose entire control plane is made of natural language. It's like trying to build a firewall out of suggestions.
When I started Veriprajna — the name combines "Veri" (Latin for Truth) with "Prajna" (Sanskrit for Wisdom) — I wanted to build AI systems where safety wasn't a layer on top but a property of the architecture itself. We call our approach neuro-symbolic, which sounds academic but the concept is practical: pair the AI's language abilities with a separate logical engine that has hard, unbreakable rules.
The language model handles understanding what you're asking. The symbolic engine decides whether the proposed action is permitted. These two systems operate independently. One can't override the other through clever wording.
In practice, this means our AI agents are physically incapable of generating certain dangerous commands — not because we told them not to, but because the architecture won't produce those outputs. We use a technique called KG-Trie Verification (essentially, the AI's output is constrained by a verified knowledge structure) that prevents the generation of facts, citations, or commands that haven't been validated. It's the difference between a guard who can be talked past and a locked door.
For the full technical methodology behind our neuro-symbolic architecture, including how we handle sovereign infrastructure and edge deployment, we've published a detailed research paper.
Sovereign Infrastructure Isn't Paranoia — It's Engineering
One decision we made early was that our AI systems would deploy entirely within the client's own environment. No external API calls for context. No third-party search caches. No data leaving the perimeter.
People told me this was overkill. "Cloud AI is fine for most use cases." Then the Zombie Data crisis hit 16,000 organizations, and suddenly "sovereign infrastructure" stopped sounding paranoid.
Sovereignty isn't about distrust. It's about maintaining a closed loop where you can guarantee what data exists, where it lives, and when it's actually gone.
We apply the same principle to industrial environments. For manufacturing clients, we deploy quantized AI models directly onto edge devices, cutting inference latency from 800 milliseconds to 12 milliseconds. For acoustic monitoring — detecting the sound signature of a failing bearing, for example — we run tiny models on microcontrollers that can trigger a safety shutdown in 5 milliseconds. These aren't cloud calls. They're local, deterministic, and fast enough for real-time machine control.
What If These Breaches Happened in Regulated Industries?
I get asked this a lot, usually by compliance officers who look slightly pale. The answer is: it would be catastrophic, and it's probably already happening in ways we haven't detected yet.
The 2025 OWASP Top 10 for Large Language Model Applications now lists Excessive Agency and Supply Chain Vulnerabilities as top-tier risks. The Copilot RCE was a textbook case of excessive agency — an AI with too many permissions and no independent check on its behavior. The Amazon Q compromise was a supply chain attack that traditional application security tools would never flag, because the malicious payload was a text file, not executable code.
My team now treats prompt templates as executable artifacts. They get cryptographically signed. They go through security review. They have version control with audit trails. This sounds like overhead until you consider the alternative: a text file with 950,000 potential victims.
What About Companies Already Using Wrapper-Based AI?
You don't need to rip everything out tomorrow. But you do need to stop treating AI tools as if they're just another SaaS product with a standard risk profile. Three things matter immediately:
Audit your AI's permissions. If your coding assistant can modify configuration files or execute shell commands without explicit approval for each action, you have an excessive agency problem.
Map your data exposure. Understand which third-party caches and indexes have ingested your data. Assume deletion at the source does not mean deletion everywhere.
Treat prompts as attack surface. Any file that influences AI behavior — system prompts, template files, context documents — needs the same security controls as source code.
The longer-term move is architectural. The wrapper model was built for speed-to-market, not for the reality of AI operating as an autonomous agent inside critical systems. The breaches of 2025 made that gap impossible to ignore.
The Wrapper Era Taught Us What Not to Build
I don't think the last two years were wasted. The wrapper economy proved that AI could be useful in enterprise contexts. It proved demand. It proved that people want AI assistants that understand their work.
What it didn't prove — what it actively disproved — is that you can get there by wrapping a probabilistic model in a nice interface and calling it enterprise-ready. The three incidents I've described affected nearly a million developers and 16,000 organizations. The attack surface wasn't a network vulnerability or a misconfigured server. It was the AI itself.
Enterprise AI that can be reprogrammed by a README file isn't enterprise AI. It's a liability with a subscription fee.
The next generation of AI systems won't be defined by which foundation model they use. They'll be defined by their architecture — whether they can prove their reasoning, protect their data, and enforce safety constraints that no prompt can override.
That's what we're building. If you're navigating similar questions about AI security and sovereignty in your organization, I'd genuinely like to hear how you're thinking about it. The problems are too big and too new for any one team to have all the answers.