In this Help Net Security interview, Dr. Jaushin Lee, CEO of Zentera Systems, discusses where AI supply chain risk shows up. He says most incidents still hit developer workflows and open-source package repositories, while poisoned model weights and compromised MCP servers stay mostly in research demos.
He explains why segmentation buys more risk reduction per dollar than tooling, where self-hosting a model falls short, and which semiconductor isolation practices software teams should copy. He also names the security belief he has since abandoned.
Supply chain risk used to mean dependencies and software bills of materials (SBOMs). Now it also means model weights, model context protocol (MCP) servers, agent tools, and vector stores. Which of those is producing incidents in your customer base, and which is producing conference talks but no incidents?
Right now, the majority of active supply chain incidents hit basic developer workflows and open-source package repositories. Exotic attack surfaces like manipulated model weights, poisoned vector stores, and compromised MCP servers are real structural threats, but today they live primarily in security research and conference demonstrations.
However, assuming those emerging vectors will stay theoretical is dangerous. It takes only a single discovered campaign in the wild for a proof-of-concept threat to become a headline incident overnight.
We are already seeing AI-native supply chain attacks targeting developers directly. A prime example is the active “Phantom Raven” campaign. Threat actors observe how generative AI tools hallucinate non-existent software package names during “vibe coding” sessions. Attackers then intentionally register those hallucinated package names in public repositories, loading them with malicious payloads. When an unmonitored developer script or AI agent automatically fetches the recommended dependency, it silently installs malware into the build pipeline.
Keep your eye on model weights and MCP servers, but recognize that attackers are currently using AI to exploit simple human trust and package management habits.
If a company can fund exactly one project this fiscal year, do they segment the developer environment or instrument the AI tooling? Which buys more risk reduction per dollar, and what would change your answer?
Environment segmentation delivers significantly more risk reduction per dollar. Segmentation provides a structural containment layer against “unknown unknowns.” It does not matter what new AI tool a developer runs or what novel exploit an agent uses. If the surrounding network prevents that machine or process from reaching adjacent corporate assets, the damage is strictly contained.
However, operational realities often force a different priority. Proper environment segmentation requires deliberate architectural planning and cross-departmental alignment, which takes time. If your organization runs an AI-native development pipeline or faces immediate government, risk, and compliance (GRC) audit pressures, leadership may demand dedicated AI session controls and visibility tools first.
What would fundamentally change my answer is data sensitivity. If your environment handles ultra-sensitive intellectual property, high-value financial records, or strict regulatory data that can never leave its boundary, you must prioritize environment segmentation first. You cannot rely on tooling instrumentation alone when a single data leak constitutes a catastrophic compliance breach.
Self-hosting a model gets sold as the conservative choice. Where does that assumption break down in practice?
Self-hosting a model is a great step for keeping data from being transmitted to third-party SaaS providers, but it’s a false comfort if you assume that solves your security problem. Self-hosting doesn’t eliminate risk. Rather, it simply transfers all of that operational responsibility onto your internal team.
The assumption breaks down because hosting the model locally does nothing to control what the local AI agent can do across your network or the open internet. An agent interacting with a self-hosted model can still execute malicious local commands, pull unverified external dependencies, or leak credentials if its execution environment lacks boundaries.
Furthermore, self-hosting raises the operational bar. Your team is now entirely responsible for patching model infrastructure vulnerabilities, monitoring for abuse, and red-teaming the deployment—tasks that commercial cloud providers otherwise handle for you. If you self-host a model without enforcing strict local sandboxing around the agent, your supply chain exposure remains identical to using a public API.
Semiconductor customers guard design data harder than almost anyone. Which of their practices should a typical software company copy, and which would be wasted money?
Software companies should immediately adopt the semiconductor industry’s approach to project-level enclaves and “chambering.” In chip design, teams isolate specific project workloads into software-defined enclaves, enforcing strict egress controls, explicit authorization, and comprehensive session logging. Applying those same concepts to software development can help you make sure that an AI agent or developer working on Project A can never reach, view, or cross-contaminate the proprietary code repositories of Project B.
What software companies should not copy is the traditional semiconductor habit of building air-gapped, physically separated hardware networks for every development group. Building separate physical networks for every team or client engagement is prohibitively expensive, operationally rigid, and completely unnecessary for modern cloud-native workflows.
Instead of physical air-gapping, software teams should virtualize those boundaries. Using software-defined segmentation, you can maintain a single, agile data center or cloud environment while achieving the exact same mathematical project isolation that semiconductor giants rely on.
What security measure did you believe in five years ago that you would not recommend now?
Five years ago, I believed privileged access management was a valid strategy: vault the credentials, enforce least privilege by identity, and the assets were protected. Zero trust had already begun eroding that belief. Its lesson was that standing trust for network access is the real exposure. There’s a subtle but important distinction between “who has the privilege to access this asset” and “who can send traffic to this asset.” The first is an application-layer question. The second is a network-layer question, and it’s the one that decides whether an attack progresses.
Agents finished the argument for me. Per-identity privileges can’t be authored fast enough for ephemeral swarms, and an agent can misuse privileges it was legitimately granted. Privileges were never a perimeter. The control that matters now is containment, scoped to task, and intent.
Download report: How security controls perform in practice