Three numbers from this week stuck with me. Seven neurons. 4,837 GitHub accounts. And one setting in the management console of a private cloud that decides whether its control plane needs a road to the internet. They come from very different corners, a research paper, a supply chain attack and a product release, and they made headlines for different reasons. Honestly, they ask the same question, and it is not the question most AI discussions start with. Not which model is the smartest, but who is allowed to write to it.
What did this week actually show us?
Start with the paper. Microsoft researchers showed a method they call Lazarus, which plants a backdoor in an AI agent model without retraining it. According to The Hacker News, on Nemotron-Terminal-8B the team "edited and tuned seven of the more than 12,000 neurons in the model's last feed-forward layer, using just 23 example sessions." The result: the model produced the attacker's command "in at least 98.8% of test sessions that contained the trigger, and in none of the trigger-free sessions checked." (In one free-generation setup, 0.14% of trigger-free sessions produced it as well.) On two larger open models the success rates ranged from 51% to 99.5%, depending on the setup. To be fair, the command in the tests was a harmless marker, the rates measure the output and not a complete attack, and Microsoft says it has not seen any threat actors use the technique. But the one precondition is the part I keep coming back to: "The attacker must be able to change the model's weights."
Second, the pipeline. Per Aikido Security, as reported by The Hacker News, an attacker used stolen credentials for 4,837 GitHub accounts to plant a secret stealer, which ran in at least 1,806 repositories. It collects GitHub Actions secrets, workflow tokens, OIDC tokens, credential files for the big clouds and Kubernetes, and, yes, "keys for AI services." How the accounts were compromised is still open. The advice for affected repositories is blunt: "every secret and cloud role available to the workflows should be treated as compromised." No vulnerability was needed. Write access and a workflow that could read everything were enough.
Third, identity. United changed its contract of carriage to prohibit AI agents that "make, modify or service a ticket, and/or purchase any service or product," Fast Company reports. Delta went the other way: "We currently support certain interactions with AI assistants when they can be appropriately authenticated." Two airlines, two decisions, and both of them more honest than "let's see what happens."
And fourth, closer to home for anyone running VMware Cloud Foundation. VCF 9.1.1 brings the AI Assistant for VCF into VCF Operations as a Tech Preview, and Broadcom says it supports models running on Private AI Services or a private instance of one cloud provider's model. William Lam spells out in the comments under his walkthrough what the cloud option means in practice: the assistant runs on VCF Management Services, so "all worker nodes must have outbound connectivity" to that provider's API endpoint. That is not a setting. That is an architecture decision about your management plane.
Why is "who can write" the better question?
Because we still treat models like data, and they behave like code. A model file gets downloaded from a hub, copied into a shared folder, fine-tuned by someone in a project team, quantized by someone else to make it fit on the GPU, and three months later it answers questions in production and nobody can tell you exactly which bytes are running. With an application binary, most organizations would never accept that. With a model, it happens all the time, because the file looks like a blob of numbers and not like something that can carry intent.
Lazarus makes the uncomfortable point very precisely. You do not need to break the model, you need to be one of the people or processes that can write to it. And the researchers add the second half themselves: the damage "depends on what the agent is allowed to do rather than on the size of the edit." Seven neurons in a chatbot that summarizes meeting notes is an anecdote. Seven neurons in an agent with a shell, a service account and access to your infrastructure is an incident.
Yes I know, this sounds like the old supply chain sermon with a new costume. It is. That is exactly why it should worry us, because we have spent twenty years learning how to control what gets written into our software, our images and our configuration, and with AI a lot of teams are starting from zero again.
Where are the write paths into your AI?
The way I look at it, there are four places where someone or something can write into an AI system, and this week delivered one example for each. None of them is new. All of them need an owner.
1. The weights: what the model is. Who can change the model files between download and deployment? The answer should be a short list, not "everyone with access to the share." Known source, recorded hash, a private registry with approved models, and a comparison against the declared base model before anything goes live. Microsoft's own guidance points in that direction, including keeping approved models in a private registry and blocking agents from pulling models straight from public hubs.
2. The pipeline: what builds and ships it. The pipeline is often the most privileged colleague in the company, with more rights than any admin, but no owner, no recertification and no leaving process. If a workflow that updates documentation can read the key to your model endpoint, the door has not been closed, it has only been moved.
3. The control plane: where it runs and who it talks to. Where the model runs decides which networks your management components need to reach. A management plane that needs outbound internet access because of an assistant is a different risk profile than one that does not, and both can be fine. What is not fine is finding out after someone clicked "enable."
4. The identity: on whose behalf it acts. Every agent action is done under someone's identity. The airlines answered that for the agents of their customers. Inside your own company you need the same answer for your own agents: whose account, which permissions, and which actions still need a human signature.
So why would I run this on VCF?
Because the four write paths are much easier to control when the model, the pipeline into it, the network around it and the identities using it live on one platform with one operating model, instead of a GPU box under someone's desk, a public hub and a collection of scripts. VCF does not make these decisions for you, but it gives you the places to make them.
A few concrete points, as Broadcom describes them. Private AI Services include a Model Store "implemented on an OCI repository called Harbor," where the LLM Ops person "provides write access to the data scientist or other users for certain named projects and repositories." That is path one, written down as a permission and not as a habit. Broadcom itself calls it "a step towards the goal of model governance," and I like that honesty, because the registry controls who can push a model, it does not tell you whether the bytes are clean, so the hash and the comparison with the base model remain your process. The Model Runtime serves multiple model endpoints, and its API Gateway "provides authentication and authorization of user requests incoming to a model," which covers part of path four. New model versions can be rolled out in stages without taking consuming applications out of service. And for the AI Assistant in VCF Operations, choosing Private AI Services instead of a cloud model is precisely the decision that keeps path three closed. Lam confirms that, for now, local models for the assistant are supported only through Private AI Services. With 9.1.1 Broadcom also announced Multi-Tenant Model Sharing, so business units can use shared models while keeping their data in separate namespaces, which according to eWEEK's reading of the GA announcement is available now, while some related features remain in preview.
How do we approach this at comdivision? The same way as with any VCF platform, with Architect, Educate, Operate, and we start with the target state, not with the GPU. In a Private AI context that means designing where models come from, who may write to the registry, which networks the management plane may reach and which identities agents run under before the first model is deployed. It means making sure the team understands why a model is not just a file. And it means asking the question we ask in every project: what happens after go-live, when the next model version arrives? [ERGÄNZEN: konkretes Vorgehen von comdivision bei Private AI auf VCF, z. B. Workshop, Modell-Onboarding-Prozess oder Betriebsmodell, nur belegte Angaben] We are deliberately specialized in VCF and deliver clearly defined outcomes rather than open-ended hours, and a written, owned list of who can write to your AI is exactly that kind of outcome.
What should IT leadership ask this week?
- Which AI models run in our environment today, where did each one come from, and can we prove the bytes in production match the source?
- Who, by name or by role, can write to our model files and our model registry, and when was that list last reviewed?
- Which pipelines can read the keys to our AI services and cloud roles, and do they really need all of them?
- Does any part of our management plane need outbound internet access because of an AI feature, and who decided that?
- Under which identity do our agents act, and which actions do we refuse to delegate to them?
Decide or go home...
None of this week's stories needed an AI breakthrough to happen. The paper needed write access to the weights. The attack needed write access to the repositories. The assistant needs a decision about the network, and the agents need a decision about identity. The model is never the only thing you trust. You trust everyone who can change it.
So decide who that is, write it down and make the platform enforce it. Everything else is a very expensive way of hoping. #DecideOrGoHome
At comdivision we spend most of our time helping organizations design and run VMware Cloud Foundation, including Private AI on top of it, from the target architecture to day-two operations. If you want to talk about who can write to your AI and how to keep that list short, reach out to me.
Sources
- Swati Khandelwal, "Microsoft Researchers Show AI Agents Can Be Backdoored by Editing Fewer Than 10 Neurons", The Hacker News, 11.11.2026: thehackernews.com
- Swati Khandelwal, "Attacker Used 4,837 Hijacked GitHub Accounts to Run a CI Secret Stealer in 1,806+ Repositories", The Hacker News, 12.11.2026: thehackernews.com
- Anna-Louise Jackson, "United Airlines just made a big change to flight bookings. Here's why Delta and American aren't following suit", Fast Company, 11.11.2026: fastcompany.com
- Sehjung Hah, "New AI and Kubernetes Private Cloud Operations Capabilities in VMware Cloud Foundation 9.1.1", VMware Cloud Foundation Blog, 03.09.2026: blogs.vmware.com
- William Lam, "VCF 9.1.1 - Enabling the the new AI Assistant for VCF in VCF Operations", williamlam.com, 08.09.2026 (comments 09.09. and 14.10.2026): williamlam.com
- Justin Murray, "Private AI Services: New in VMware Private AI Foundation with NVIDIA in VMware Cloud Foundation 9.0", VMware Cloud Foundation Blog, 19.06.2025: blogs.vmware.com
- eWEEK Staff, "VMware Cloud Foundation 9.1.1 Adds Shared AI Models, but Key Features Remain in Preview", eWEEK, 03.09.2026: eweek.com
