Blackthorn: The Frontier of Confidential AI

Key Takeaways

• In most AI services, the prompts users submit are processed in plaintext inside the provider's trust boundary. Regulation, the value of data, and the actual behavior of enterprises all point to a structural demand for confidential AI. Yet the number of confidential GPUs that can actually be rented today is estimated at roughly 600 to 4,500 worldwide, which is only about 0.04% of the GPUs capable of confidential computing.
• Existing confidential AI architectures place x86 CPU trusted execution environments (TEEs) such as Intel TDX and AMD SEV-SNP at the center of the trust chain. Since 2020, however, these chips have been repeatedly broken by attacks that include key extraction and attestation forgery. Arcium Blackthorn is designed as an architecture that removes the CPU TEE from the trust chain entirely and replaces it with multi-party computation (MPC) that provides malicious security.
• Blackthorn reduces the trust chain to just two elements: the device identity key burned into the silicon of NVIDIA GPUs, and the cryptographic threshold of the Cerberus MXE(Multi-party eXecution Environment). The host CPU serves only as a relay that forwards doubly encrypted ciphertext, and deployment requires nothing more than a software upgrade, with no new hardware. This opens confidential inference to the bare-metal Hopper and Blackwell fleets that neoclouds and enterprises already operate, a pool far larger than the roughly 2,000 confidential GPUs on the market today. GPUs running under virtualization, which still cannot enter confidential computing mode, stay outside this pool.
• Blackthorn still assumes hardware trust in the GPU's confidential computing mode, and its most important remaining task is validation on real hardware. Arcium's long-term roadmap points to purely cryptographic execution built on Manticore, with no hardware trust at all. Until that performance gap closes, Blackthorn is positioned as the real-time confidential AI architecture deployable today with the lowest trust requirements.

0. Every Prompt Handed to an AI Arrives in Plaintext

When you ask a chatbot about your medical checkup results, paste in a company contract, or request a summary of unreleased financial data, what happens to those sentences? The connection is encrypted with TLS in transit, but the moment the data reaches the provider's servers, it is decrypted and processed in plaintext. Depending on its policies and system design, the provider can read and store it, and if the infrastructure is breached, an attacker gains access to the same plaintext. Even where technical controls such as access restrictions or encryption at rest exist, the party operating them is the provider itself. What protects a user's prompt today is ultimately trust in the provider: its terms of service, its policies, and its internal controls.

Source: TechCrunch

And that trust has been broken again and again. In 2023, a single library bug at OpenAI exposed some users' conversation titles and payment details to other users, and in the same year, Samsung Electronics banned the internal use of generative AI after employees entered source code into such tools. In the 2025 lawsuit The New York Times filed against OpenAI went a step further and demonstrated this problem in practice. The court first ordered OpenAI to preserve its logs, including conversations users had deleted, and in late 2025 it ordered the company to hand over a sample of 20 million consumer ChatGPT conversations to the plaintiffs' lawyers. Even by OpenAI's own account, the overwhelming majority of those conversations belonged to users who had nothing to do with The New York Times. OpenAI appealed, but the appeal was denied, and in early 2026 the company complied with the order by turning over de-identified logs. In other words, deleting a conversation only removes it from the user's screen. The plaintext remains on the provider's infrastructure and can be sent over in bulk by a third party anytime, regardless of the user's own will.

Arcium describes this situation as "one of the largest honeypots of personal data in history." It may sound like rhetorical exaggeration, but considering that no system has ever existed where hundreds of millions of users pour their most sensitive questions into a single place, the description is not far off the mark. And Korean readers have already witnessed firsthand how far plaintext accumulated in one place can travel.

Source: Joongang Daily

Most Koreans will remember Iruda, the AI chatbot launched at the end of December 2020. Iruda drew attention with its fresh combination of a persona (a twenty-year-old woman) and an affinity system, along with its natural conversational style, and reached roughly 750,000 users within two weeks. Before long, however, it became the center of a data privacy controversy after it leaked the names, addresses, and bank account numbers of real people in the middle of conversations.

Why did this happen? Scatter Lab, the company behind Iruda, had used 9.4 billion KakaoTalk messages from roughly 600,000 people, collected through its own relationship counseling app, as training material. Sentences that had been sent only to a partner surfaced in conversations with strangers. The service was shut down within three weeks, and the following spring, Korea's Personal Information Protection Commission imposed fines and penalties in the 100 million won range, the first such sanction against an AI developer.

Plaintext accumulated in a service is not dangerous only while it sits in storage. The moment it is used for training, it seeps into the model's weights, and after that, no one can control when or in whose conversation it might resurface.

Arcium's answer begins with an admission: this chain cannot be cut all at once. As Iruda’s case shows, once plaintext has seeped into a model's weights, no technology can recover it. The only point at which intervention is possible, then, is before the data is swallowed, at the very moment it arrives at the service.

Arcium's Blackthorn aims to seal off exactly this point. It builds a confidential inference architecture in which the plaintext of a prompt exists in only two places, the user's device and an isolated region inside the GPU, so that neither the service provider nor the host controlling the infrastructure ever handles anything but ciphertext they cannot open. Plaintext that cannot be read cannot leak even if the provider's infrastructure is breached. And because the provider never obtains the original prompt, the path of collecting that data directly and reusing it for training, as has been common practice, is closed off.

1. Where Confidential Inference Stands Today

1.1 Demand Is Already Structural

Beyond the specific incidents and vulnerabilities mentioned above, problems arising from the submission of sensitive prompts are occurring across society. In its 2024 Data Privacy Benchmark Study, Cisco reported that more than a quarter of organizations had banned the use of generative AI at least temporarily. A 2025 survey of some 48,000 people by KPMG and the University of Melbourne found that about 48% of workers who use AI had entered sensitive company information into public AI tools.

Banning prompts that contain sensitive information, however, remains something people can work around, and such measures do less to eliminate demand than to push it underground. In my view, what enterprises want is not to avoid AI but to have AI they can trust. More precisely, they want AI that processes their data while ensuring that even the company doing the processing cannot see the original content. This kind of technology is generally called confidential inference.

If enterprise behavior forms the lower layer of demand, regulation sits above it. Alongside its data minimization principle, which limits processing to what a given purpose requires, the GDPR explicitly names pseudonymization and encryption as protective measures. Sector-specific rules such as HIPAA and GLBA in the United States, and the SEC's Regulation S-P as amended in 2024, subject every external processor with access to customer data in plaintext to contractual, audit, and breach notification requirements.

Confidential AI does not address these requirements one by one; it resolves them all at once through a single property: the provider never holds the plaintext or a complete decryption key in the first place. Making the data invisible to the provider can satisfy regulatory requirements at the structural level, and by keeping the provider away from the original data, it structurally fulfills part of the technical controls that compliance demands. No law mandates the use of confidential inference, but every requirement points in the direction of the same architecture.

1.2 Yet Confidential AI Is Trapped in a Supply Bottleneck

If demand is this strong, what infrastructure can an enterprise that wants confidential AI actually use right now? To understand the answer, we first need to understand what ingredients confidential inference requires.

The first ingredient is isolation on the GPU side, where the computation takes place. Since the Hopper generation, NVIDIA has supported a GPU-level Confidential Computing (CC) mode. It is implemented by establishing a protected area inside the GPU chip, called the Compute Protected Region (CPR), that cannot be inspected from outside. GPUs from the H100 onward also provide hardware attestation, which verifies that CC mode is enabled on a genuine GPU with a proper firmware configuration.

This alone, however, does not complete a confidential AI system. Someone outside the CPR has to encrypt the data and feed it in, manage the decryption keys, and verify that the GPU is genuine, and whoever performs that role must also be trustworthy. One common approach is to assign the role to the CPU: a Confidential Virtual Machine (CVM) is launched on top of a CPU trusted execution environment (TEE) such as Intel TDX or AMD SEV-SNP, and the GPU is accessed through this CVM. In other words, building a confidential inference system today requires three things.

1. A GPU with CC mode enabled
2. A host CPU that supports a TEE and has it enabled
3. A workflow that bundles the two into a validated product

Note: Whether a GPU can run in CC mode depends not only on its silicon but on how it is operated, and a GPU handed out through a virtualization layer, as most of the installed base is today, cannot run in CC mode as things stand.

The question is how many products actually bring all three ingredients together. The Arcium team surveyed some 80 providers, including hyperscalers, GPU neoclouds, confidential AI specialists, and decentralized compute networks, counting only GPUs on which this configuration is actually enabled and that can be rented or purchased as a product. Cases where CC-capable silicon is sold in normal mode, and the common setup where a GPU is simply attached to a CVM without the GPU's own CC mode, were excluded.

The results clearly revealed the bottleneck in building confidential AI infrastructure. Only about 600 to 4,500 confidential GPUs are available for purchase worldwide, and nearly all of them are Hopper-class units in single-GPU configurations.

Moreover, only two hyperscaler products have reached general availability, Microsoft Azure and Google Cloud, and both limit each virtual machine to a single GPU. These are also the only two clouds NVIDIA officially lists as confidential computing partners. AWS's flagship GPU instances are not confidential VMs, and large GPU neoclouds such as CoreWeave, Lambda, Crusoe, and Nebius operate CC-capable silicon at scale but do not support systems with the host CPU TEE enabled, so they cannot offer confidential AI products at all. Ironically, the largest confidential GPU deployments on the planet, in technical terms, run behind Meta's WhatsApp Private Compute and Apple's Private Cloud Compute, but both are internal infrastructure and are not sold to anyone.

In short, millions of GPUs are built on CC-capable silicon, yet the confidential AI systems that can actually be bought and used come to roughly 2,000 GPUs. Two filters stand between those numbers. The larger one is virtualization: most of the installed base is operated through a hypervisor, and those GPUs cannot run in CC mode regardless of what host sits next to them. The smaller one is the host: among the GPUs that could run in CC mode, the conventional architecture also demands a CPU TEE and a certified CVM product, and this is what keeps the neoclouds' bare-metal fleets off the market. As chapter 4 will show, Blackthorn removes only the second filter. Converting this into compute capacity makes the gap even more tangible. The confidential AI compute available for purchase today amounts to about 2 EFLOPS at peak performance. Given that a single frontier training cluster of 100,000 H100s (xAI's Colossus) delivers about 100 EFLOPS, all the confidential AI compute on Earth combined comes to roughly 2% of one frontier cluster.

And even this scarce supply is constrained by the trust bottleneck examined below.

2. The Trust Bottleneck: x86 TEEs That Keep Getting Broken

2.1 The Heart of the Existing Confidential AI Stack: Vulnerabilities in CVMs and x86 TEEs

As described above, most commercial confidential AI deployments today follow a common pattern. A CVM running on Intel TDX or AMD SEV-SNP sits on the GPU host, and an H100 in confidential computing mode is attached to that CVM. The CVM is the entity that verifies the GPU attestation chain, the entity that handles decrypted model weights and inference activations, and the recipient to which an external key broker hands the application keys. In other words, the CVM, and thus the x86 CPU TEE, is the heart of the trust chain in a confidential AI system.

The problem is that vulnerabilities in CPU TEEs have been discovered continuously. The AMD SEV family has been under attack since SEVurity in 2020, and Intel TDX has been targeted at top-tier security conferences ever since its launch, with the 2023 joint security audit with Google Project Zero serving as a starting point.

The attack vectors are highly varied. Research has demonstrated ciphertext side channels that exploit the deterministic nature of memory encryption (SEVurity 2020, CipherLeaks 2021, Heracles 2025), fault injection and corruption of architectural state (CacheWarp 2024, WeSee 2024, StackWarp 2026), single-stepping and microarchitectural timing channels (TDXdown 2024, CounterSEVeillance 2025), collapse of the integrity foundation through memory aliasing (BadRAM 2025, RMPocalypse 2025), and even forgery of the attestation that serves as the root of trust. Notably, MilanLaunchy + BadFuse in May 2026 was a software-only attack requiring no physical access, and it showed that valid SEV-SNP attestations could be forged for any firmware version.

Many of these were patched in subsequent generations. But the pattern itself, in which a new vulnerability along a new axis appears within one to two years even in patched versions, has continued unbroken for six years, and the vendors have declared that some categories will not be fixed at all. At the top of this list is tee.fail, disclosed in October 2025, which shattered the assumption that breaking a TEE requires substantial resources.

Source: tee.fail

The idea behind tee.fail is simple: insert an eavesdropping device (an interposer) on the DDR5 bus between the CPU and memory, and record the memory traffic as it passes. The TEE does encrypt memory, of course, but the fatal flaw is that the memory encryption used by Intel and AMD is deterministic. The tee.fail researchers showed that if you write 0, then 1, then 0 again to a TDX machine, the ciphertext of the first and third writes matches exactly. Even without reading the contents, one can tell that the two are identical, and by building a timing attack on this fact, the researchers recovered attestation keys even from encrypted code.

What makes this attack so threatening is less its sophistication than its low barrier to entry.

• Cost: The device can be built for under $1,000 from off-the-shelf parts available online, and the paper even publishes the circuit diagram.
• Portability: The researchers also built a portable version that fits in a 17-inch briefcase. The attack works with the case closed, the case fits under an airplane seat. Side-channel attacks on TEEs have traditionally assumed a "man with a Glock" model, in which the attacker has physical access to the deployed hardware, and the smaller the equipment an attack requires, the more realistic that scenario becomes. It means the scenario of an attacker sneaking into a data center is no joke.
• Results: Intel's Provisioning Certification Key (PCK) was extracted fully automatically from observing a single signing operation, and a TDX quote forged with this key passed Intel's own verification library at the highest trust level, UpToDate. This was a quote whose measurement fields were filled with 0x1337..., something genuine hardware could never produce. The researchers even run an "Attestation as a Service" social media bot that issues forged attestations. On the AMD side, they likewise extracted a constant-time OpenSSL ECDSA private key from SEV-SNP with the latest defense, Ciphertext Hiding, turned on.
• Real-world impact: Against a live TDX deployment of Ethereum's BuilderNet, which produces blocks worth millions of dollars each month, they demonstrated that a malicious operator holding the attestation key could decrypt confidential order flow and access the wallet used for validator payments.

Source: AMD

The most important part is how the vendors responded. Intel and AMD have treated tee.fail, along with other vulnerabilities requiring physical access to the target such as Battering RAM and WireTap, as out of scope, offering no firmware mitigation and advising only that the physical security of servers be ensured separately (Intel security advisory, AMD security bulletin). Current x86 TEEs thus contain a structural gap that no patch can be expected to close and that must simply be accepted.

Source: @v12sec

And this accumulation of vulnerabilities is not confined to the silicon itself. In late August 2026, V12, a security auditing agent, had broken into the Intel SGX enclave running Signal's Contact Discovery Service (CDSI). CDSI processes encrypted lookups inside an attested SGX enclave, allowing users to learn which of their contacts use Signal without exposing their address book even to Signal's own servers. It is enabled by default on both the Android and iOS apps, and the address book is transmitted every 48 hours. In using a TEE to deliver the promise that not even the service provider can see the data, it has exactly the same structure as what confidential AI seeks to build.

What is notable is that what this attack broke was not the hardware. Memory encryption and attestation both worked as designed. What was breached was Signal's code running inside the enclave. The host cannot read the contents of the isolated region, but it legitimately holds the authority to invoke the enclave and to pause or resume its execution. With nothing more than this legitimate control, V12 exploited two flaws in the code and extracted the enclave's secret key, and a host holding that key can impersonate the enclave and decrypt every user lookup. Both vulnerabilities were verified in the same environment Signal actually operates in, and both were reported and fixed before disclosure. The lesson that remains, however, is that attestation only proves which code is running; it cannot prove that the code is safe in the face of a malicious host. And the fact that it was V12, an autonomous AI agent, that found these bugs suggests that the interval at which TEE vulnerabilities are discovered may grow even shorter.

2.2 The Collapse of Trust Spreads to the GPU, and the Two Stacks Part Ways

So far, this has been a story about CPUs. But the tee.fail paper went a step further, showing that the collapse of the x86 TEE also brings down the guarantees of NVIDIA GPU confidential computing.

The mechanism works as follows. An NVIDIA CC attestation report only proves that "this GPU is genuine and its firmware is intact"; there is no binding that ties the report to a specific CVM or a specific CPU. Since the CVM is the verifier, the design holds only on the premise that the CVM is honest. An attacker who can forge CPU attestation can therefore "borrow" an attestation issued by a GPU somewhere else entirely and submit it. In the researchers' words, the attacker does not even need to own a GPU. The user believes their LLM conversation is protected inside the GPU vault, while the actual workload runs in plaintext. The researchers demonstrated this against a real deployment of Phala's dstack SDK: a malicious provider ran the workload on an ordinary VM, forged every attestation, and relayed attestations obtained from a third party's spot GPU to pretend it owned a GPU it did not.

This is exactly where the two stacks part ways. In the current confidential AI stack (CPU TEE + NVIDIA CC), trust in the GPU's CC region depends on the security of the CPU TEE that verifies it. Once the CPU TEE is breached, the GPU's confidential region becomes meaningless without ever being attacked directly. Blackthorn's stack (MPC + NVIDIA CC), by contrast, does not make GPU CC itself more secure; its distinction lies in separating the trust structure so that the guarantees of GPU CC do not depend on the security of any particular CPU TEE. It uses the same GPU and the same attestation chain, but the party receiving that attestation is different.

These vulnerabilities do not make TEEs an "unusable technology." Across successive versions, TEEs have steadily narrowed their attack surface. The problem is that every newly disclosed attack demands redesign and re-auditing, that even this cannot be expected for the axes vendors have declared out of scope, and that from the customer's perspective, this remains a standing risk. Would it not be a better option to start from an architecture in which the TEE is not part of the trust chain in the first place?

Blackthorn is precisely the answer to that option. Arcium is a team that, going back to its blockchain work, has chosen MPC over TEEs because of the burden of trusting hardware manufacturers and the track record of side-channel attacks on TEEs, and Blackthorn extends that concern to AI inference. The next chapter examines how Arcium removed the CPU from the trust chain and what it put in its place.

3. Arcium Blackthorn: Replacing the CPU TEE with Mathematics

3.1 Blackthorn's Structure: The User, the GPU, the MXE, and the Untrusted Host

The name Blackthorn comes from the sloe (Prunus spinosa), a thorny shrub that has been planted in Europe for thousands of years as hedging around homes and livestock. Unlike grafted or parasitic species, the blackthorn grows on its own in poor soil, without a host. Arcium chose the name because its confidential AI architecture likewise stands on its own, without a host-side TEE. How, then, can this be achieved?

The purest approach would be to trust no hardware at all, the CPU included, and to run the entire inference computation in encrypted form using multiparty computation. With current technology, however, this is roughly 100 to 1,000 times slower than plaintext inference. That is far too slow for any real-time service, so a compromise that borrows the power of hardware somewhere is unavoidable. The question then becomes what to entrust to cryptography and what to entrust to hardware.

Arcium drew the line based on the nature of the computation. The heavy, frequent inference computation itself runs inside the GPU's isolated region, while small, infrequent, or specialized operations such as key management and trust distribution are handed to MPC. From deployment through session termination, Blackthorn places no CPU TEE at any stage.

Blackthorn is not a system that performs the inference computation itself with MPC. Inference runs in plaintext inside the GPU's confidential region, and MPC handles the small operations of key management and trust distribution.

As a result of this division of labor, Blackthorn has a structure made up of the following four participants.

1. User device: One of the two places where the prompt exists in plaintext. At the start of a session, it establishes an encryption key directly with the inference engine inside the GPU.
2. GPU and its Compute Protected Region: The other place where plaintext exists. bLLM-Engine, an inference engine forked from vLLM, resides here and runs the entire token generation loop.
3. MXE (Multiparty eXecution Environment): Arcium's multiparty computation environment. From across the network, it conducts the key exchange with the GPU on the system's behalf and authorizes sessions. It handles every key only as shares that no single party can reconstruct.
4. Host CPU: A participant granted no trust, serving only as a relay that moves ciphertext and as a scheduler.

In this structure, the user must trust two things. The first is the GPU's isolated region: the user must trust the integrity of NVIDIA's device identity key, which is burned into the silicon when the GPU is manufactured. The second is Arcium's MXE, which requires trust in the security of the multiparty computation mechanism that handles the key exchange with the GPU. Blackthorn's structure still has parts the user must trust, but trust in the GPU's isolated region is a dependency that existing x86 TEE-based architectures carry as well. What Blackthorn adds in place of the CPU TEE is the MXE as a new object of trust, a point I will return to in a later section.

The sections that follow examine the role each of Blackthorn's participants plays and the trust structure among them.

3.2 The User Device: Where the Plaintext Begins

When starting a session, each user establishes a key directly with the bLLM engine inside the GPU's isolated region. The MXE issues a threshold-signed token that authorizes this exchange, but it does not learn the session key itself, and the host relays only public values.

This session key creates what will be referred to throughout as the "inner envelope." The prompt is encrypted with this key before it leaves the user's device, and the response is decrypted only after it arrives back. From the user's perspective, then, Blackthorn is an end-to-end encrypted channel between the user and the GPU's isolated region, and no intermediary along the way, not even the service operator, can open its contents.

3.3 The GPU and the CPR: The Only Server-Side Space Where Plaintext Is Allowed

NVIDIA GPUs from the Hopper generation onward can create a Compute Protected Region (CPR) inside the chip that cannot be inspected from outside, and they provide hardware attestation proving that the chip is a genuine NVIDIA part and that the region is properly protected.

Residing in this isolated region is bLLM-Engine. Blackthorn forked vLLM, the industry-standard serving engine, splitting it along the trust boundary into two parts: bLLM and bLLM-Host. In bLLM, every component that touches plaintext, including the tokenizer, the forward pass, and the sampler, runs continuously inside the CPR as a single CUDA application. The autoregressive loop that generates tokens one at a time runs entirely within this boundary, and neither the host nor the MXE takes part in it.

Blackthorn goes further, moving into the isolated region not only the plaintext itself but also derived values that correlate with it.

Suppose several users of the same service start their conversations with the same system prompt. For efficiency, the GPU uses prefix caching to store the overlapping portion only once and share it across sessions. As a result, two sessions with overlapping prompts point to literally the same memory page numbers. A page number by itself is just an integer and contains not a single byte of content. But if the host holds the page number lists for multiple sessions, it can learn that "these users are using overlapping prompts" simply by comparing the lists side by side, without ever seeing the contents. A seemingly harmless number is in fact leaking information. This is why Blackthorn moves the entire page number management table into the isolated region as well.

At the same time, the prefix caching feature itself is preserved, so workloads with heavy system prompts retain the same throughput gains as vLLM. The engine binary's hash is verified when a session is established and remains fixed until the session ends; replacing it requires reinitializing the entire isolated region.

3.4 The MXE: A Distributed Key Management Mechanism That Replaces the Host

The MXE is the MPC execution environment developed by Arcium, and it is the participant that takes the seat once occupied by the trusted host in the conventional structure. It is a multiparty computation quorum in which multiple parties split a secret and compute on it together, conducting the key exchange with the GPU from across the network and authorizing sessions. What the MXE sees, however, is only shares and ciphertext. It handles every key only as shares that no single party can reconstruct. It opens and closes the outer envelope of the data, but what lies inside is still the ciphertext of the inner envelope, so it never sees the original prompt or response.

This section looks in turn at the security model underpinning the MXE (3.4.1), how it replaces the host's key exchange role (3.4.2), and why that replacement preserves real-time speed (3.4.3).

3.4.1 Cerberus

Source: Arcium

The MXE runs Cerberus, which has the strongest security model in the Arcium protocol stack. The strength of this model becomes clear once you understand the dilemma Cerberus was designed to solve.

Most MPC protocols rely on an honest majority assumption, meaning that more than half of the participants follow the protocol faithfully. This is a reasonable assumption in permissioned settings where participants' identities are verified. But on public blockchains like Ethereum and Solana, that is, in permissionless settings where the node operators are unknown, there is no way to guarantee that some anonymous actor has not seized a majority.

Dishonest majority protocols solve this problem. Because the secret is split into shares across n parties and can be reconstructed only when all of them are combined, the original remains hidden even if n-1 parties collude maliciously, and confidentiality holds as long as a single honest party remains. But this came at a price. A single malicious participant could cause the entire computation to fail simply by going offline or deliberately sending incorrect data, and since there was no way to tell who was responsible, no punishment was possible. In other words, these protocols were defenseless against denial-of-service (DoS) attacks.

Cerberus was developed to address this dilemma. It is the first production MPC protocol to provide identifiable abort security, attaching a message authentication code (MAC) to every data share on top of the BDOZ protocol. If a node submits a tampered share, it is detected immediately and the computation halts, so a corrupted result can never be produced in the first place. In short, under Cerberus, as long as a single honest party remains, the outcome is either a correct result or a detectable abort, never the silent acceptance of a wrong result.

Note: For performance reasons, Blackthorn's first version runs Cerberus in honest-majority mode.

3.4.2 Remote SPDM: Multiparty Computation Takes the Place of the Trusted Host

To see how replacing the trusted host with MPC actually works, we need to look briefly at how NVIDIA's GPU confidential mode operates. When the GPU's confidential computing mode is turned on, the GPU and the host jointly establish an encryption key through a standardized procedure (SPDM, Security Protocol and Data Model). From the resulting master key, channel keys are derived that protect all data crossing the boundary of the isolated region.

The key element here is the GPU's counterpart in SPDM, the role known as the Requester. In a typical deployment, this role is performed by software running on the host, which means the host ends up holding every session key in plaintext. That is a sound structure as long as the host is trusted, but Blackthorn is premised on not trusting the host, so this structure cannot stand.

Remote SPDM, a core component of Blackthorn, is a protocol that lets the MXE, across the network, perform this Requester role. Just as a threshold signature wallet produces a valid signature from individual key shares without ever assembling the private key anywhere, the parties of the MXE hold every secret value only as shares and compute locally. This covers everything from the random values used in the key exchange to the master secret and the channel keys. Thanks to the linearity of computation on elliptic curves, the same property that makes threshold wallets possible, each participant can compute its own share of the shared secret locally using its own key share. At no point in this process does any party reconstruct the full key; the complete key can only come together inside the GPU chip. Just as the private key never exists in whole anywhere in the signing process, this key never exists in whole anywhere in the MXE, and the host sitting next to the GPU receives the key at no stage.

Identifiable abort serves as the accountability mechanism in this flow. A participant that deviates during one-time operations such as key establishment or authorization signing is identified along with signed evidence and becomes subject to expulsion and onchain slashing.

In addition, every Remote SPDM establishment leaves behind an audit receipt in which the MXE threshold-signs the GPU attestation and the entire key exchange transcript. Users and external auditors can then verify the legitimacy of each key establishment event after the fact using only the MXE's public verification key.

3.4.3 Audit Receipts

Every key establishment event in Blackthorn leaves behind a verifiable receipt. Each time Remote SPDM completes, the MXE issues an audit receipt that threshold-signs the session's full transcript: the attestation signed with the GPU's burned-in key, the firmware measurements, both sides' Diffie-Hellman public points and one-time nonces, and a timestamp. This receipt is delivered to the user, and with only the MXE's public verification key, the user or any third-party auditor can independently confirm after the fact that "the key for this session was established with a genuine GPU through the proper procedure."

The same principle applies at the cluster level. The MXE collects the attestation of each GPU in a cluster and issues a threshold-signed cluster manifest, and any GPU whose firmware has been rolled back or whose attestation is inconsistent is excluded along with a signed rejection record. In conventional CVM designs, such decisions remained only in the operator's internal logs, with no surface for outsiders to inspect. In Blackthorn, every trust decision is left as a signed artifact verifiable with a public key. Taken together with the signed evidence transcripts of identifiable abort and onchain slashing described earlier, Blackthorn amounts to a structure that transplants the long-standing crypto principle of "don't trust, verify" into the key management layer.

Of course, what these receipts prove is the legitimacy of the key establishment procedure, not which model generated which response inside the GPU. This limitation is revisited in 5.3.

3.5 The Host CPU: An Untrusted Relay

The last participant is the host CPU, which sits right next to the GPU yet is granted no trust at all. Blackthorn does not remove the CPU from the system (nor could it); instead, it chose to keep the CPU working as before while simply never giving it the keys.

The component that assigns this work is bLLM-Host, the other half of bLLM. bLLM-Host carries over vLLM's control plane almost unchanged, the part that serves as the front desk (the API server, request handling, and the batching scheduler), but instead of raw data it deals only with opaque session IDs, blobs of ciphertext, and per-session aggregate figures. Thanks to the isolation of derived values described in 3.3, even these numbers used for scheduling are filtered so that they carry no correlation with the plaintext.

In sum, all the host ever sees is doubly encrypted ciphertext, session metadata, and aggregate figures for scheduling. Even if the host is completely compromised and every byte of its memory is recorded, all the attacker obtains is encrypted data that cannot be opened.

In CVM-based designs, the user's connection terminated at the CVM, which saw the original prompt before passing it to the GPU. Host-side software was the heart of the trust chain, which is precisely why the attacks on TEEs discussed earlier were so devastating. In Blackthorn, the host occupying that same position is nothing more than a relay that moves ciphertext bytes and a scheduler.

3.6 The Prompt's Journey and the Threat Model

Let us now trace the full journey a prompt takes among the four components.

1. When the GPU boots into confidential computing mode, the MXE remotely takes over the role of key exchange counterpart normally played by the host. From this point on, the channel key protecting all data that crosses the GPU boundary exists in complete form only inside the GPU and only as shares in the MXE.
2. The user establishes a session key directly with the bLLM engine inside the CPR. The MXE merely authorizes this exchange with a signature and does not learn the session key.
3. The prompt travels in two layers of envelopes. The inner envelope is session key encryption that only the user and the CPR can open, and the outer envelope is SPDM channel encryption handled only by the MXE shares and the GPU. The host carries this double envelope but can open neither layer, and the MXE likewise does not hold the inner envelope's session key.
4. Tokens are generated from the prompt decrypted inside the CPR, and the response returns to the user along the same path in reverse.

By analogy, it is like placing a letter (the user's prompt) in an envelope, then placing that envelope inside a larger one before mailing it. At no stage of this entire journey do the plaintext or a complete key exist outside the user's device and the Compute Protected Region.

To summarize briefly for clarity, Blackthorn's threat model and trust assumptions are as follows.

• Threat model: The attacker has full control of the host CPU and its operating system, eavesdrops on every network segment, and has corrupted up to n-1 of the MXE's n parties.
• Protected assets: The confidentiality of prompts, the responses to them, and model weights
• Trust assumption 1 (hardware trust): The NVIDIA GPU's CC mode works as designed
• Trust assumption 2 (protocol trust): At least one honest party remains in the MXE, and the MXE works as designed

3.7 tee.fail vs. Blackthorn

tee.fail had three attack vectors against the existing confidential AI stack: reading host memory, forging CPU attestation, and borrowing GPU attestation. Aiming these three vectors at the Blackthorn stack yields the results below.

To elaborate on false GPU attestation: in Remote SPDM, what the GPU signs with its burned-in key is not the general statement "I am a genuine GPU" but the transcript of the entire current key exchange, including the Diffie-Hellman public point and one-time nonce the MXE has just generated in share form. Because the attestation is tied to the key exchange itself, a false attestation report is rejected immediately on the grounds that the exchange values it contains differ from those of the current key exchange.

That concludes the description of the architecture. The next chapter looks at what level of performance Blackthorn delivers compared with the existing confidential AI stack, and which markets it opens up.

4. Real-Time Confidential Inference with Blackthorn

4.1 Performance: The Price Tag of Confidentiality

Start with the cost of GPU computation itself. According to the benchmark study cited in the whitepaper, the overhead of NVIDIA's confidential computing mode is about 7%, so on H100-class hardware, a forward pass of a 70B model is expected to take 15 to 25 ms per token, or 30 to 60 tokens per second for a single stream. The encryption cost at the boundary is added on top of this, and as noted earlier, the MXE's MPC-AES adds less than a microsecond of overhead per token. The architecture's performance claim, then, is that it has held the marginal cost of confidentiality down to the single-digit overhead of confidential computing mode itself, and Blackthorn is designed to support even trillion-parameter Mixture of Experts (MoE) models at production throughput.

The one-time costs are also worth laying out. Remote SPDM at GPU initialization is estimated at 1 to 2 seconds, and the authorization signature per conversation session at 50 to 200 ms. The heaviest cost is loading the model weights, because in confidential mode there is no plaintext path into the isolated region at all, so even public weights must travel through MPC-AES. At 12 million blocks per second, Blackthorn takes about 3 minutes for a 70B-class model (roughly 35 GB), about 30 minutes for a 671B MoE model (roughly 335 GB), and about 45 minutes for a 1T-class model (roughly 500 GB). This, however, is a cost paid only once per session and amortized over a session lifetime that runs from hours to days.

For proprietary models, one more layer is added: transciphering, in which the MXE stores the model owner's encryption key as shares and re-encrypts the weights at load time while still in share form. This allows even proprietary model weights to reach the isolated region without ever being exposed to the infrastructure operator.

4.2 Supply: Removing the Filter

Blackthorn's only structural requirement is a GPU that supports confidential computing mode; it needs neither a host CPU TEE nor a certified CVM product. With the second of the two filters seen in 1.2 removed, the pool of candidates for confidential inference expands from today's roughly 2,000 GPUs to the bare-metal Hopper and Blackwell fleets that neoclouds and enterprises already operate. And this expansion can be achieved with a software upgrade alone, not new silicon. The first filter stays in place, however: GPUs operated under virtualization still cannot enter CC mode.

4.3 Trust at the GPU Cluster Level

Serving frontier-class models requires clusters of multiple GPUs, so the design at the cluster layer also deserves attention. Arcium's position is that Blackthorn's contribution at the cluster layer is not a throughput advantage but a trust topology. In other words, it does not make things faster; it makes deployments possible that were previously impossible.

On the Hopper generation, two modes are offered. Within an NVLink-connected node, the MXE uses attestation to form a trust group in which GPU-to-GPU traffic flows in plaintext, just as in NVIDIA's existing approach, but remains invisible to the host. Throughput here is the same full NVLink speed as in CVM-based clusters (Hopper has no encrypted NVLink to begin with, so this is true of any design). Configurations without NVLink are noticeably slower because traffic must pass through the host, but in exchange they enable topologies that CVM designs could never reach at the confidentiality layer, namely clusters spanning multiple data centers and edge deployments.

One caveat should be added in fairness to this account of Hopper clusters. Whether the full NVLink speed mode described above actually holds depends on two behaviors of NVIDIA's closed GPU firmware that have not yet been verified: whether the GPU accepts a remote Requester rather than a CVM, and whether the trust group's firewall is enforced on the basis of attestation. These are among the items for validation discussed in chapter 5.

The picture changes with the Blackwell generation. Hardware-level encrypted NVLink is added, so GPU-to-GPU traffic is encrypted at line rate, and analysis of the open-source driver has confirmed that the MXE can provision those link keys remotely. Multi-GPU confidentiality that is cryptographic in the true sense can therefore be completed on Blackwell.

What sets a Blackthorn cluster apart from a CVM-based one is how trust is arranged. Multiple tenants can share a single cluster while remaining cryptographically isolated, without replicating CVMs. A geographically distributed MXE makes a single cluster spanning several data centers possible. Adding and removing a GPU becomes as light as establishing and closing a single session. And a configuration in which multiple mutually distrusting organizations, such as the model owner, the operator, and a user representative, jointly operate the MXE becomes workable. By the whitepaper's estimate, this structure brings some 600,000 to 1.2 million NVLink baseboards newly within reach.

4.4 Newly Opened Markets

The clearest way to see which markets Blackthorn actually opens is to look at each deployment type.

• The bare-metal GPU rental market: This is the most direct beneficiary. As explained earlier, the large neoclouds operate CC-capable silicon but have been unable to sell confidential products for lack of CVM infrastructure. Under Blackthorn, a GPU rented on an ordinary Linux host can serve as a confidential inference platform as is.
• Sovereign AI: Jurisdictions subject to US x86 export controls, or those that require domestic control over CPUs, often cannot procure TDX or SEV-SNP hardware but can still obtain NVIDIA GPUs through licensed channels. Because Blackthorn works regardless of whether the host is ARM, RISC-V, or domestically produced silicon, it opens a path to operating frontier AI without trusting the microcode of US x86 vendors. By the same logic, it opens a path to deploying confidential inference in edge environments where no CPU TEE exists, such as robotics and industrial IoT.
• Model serving among mutually distrusting organizations: In a three-party arrangement where the model owner wants to protect its weights, the operator its infrastructure, and the user their data, Blackthorn distributes the model keys and cluster keys as MXE shares, creating a configuration in which no single party holds another's secrets. This means Blackthorn can be applied in forms such as model marketplaces, private RAG across institutions, and model serving among organizations that do not trust one another.

As a product, Blackthorn is to be offered in three forms: a dedicated Blackthorn unit consisting of an HGX server with eight H100, H200, or B200 GPUs running the bLLM runtime; an encrypted model API that serves major open-weight models from DeepSeek, Meta, Mistral, and others with per-token billing; and an option to install bLLM on Hopper or Blackwell hardware a customer already owns, converting its own GPUs into confidential infrastructure. Alongside the whitepaper's release, Arcium has signaled that it will announce the first real-world pilot built on this foundation.

4.5 The First Deployment: Charité and 20,000 Transplant Patients

Alongside the whitepaper, Arcium announced that Blackthorn's first production partner is Charité – Universitätsmedizin Berlin, Europe's largest university hospital and the hospital with more Nobel Prizes in medicine than any other in the world. In the first phase, already underway, researchers from Charité and the German Heart Center of the Charité (DHZC) are using Blackthorn to securely process data from more than 20,000 heart and lung transplant patients in support of four medical research papers. The second phase is to develop a commercial product on Arcium's network for encrypted training, inference, and data science across multiple hospitals.

Healthcare data is where the two layers of demand, enterprise caution and regulation, press hardest at once. Plus, the cross-hospital second phase is the "mutually distrusting organizations" scenario in its purest form: each hospital trusts neither the others nor the operator, yet all want to compute on the union of their data. In Blackthorn, the participating hospitals can jointly operate the MXE so that no single institution, Arcium included, ever holds a complete key to another hospital's patients.

5. Discussions

The Blackthorn whitepaper devotes a separate section to its unverified assumptions and known gaps. Sections 5.1 through 5.3 of this chapter organize the limitations the whitepaper itself acknowledges, with my own perspective added.

5.1 Concentration of Hardware Trust

Blackthorn has removed the need to trust x86 TEEs, but it still relies on trust in the GPU's confidential mode. Arcium itself acknowledges that the logic of accumulating vulnerabilities it applied to x86 TEEs could, in principle, apply to GPU confidential computing as well over a long enough time horizon.

The core enforcement mechanisms of GPU confidential mode, such as memory access management and the firewall between GPUs, reside in closed-source GPU firmware beyond the reach of external audit. In the sense that it involves trusting a vendor's closed code that cannot be verified, I do not think this differs greatly in character from trusting the internal code of x86. Moreover, NVIDIA is currently the only vendor shipping data-center-grade confidential computing GPUs, so in a scenario where NVIDIA's confidential computing mode is broken, there is no alternative. That is a clear weakness.

Arcium's ultimate answer to this is its roadmap toward purely cryptographic execution based on Manticore, with no hardware root of trust at all, which I will address in the final chapter.

5.2 What Blackthorn Protects and What It Does Not

Knowing what Blackthorn does not protect is as important as knowing what it does. Conveniently, there is a good yardstick for this. Measuring the incidents listed at the beginning of this article against the threat model in 3.6 splits them neatly into two groups.

The incidents Blackthorn would have prevented are those where plaintext on the provider's side was the problem. For example, source code entered by employees remaining in readable form on the provider's servers is structurally impossible under Blackthorn. Because no plaintext exists outside the GPU's isolated region, where an entire internal database was exposed, would be nothing but ciphertext that cannot be opened. Furthermore, if the inference layer is designed not to store plaintext, a structure becomes possible in which no plaintext conversation logs exist for an operator to hand over under a preservation order. This holds, however, only on the premise that not just the inference layer but also the application layer, including conversation history storage, follows the principle of keeping plaintext solely in the user's local environment.

Conversely, the incidents it would not have prevented are those where the plaintext was somewhere else to begin with. The KakaoTalk messages Iruda spat out were plaintext that had seeped into the model weights at training time, not at inference time, and Blackthorn's threat model covers only the confidentiality of inference.

With this distinction as a foundation, three further points are worth noting.

First, what Blackthorn protects is content, not metadata. The host scheduler can observe the existence of sessions, request frequency, ciphertext sizes, and batch composition. In addition, prefix cache hits produce differences in processing time, leaving a kind of timing signal. This means that even without knowing the contents of a conversation, who uses the AI, when, how often, and at what length can be revealed. Strong guarantees against traffic analysis would require combining a separate layer, such as a mixnet or traffic padding, in front of the system, which adds its own overhead.

Second, what the whitepaper proves is confidentiality, not correctness. Users actually worry about two things: whether their prompt leaks, and whether the answer they receive really came from the stated model. Blackthorn's core theorem answers the first question but does not address the second. The scenario in which a malicious operator quietly biases responses or secretly swaps in a different model, all without breaking confidentiality, is out of scope. The computational correctness that Cerberus was said to guarantee in 3.4.1 applies only to the MPC portion, that is, key management and encryption and decryption; which model generated which response inside the GPU is a separate matter. Since the purpose of confidential inference is not to guarantee the integrity of results, it may be unreasonable to demand this, but I believe users need to be aware of it nonetheless.

Finally, there is the question of scope. The confidentiality Blackthorn addresses is limited to the inference process, and the confidentiality of training, agent tool execution, and orchestration is deferred to separate specifications. Given that AI usage is shifting increasingly toward agents, I expect that even if a prompt is perfectly protected inside the isolated region, control becomes difficult once the search queries or tool calls the model generates leave for the orchestration layer on the host side.

6. Looking Ahead

6.1 Significance as a New Use Case for MPC

In the crypto ecosystem, the main use of MPC to date has been key management. Threshold signature wallets are the prime example, and Arcium itself has used MPC onchain as the foundation for applications that handle encrypted shared state, such as sealed-bid auctions and dark pools. What is new about Blackthorn is the expansion of its purpose.

If this approach proves valid in a real environment, its implications may not be confined to AI. Other infrastructure that keeps a TEE in its trust chain, such as TEE-based coprocessors and certain bridge and rollup designs, could see the same logic applied and be replaced with Arcium's infrastructure. Blackthorn is the first experiment in using MPC as a substitute for hardware trust, and its success or failure will set a precedent that shapes the direction of designs that follow.

6.2 The Threshold for Adoption

The confidential AI market is not empty. Specialist providers such as Phala, Tinfoil, and Edgeless already sell products built on the CVM pattern. Blackthorn's advantage materializes only when the argument that it has removed the repeatedly broken x86 TEE from the trust chain is reflected in actual purchasing decisions. How much of a price premium this difference commands in the security reviews of regulated industries remains to be seen in the market.

There is also risk from the opposite direction. Part of Blackthorn's differentiation rests on current gaps in the NVIDIA ecosystem, namely attestation that does not measure the loaded kernel and a multi-GPU confidential mode tied to CVMs. If NVIDIA fills these gaps directly, or if hyperscalers commercialize confidential products in earnest and drive prices down, part of the gap could erode. That said, trust topology properties such as the multiparty distribution of key custody, clusters spanning data centers, and joint operation by mutually distrusting organizations are not something a hardware vendor can provide on its own. In the long run, therefore, multiparty key management and trust topology, which hardware vendors have difficulty addressing directly, are likely to remain the differentiating factors.

6.3 Manticore: Toward Zero Hardware Trust

Blackthorn is not the final destination. Arcium itself defines it as an intermediate stage. The ultimate goal is a purely cryptographic execution setup with no hardware root of trust whatsoever, in which transformer inference itself runs inside a Manticore-based MPC protocol. As noted at the start of chapter 3, the performance gap along that path is currently about three orders of magnitude relative to plaintext, and closing it will take years of progress in both algorithms and hardware acceleration. Until that gap closes, Blackthorn offers one practical path to pursuing real-time confidential inference and low trust assumptions at the same time on the GPUs shipping today.

Just as the garden of applications on Arcium did onchain, Blackthorn's value will ultimately be proven by the workloads that actually run on it. AI in which confidentiality is the default rather than a premium add-on: it is now time to watch whether that proposition holds in the market.