GPU-less, Trust-less, Limit-less: Reimagining the Confidential AI Cloud

How do you run a model on sensitive data without handing that data over? And how do you let customers use a proprietary model without surrendering its weights? These requirements meet at the same execution boundary: someone must perform the computation, but neither party wants the operator—or the other participant—to gain unrestricted access. Collaboration becomes harder when autonomous agents interact and make decisions dynamically. Mike Bursell introduces Super Protocol as infrastructure for running, scaling, and monetizing AI under those constraints.

Encryption at rest and in transit leaves another phase to protect: data in use. Training, fine-tuning, and inference all require computations over data and model parameters. Confidential computing addresses exposure during that processing phase.

A trusted execution environment, or TEE, supplies hardware-enforced isolation. The presentation names Intel TDX, AMD SEV-SNP, and NVIDIA GPU TEEs. Instructions built into the processor establish a confidential environment whose protected memory is isolated from the host operating system, hypervisor, and hardware operator. The intended boundary therefore extends beyond ordinary application permissions: administering the host should not grant access to the workload’s plaintext memory.

Isolation answers who can inspect execution. Attestation addresses what environment is actually running. Hardware-backed, signed evidence lets a verifier check that the environment uses genuine TEE-capable hardware and contains the expected measured software. Both checks matter: identifying the code is insufficient if its supposed isolation is counterfeit, and genuine confidential hardware is insufficient if it runs unexpected code. Together, isolation and attestation provide the foundation for processing private data with a private model.

For medical AI, obtaining permission to use data can be harder than building the model. Hospitals and laboratories hold expensive, tightly controlled clinical datasets; security policies and regulations may prevent a developer from simply bringing a model to those datasets. Bursell describes negotiations lasting months even for small collections, with collaboration across multiple providers harder still. Confidential execution offers a way to change the access arrangement without requiring each owner to release its raw records.

Other applications encounter related constraints:

• Personal agents: An assistant managing an inbox, calendar, or documents needs extensive private access. Users worry about sharing, developers worry about custody and misuse, and enterprises and regulators require defensible guarantees.
• Behavioral analytics: Fine-tuning on interactions with websites, content, and online services may be technically straightforward while remaining constrained by privacy law, internal security rules, and ethics.

The common problem is permission to perform useful computation without creating another uncontrolled copy of sensitive information.

Model monetization introduces reciprocal restrictions. A developer with a specialized legal, medical, or financial model wants to charge for use without distributing the weights. Customers may refuse to send sensitive records to that developer, even for an evaluation. A confidential environment is intended to let both assets meet for execution while their owners retain control over disclosure.

Training also raises a provenance question: was the model trained where, how, and on the datasets its provider claims? Bursell proposes attested execution as a way to connect inference outputs back to the original training inputs. The concrete mechanism developed later is narrower and useful: certificates identify the environment, and hashes identify approved workload components and inputs. Establishing complete training provenance also depends on the approved application’s behavior and the surrounding workflow; a matching hash alone does not establish the meaning or correctness of its computation.

Super Protocol combines a confidential AI cloud with a marketplace for models, datasets, and compute. Bursell reports support for Intel, NVIDIA, and AMD TEEs. The edge roadmap is less mature: he describes validating Armv9 confidential-computing compatibility through emulation, with confidential execution from personal devices to the cloud as an intended extension. He cites Android as 70% of the smartphone market to motivate that direction.

The proposed scaling model distributes work across independent GPU nodes, with automatic redistribution after server downtime. Bursell describes smart contracts on BNB Chain as orchestrating the platform without human intervention. The developer-facing goal is to hide the specialized work of launching and attesting TEEs. He also commits to making all parts open source, presenting Super Protocol as a protocol rather than a single hosted service. His HTTPS comparison concerns the protection phase: HTTPS protects communication in transit; confidential computing extends protection into AI processing.

The three terms in the talk’s title describe different ambitions:

GPU-less still uses GPUs. A developer can supply a server or obtain compute through the marketplace without buying hardware or committing to rent beyond its use.

Bursell presents the security claim categorically: unauthorized access by the hardware provider, Super Protocol, or a third party is technically impossible. Treat that as the presentation’s claim about its protected execution boundary, not a guarantee covering every application behavior. Confidentiality still depends on the code allowed inside that boundary and what it sends out.

The limitless ambition extends to restrictions on data access, geography, GPU availability, and model ownership. Bursell also connects it to agentic systems whose participants compute, communicate, and adapt without predefined scripts or centralized control. Confidential execution can address technical disclosure concerns in those arrangements; it does not itself remove legal obligations, cross-border restrictions, or the need to authorize data use.

The advertising example starts with Mars running campaigns across many markets. Bursell places the global digital advertising market at roughly $600 billion annually. Realeyes analyzes small facial expressions to assess reactions to ads for customers including Coca-Cola and Mars. Improving those models required more biometric video from external partners, but GDPR, CCPA, and ownership concerns made providers reluctant to share it.

For the Mars project, the presentation describes training in TEEs using NVIDIA H100/H200 GPUs and Intel Xeons, with smart-contract automation and hardware-backed certification. The intended change was that the training environment could consume protected footage without exposing its contents to infrastructure operators or other participants.

Bursell reports four times more sensitive footage and 319% growth in the training dataset. He reports prediction accuracy reaching 75% and a 3–5% sales increase across 30 brands in 19 markets. The linked Realeyes and Mars case study gives accuracy as up to 75%; it does not disclose an evaluation protocol, a human-comparison test, or a causal sales analysis. The proposed mechanism is nevertheless clear: stronger confidentiality assurances persuaded data owners to contribute more training material.

The healthcare case concerns the Brain Electrophysiology Laboratory, or BEL, which develops devices and AI tools for epilepsy and sleep disorders. It wanted an AI audit of documentation for a medical-device submission without exposing its trade secrets or the audit provider’s model. The presentation calls that provider Titonic; the matching BEL partner case study identifies it as Tytonyx. Bursell describes a baseline of two to four weeks of manual auditing, multiple NDAs, and the possibility of a 120-day review delay after a documentation error. That delay is a presentation claim, not a universal FDA penalty or an established outcome for BEL’s submission.

The audit ran in confidential hardware environments described as NVIDIA H100/H200 GPUs and Intel TDX CPUs. Smart contracts orchestrated the job, with cryptographic evidence and files readable only within the protected environment. The intended protection was reciprocal: BEL’s documentation remained private, as did the audit provider’s model.

Bursell reports that the compliance audit fell from two to four weeks to one to two hours. This measures the documentation review, not FDA clearance time. He also claims no re-review delays and zero leak risk; the supplied case study does not establish an FDA outcome or the elimination of all leakage paths. The practical result being presented is a faster confidential audit of sensitive documents.

The first demonstration turns the architecture into a marketplace transaction. Blockchain-based settlement connects model and dataset providers, confidential hardware providers, and clients. Models are leased rather than made available for download: the deployed application exposes a link or API while the weights remain within the confidential environment. The proposed commercial options include hourly pricing, fixed pricing, and revenue sharing.

The interface walkthrough follows a short deployment sequence:

1. Sign in. The marketplace supports Web3 and Web2 login; the demonstration uses Google.
2. Choose an offering. Browse models by category or task, or publish a private model of your own.
3. Inspect the model. The narrator selects a DeepSeek variant and reviews its description, quantizations, hardware requirements, and pricing options.
4. Select compute. Choosing an H100 automatically assembles an order, with optional manual changes to the compute configuration.
5. Deploy. The platform creates the order on the blockchain, then downloads the engine and model into the confidential environment for execution.

The marketplace demonstration skips approximately twenty minutes before the deployment is ready. The resulting link opens a text-generation web interface for interacting with DeepSeek. Deployment through an API and use of a custom domain are also presented as options.

The final step is verification. The narrator copies the deployment URL into a verification tool, which checks confidential hosting, an encrypted connection, and the integrity of the AI engine. Reaching an endpoint and verifying its execution environment are separate operations. The demonstration includes both.

The next demonstration moves from a single model endpoint to medical automation with n8n. A doctor submits an X-ray and patient information through a protected web form. An n8n workflow running inside a TEE cleans the inputs, invokes an AI model, generates a structured report, and emails it to the doctor. The introductory walkthrough shows the form displaying a completed analysis, including a clinical impression and next steps.

n8n is already deployed and opens through a secure access link. The narrator says direct UI access is disabled in production, where interactions instead use APIs and web forms. For the demonstration, the operator signs in, imports a prepared workflow, and adds AI API keys and Gmail credentials through the Credentials tab. Those credentials are stored inside the TEE. The model endpoint may be hosted on Super Protocol or elsewhere.

The webhook extracts the uploaded X-ray, patient ID, name, age, clinical information, and the doctor’s name and email. The workflow then separates personal information from diagnostic input: the model receives only the X-ray and symptom description. An allowlist makes that separation explicit. In JavaScript, the core projection can be written as:

function diagnosticInput(submission) {
  return {
    xray: submission.xray,
    symptoms: submission.symptoms,
  };
}

Returning only the diagnostic fields prevents a later addition to the submitted patient record from automatically becoming part of the model request.

After inference, the workflow recombines the diagnostic result with the patient’s personal data. It can produce text, HTML, or JSON, with JSON supporting hospital-system or ERP integration. It sends the report to the doctor’s Gmail account and posts a response back to the web-form endpoint. Those destinations define a larger data path than the n8n TEE alone: an external model receives diagnostic inputs, and email receives the assembled report. Egress, retention, and recipient access therefore remain separate policy decisions.

n8n nodes support API calls, webhook responses, and custom JavaScript. The Credentials tab manages secrets; the Executions tab exposes current and past runs, successes, errors, and debugging information. To inspect the prepared workflow, the narrator switches it to inactive, submits a test X-ray, follows node execution, and examines each node’s inputs and outputs. The demonstration then checks that the form receives its response and the email reaches the inbox. Because those inspection views can contain medical data, access to debugging output belongs within the workflow’s confidentiality policy too.

The same orchestration pattern is proposed for CT scans, MRIs, ECGs, and laboratory tests: receive an input, minimize what reaches the model, assemble the result, and deliver it to an authorized destination. Changing the workflow’s modality does not by itself establish the diagnostic validity of the model used.

The scaling demonstration uses vLLM across multiple GPU servers. The narrator describes partitioning model layers among nodes, a pipeline-parallel arrangement; vLLM also supports tensor parallelism, and the recording does not establish the exact version or flags used. Distributing a model creates more places where weights, code, and intermediate activations could otherwise be visible to host operators.

Super Protocol’s demonstrated protection puts every node inside a confidential virtual machine, or CVM, and joins them through a private overlay network. Weights and intermediate activations are decrypted and processed within the confidential environments; communication between nodes is encrypted. Alice, Bob, Carol, and David supply four H100/H200 GPU hosts. Here those names identify hardware owners contributing resources to one inference job.

Packaging starts from a custom Dockerfile based on the official vLLM repository. A helper script launches head and worker modes, with configuration files selecting each role. The first two packaging operations use ordinary Docker commands; for an image named confidential-vllm, they are:

docker build --tag confidential-vllm .
docker image save --output confidential-vllm.tar confidential-vllm

The narrator then uploads the image archive to decentralized storage with spctl, Super Protocol’s command-line tool. The deployable image and role configurations are prepared before node startup.

Four spctl configurations describe orders in the same overlay network, with known internal addresses. Alice starts the head node and receives an order ID. Bob and Carol then start regular workers, which connect to Alice’s head. David’s configuration adds inference-serving responsibilities to a worker role.

David’s node selects a preloaded Mistral model described in the recording as having 22 billion parameters. Its configuration also supplies the public domain, TLS certificate and private key, head-node address, and a four-GPU setting. The responsibilities are:

The model runs across the combined resources; David’s extra launch responsibility does not mean inference is confined to his host.

Once all four orders are deployed, the narrator downloads their on-chain reports and compares the image and model hashes with the expected values. Each report passes the shown integrity checks. The demonstration then sends requests to the public endpoint. The narrator attributes faster responses to parallel execution across four machines, but provides no latency or throughput comparison. Inter-node communication and the chosen parallelism strategy remain consequential to performance.

The final demonstration makes verification part of authorization. Bursell describes hardware-signed evidence connecting a genuine TEE, expected code, and an open-source runtime without revealing workload data. Crucially, the protocol is intended to refuse application and data loading when those checks are bypassed. Verification gates access to inputs; it is not merely a report produced afterward.

The participants now have different roles from the GPU demonstration. Alice’s laboratory and Bob’s clinic each contribute sensitive datasets. Carol’s research center contributes a training engine. There is no model yet: the goal is to train a new model for early cancer detection. All three inputs meet inside the confidential environment, while each participant retains custody of its original assets outside it. The verified engine, Super Protocol Certification Center, and smart contracts on opBNB—BNB Chain’s layer two—automate the collaboration.

The workflow is designed to reduce the manual setup and trust negotiations that can stall multiparty projects. Its CVM is reusable across jobs rather than recreated for every task. At boot, it requests remote attestation from an open-source certification authority that itself runs in confidential mode. If verification succeeds, that authority issues a certificate identifying the attested confidential environment.

A trusted loader inside the CVM then receives its own attestation and certificate, creates a signed key pair, and checks workload components. A failed check stops processing. This establishes two layers of identity before sensitive inputs are admitted: the confidential machine and the loader responsible for validating what it will execute.

Carol first builds a container-based training engine, calculates its hash, and uploads the image to her encrypted storage. She provides its source code and hash to the data owners for review. Although the engine is proprietary, she privately shares the source with Alice and Bob so they can check for data leakage. If direct sharing or in-house review is unsuitable, an external reviewer can inspect it and provide assurances. Attestation identifies the approved program; source review determines whether that program deserves approval.

The certification center separately supports verification of the confidential environment. Alice and Bob archive their datasets and upload them with spctl, which encrypts the files during upload. Each uses their own storage. Their prepared access information includes the dataset hash, encryption-key information, and storage access details, while binding use to the approved engine hash and the intended CVM.

The demonstration selects a compute offer whose public key is already published on the blockchain. The protected submission is addressed to that confidential environment, which holds the private key required to decrypt it. This restriction applies to the submitted encrypted material; Alice and Bob still retain their original datasets outside the environment.

Carol submits the main order using her engine and both participants’ prepared access files on the selected compute offer. Before training, the trusted loader:

1. Checks the CVM certificate.
2. Calculates hashes for the engine, datasets, and configuration.
3. Compares them with the approved values.
4. Blocks the job if any value diverges.
5. Starts training only after every check passes, with the engine and data decrypted inside the TEE.

The confidentiality boundary thus depends on both where the job runs and which exact components it is allowed to run.

Only Carol receives the encrypted trained model and artifacts. The narrator describes encryption keys as remaining inside the TEE, then demonstrates recipient-side decryption with Carol’s configured key. The operational fact shown is that spctl downloads the completed result and decrypts it for Carol; the narration does not specify the full key hierarchy behind those two statements.

After unpacking the result, the narrator examines logs showing the input and reference directories, the training process, and saved outputs. The SP output folder contains a PKL model file with weights, an evaluation matrix, and other artifacts. These files show what the application produced; the separate integrity report supplies evidence about the environment and approved inputs used for the job.

Before training starts, the trusted loader creates an integrity report signed inside the TEE. It is published on opBNB as part of the order report. Once the job has started, the narrator retrieves that report with spctl and inspects its certificates, input list, and timing.

Verification compares the executable image hash with the engine Alice and Bob approved, then checks the hashes of Alice’s and Bob’s datasets. The demonstration shows each match. These comparisons connect the certified environment to the expected engine and input files without publishing the raw datasets. After completion, the encrypted result is delivered only to Carol and the job’s raw inputs are wiped.

The report combines an integrity report, a signature, and a certificate chain. The same trust chain supports another operation: an application running inside a CVM can sign runtime data with its private key, allowing an on-chain verifier to establish that the signature came from a certified confidential environment. That makes the execution identity useful beyond an audit trail, including in Web3 AI workflows that consume signed application outputs.

Bursell closes this demonstration by presenting the report as a replacement for blind trust, NDAs, and manual audits. The earlier source-review step remains essential to interpreting that promise: the certificate chain and hashes establish environment and component identity, while application review addresses whether the approved code leaks data or performs acceptable work. The process automates execution checks without making legal agreements or semantic review universally unnecessary.

The closing invitation is to launch a model in a confidential environment: use private data without exposing it to the host, deploy proprietary weights without distributing them, and inspect cryptographic evidence of execution. Bursell also describes fine-tuning without compliance risk; the demonstrated mechanisms support protected execution and verification, while compliance still depends on the particular data use and application.

Bursell names the Super Protocol website, Super AI Marketplace, documentation, and NVIDIA’s architecture walkthrough as starting points. When reading alongside the recording, keep their versions distinct: NVIDIA’s November 2024 article describes Polygon, while this demonstration uses BNB Chain and opBNB; the current Super Protocol homepage emphasizes Super Swarm and Kubernetes rather than reproducing the recorded marketplace experience. The useful first exercise remains concrete: deploy a workload, identify the code and inputs you approved, and examine the evidence that binds them to its confidential environment.