Whose GPU is it,
and who else can see your workload

1. The place of the talk in the day

The talk runs in the same short-presentations block as the analysis of expertise extraction, and together they close the day from two sides. There the subject was where knowledge comes from and how to preserve its ownership. Here the subject is what happens to knowledge, models and data when they end up on someone else's hardware.

It helps to see the link to the third talk of the day. There sovereignty was examined as a set of provable authorities and carried down to the layer of the megawatt and the power contract. Here the same layer is treated as an attack surface: if the authorities do not exist or are not checked, then the question is no longer who controls the workload legally, but who has physical access to it.

2. Who is speaking

The speaker introduces himself as an engineer with twenty years of work in Silicon Valley and with experience of large-scale infrastructure: he speaks of building systems of the same class as public clouds. He is now the founder of a company that is building a decentralized cloud with the promise that data and services belong to their owner and that this can be verified.

This position makes the talk interesting by its construction. A person who is building decentralized infrastructure appears with an examination of its weak points and says plainly that he is himself an advocate of such computing. From this comes a rare genre: criticism not from outside but from within the field, and for that very reason it is more convincing than an ordinary list of risks.

3. Transcript corrections: what the recording heard incorrectly

4. The question and the thesis

The question the speaker suggests keeping in mind throughout the talk is this: when you run an AI workload on infrastructure you do not manage, who else has access to what you run. This is the right framing, because it moves the security conversation from the plane of "is the provider protected" to the plane of "what does the party beneath you see".

The thesis: the trust model on which AI infrastructure rests breaks at all layers at the same time, and the threat models in most security teams have not been updated for this. The four layers are then examined in turn, and at each one is shown either active exploitation or a disclosed vulnerability that has not yet become a weapon in wide use.

5. Layer one, code: the fake repository

The first case begins with a repository on Hugging Face that appeared in May 2026 under a name imitating an open OpenAI model. The model card was copied word for word from a legitimate release, and the difference lay in a single file that looked like an ordinary modern model loader. Inside was plausible bait code with no obvious signs of forgery, then a disabling of certificate verification, a decoding of an encoded block, and the download of a script that executed on every machine running Windows where this loader was launched.

What happened next is known from the security vendor's analysis: within roughly eighteen hours the repository became first in the platform's trends, gathered on the order of 244,000 downloads and was removed before most had time to learn of it. The analysis was unambiguous: if this loader had been run, the machine must be considered fully compromised, not examined.

The speaker separately emphasizes that such a reach does not require sophisticated ingenuity. It is enough to repeat an already existing template: imitate a trustworthy release, use a popular platform as the channel, and count on the download being perceived as a mark of quality.

6. The same template in agent ecosystems

The speaker then shows that the model case is not isolated but belongs to a class. In February 2026 an independent audit of a popular agent's skill registry found 341 malicious skills out of 2857, that is about twelve percent of the registry, with some campaigns specifically hunting for cryptocurrency and model training infrastructure.

The conclusion is stated briefly and it holds not only for AI: open ecosystems of skills and packages are a built-in gap in trust. The platform is not a means of control, and the number of downloads is not a security check. The speaker draws a direct parallel with package managers, where this lesson has long been known.

7. Layer two, containers: escape through the toolkit

Turning to containers, the speaker examines a vulnerability disclosed in July 2025 by the company Wiz and given the name NVIDIAScape. This concerns a component that connects containerized workloads to graphics cards, and it is installed almost everywhere that containerized GPU jobs run, including at large cloud providers.

The mechanism is described as elegant and frighteningly simple. A malicious container adds, through a preload variable, a reference to a library it controls, and when the container runtime hook fires, that library is loaded on the host rather than inside the container. From there the attack has root privileges and full control of the machine. By the researchers' estimate, on the order of 35 percent of cloud environments were exposed to the vulnerability, and a few lines in the description of the container build sufficed to launch the attack.

Alongside this, the speaker mentions a second flaw in the same toolkit, disclosed at about the same time and enabling file substitution on the graphics card side. The conclusion he draws from this is more important than the vulnerabilities themselves: a container is not a boundary of isolation that can be relied on alone.

8. Layer three, marketplaces: a different relationship of trust

The speaker calls this part the main reason he came to speak, and explains a difference that is easy to miss. In a traditional cloud an organization has an account, a contract, a support number, a compliance framework and a legal entity on the other side of the transaction that has something to lose. Decentralized compute marketplaces are structured fundamentally differently: they are an exchange of compute capacity between participants, in which the hardware owner registers as a supplier, customers publish jobs, suppliers compete on price, and the match is closed automatically.

The economic rationale is very strong: the shortage of compute is real, and such marketplaces offer access to it at a fraction of the cost of large clouds, so organizations are already using them. The question that is not asked in the process is "who is running the hardware beneath your workload", and the answer in the decentralized model is unknown: the supplier is anonymous or at best pseudonymous, there are no checks, there are no personal contractual obligations to the customer, and the only incentive is the reward for compute time supplied.

9. A case from the third layer: bypassing the deployment owner

Next comes a concrete example of a vulnerability found in May 2024 by the research group ChainLight in the decentralized compute platform Akash Network. The flaw allowed an attacker to impersonate the deployment owner, bypass the access check and execute arbitrary commands on any active instance. That is, to read logs, exfiltrate data, gain access to model weights and interfere with running processes.

The disclosure was responsible, the platform issued a fix quickly, and this is a good outcome. But the speaker asks us to think about what such a vulnerability means specifically in the decentralized context, and he explains the difference precisely. In a traditional cloud a flaw like this is very serious, but whoever uses it must first compromise the platform, and the platform has a security team, monitoring, response and legal liability. In a decentralized marketplace the attacker already owns the hardware beneath your workload. He does not need to break the platform; it is enough for isolation to fail.

10. The scenario end to end

So that all of this does not look like a set of separate vulnerabilities, the speaker assembles a single scenario from beginning to end. A financial organization runs model inference on a decentralized marketplace, because it is substantially cheaper and the budget for compute is under pressure. The team checked all the security elements it knew how to check and packaged the workload into a container.

The operator who received this node uses an unpatched version of the container toolkit and performs an escape. He then spins up his own container alongside, runs the exploit and ends up on the host. After that the model weights, the input data and the results of the work become visible to a party the customer has never met, cannot identify and has no contractual relationship with.

The speaker emphasizes that the scenario is not hypothetical: every element of it is documented. And the blast radius in such a model is wider than in a traditional cloud, and the explanation for this is given through the incentives we have already discussed: a large operator has reasons not to read the data, while an anonymous node has no such reasons.

11. The four risks that arise here

12. The fourth layer, hardware: attacking graphics card memory

The last part of the talk is about something that is not yet exploited at scale, and the speaker states this openly. It concerns an extension of a known class of memory attacks, where frequent accesses to memory cause bit flips in adjacent cells. Here the same technique is applied not to the computer's main memory, but to graphics card memory, and the speaker calls the work by its name.

The mechanism is described as follows. The problem is not the flipped bits themselves, but that an unprivileged compute kernel can, by acting on memory, gain access to arbitrary regions of memory on the card, and from there reach driver vulnerabilities and obtain full privileges on the host. An essential detail: this works even with protection enabled that is supposed to restrict direct device access to the machine's memory.

According to the public materials, the body of attacks is as follows. The first work, which the speaker names, strikes the page tables of graphics card memory: at one vendor their placement turns out to be next to user data, so a flipped bit in the right position redirects the address mapping to the processor's physical memory, after which the card reads and writes to it directly. The second work from the same period goes one level deeper and corrupts page directory entries. The third, from the group that first demonstrated this problem on graphics cards, bypasses the protection mentioned above entirely. The claimed scope of impact is considerable: instead of 8 flipped bits in the early work, here it is on the order of 129 bits per memory bank, and a widely used model, which cloud platforms use, is named as the publicly confirmed vulnerable card.

13. Why this matters specifically for AI infrastructure

The speaker explains the applicability briefly and precisely. The dominant deployment model is shared graphics cards: multi-tenant clusters used by decentralized platforms, by capacity rental services, and by scientific computing environments alike. In such an environment, "unprivileged" does not mean an abstract user, but another tenant on the same hardware.

There are no confirmed cases of exploitation in real attacks as of the time of the talk, and the speaker emphasizes this. But there are two signals that he considers more important than the fact of exploitation itself. First: the research is published, the technique is documented, and the attack surface is the most widespread computing infrastructure in the world. Second: the topic has moved out of academia and into politics. In May 2026 the works appeared at a dedicated security and privacy symposium, and in August, at a security conference, attacks on GPU hardware were for the first time on the agenda of a keynote presented by representatives of a dedicated cybersecurity agency, the FBI, and the White House cyber director.

The conclusion the speaker draws from this layer: hardware is no longer a trusted boundary. The attack surface now lies below the operating system, below the container, and below the driver, and the assumption that silicon is the floor turned out to be wrong.

14. Summary: four layers and four wrong assumptions

15. What is proposed to be done

The speaker's answer rests on a single distinction, and it is the most valuable part of the talk. The solution is not to scan better at one layer, and not to patch faster (although patching faster is always necessary). The solution is to recognize that trust must be earned at every layer, and that any architecture which passes trust down by default stands on a foundation that has already cracked.

The second thesis: independent verification of each layer is needed so that the failure of one layer does not bleed into the others. The speaker emphasizes that this is not a product question but an architecture question, and that the absence of such an architecture means only a matter of time until an incident.

16. What is not proven here

17. Three questions the talk does not address

First: how to verify the lower layers in practice. Independent verification of hardware and driver requires either trusted measurement or the ability to compare the system's behavior against a baseline, and that is a separate engineering task, which the talk names as a requirement but does not work through as a job.

Second: what the incentives of the party that provides this verification look like. The speaker correctly notes that an anonymous operator has no reason not to read the data. But the verification provider also has its own interests, and the analysis offers no answer to the question of who verifies the verifier in the infrastructure layer. This is exactly the same question raised in the talk about agent obligations, as applied to certification.

Third: what to do with already deployed workloads. All the talk's recommendations are architectural, and therefore apply to new projects. For systems already running on someone else's hardware, neither a course of action nor a criterion is offered, whether to stop work urgently or to continue.

18. Numbers and facts on one screen

19. Glossary of the talk

20. Twenty self-check questions

• Why does the speaker call his critique a view from inside the field?
• Why does he divide threats into already exploited and disclosed but not weaponized?
• In the fake repository case, what was a copy and what was a difference?
• Why did the analysis's conclusion prescribe reinstalling the machine rather than verification?
• What is the sense of the phrasing that the model was the delivery method and the compute instance was the target?
• Why does the download count work as an accelerant of the attack rather than as a sign of reliability?
• What share of the skills registry turned out to be malicious, and how does that change the attitude toward such registries?
• Describe the mechanism of a container escape via a runtime hook.
• Why does loading a library on the host mean full control over the node?
• How does the threat model of a capacity marketplace differ from a traditional cloud?
• Why does the absence of a contract with the operator change not only the legal but also the engineering picture?
• What did bypassing the deployment owner check allow?
• Why, in the decentralized model, does the attacker not need to break the platform?
• List the four risks that the speaker names for workloads on someone else's hardware.
• Why is manipulation of outputs harder to detect than theft of the weights?
• Describe the chain of a GPU memory attack from an unprivileged kernel to root privileges.
• Which protection do some of these attacks bypass, and what does that change?
• Why do shared graphics cards make these attacks applicable rather than theoretical?
• What does the requirement to verify each layer independently mean, and what does it lack?
• Name the three questions the talk left open.

21. Where to check the primary sources

• Event and talk: Open Source x Sovereign AI, first day, a block of short talks. The topic in the program reads as "Whose GPU Is This, Anyway?", the speaker is Craig Thayer, founder of DC3 Network.
• The fake repository case: publications by dedicated outlets and analyses by security vendors from May 2026 about a repository imitating an open model, and about the order of magnitude of the downloads.
• The agent skills registry: an audit of February 2026, in which 341 out of 2857 skills were found malicious, with an analysis of the campaigns.
• The vulnerability in a GPU container toolkit: an analysis by a research group from July 2025, a description of the mechanism via a runtime hook, and an estimate of the share of affected cloud environments.
• The decentralized platform: a public analysis of the May 2024 finding about bypassing the deployment owner check and about the fix that was released.
• Graphics card memory attacks: public materials from three research groups, disclosed in April 2026, including descriptions of the chain to root privileges, the behavior of page tables, and the bypass of direct device access protection.
• The topic moving into politics: the keynote program of a security conference in August 2026, with the participation of a dedicated cybersecurity agency, the FBI, and the White House cyber director.

This analysis is based on the transcript of a short talk. Names, proper names, and vulnerability numbers distorted by automatic transcription have been restored from primary sources and marked with a verification status. Not verified: the exact number of the second defect in the container toolkit, and the quantitative comparison of attack surfaces, which the speaker gives as an estimate. The scenario involving a financial organization was assembled by the speaker as an illustration, and not as a recorded incident.