AI Engineer World's Fair 2025
GPU-less, Trust-less, Limit-less: Reimagining the Confidential AI Cloud
Read the talk
Confidential AI: From Protected Inference to Verifiable Multiparty Training
Follow Super Protocol’s demonstrations of model leasing, medical automation, distributed inference, and training that binds private inputs to an approved execution environment.
From a talk by Mike Bursell
Before you start: Familiarity with model inference, containers, APIs, and public-key cryptography will help; the article introduces TEEs and attestation.
Private data meets a private model
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The constraints start before computation
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Independent compute, verifiable execution
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:
| Term | Intended operating model |
|---|---|
| GPU-less | Use independent GPU nodes without a single cloud dependency |
| Trustless | Verify protected execution instead of relying solely on an operator |
| Limitless | Reduce barriers to collaboration, deployment, and monetization |
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Two applications of protected data access
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Lease, deploy, and verify a model
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:
- Sign in. The marketplace supports Web3 and Web2 login; the demonstration uses Google.
- Choose an offering. Browse models by category or task, or publish a private model of your own.
- Inspect the model. The narrator selects a DeepSeek variant and reviews its description, quantizations, hardware requirements, and pricing options.
- Select compute. Choosing an H100 automatically assembles an order, with optional manual changes to the compute configuration.
- 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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A confidential n8n workflow for X-ray reports
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:
javascript
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Distribute inference across four confidential GPU hosts
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:
bash
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:
| Host owner | Role |
|---|---|
| Alice | Head node accepting cluster connections |
| Bob | Worker |
| Carol | Worker |
| David | Worker that also launches model inference |
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make verification a prerequisite for training
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Approve the engine and bind the encrypted inputs
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 compute offer 8, whose public key is already published on the blockchain. The protected submission is addressed to that 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 compute offer 8. Before training, the trusted loader:
- Checks the CVM certificate.
- Calculates hashes for the engine, datasets, and configuration.
- Compares them with the approved values.
- Blocks the job if any value diverges.
- 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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Deliver the model to its authorized recipient
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Inspect the report and verify runtime signatures
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Start with a workload you can verify
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
A 2024 walkthrough of confidential model leasing, deployment, trusted loaders and attestation.
The project's current overview of confidential execution and multi-party infrastructure.
Public repository for the command-line tooling used to manage Super Protocol workloads.
Further reading
- Realeyes and Mars case studyArticle
Exxact's account of confidential advertising analytics, including reported dataset growth and business outcomes.
- BEL and Tytonyx case studyArticle
Exxact's account of confidential medical-device compliance reviews and reported processing-time reductions.
Versioned guidance on tensor and pipeline parallelism, multi-node deployment and network requirements.
Updates since the talk
- Confidential computing trust boundariesDocumentation
NVIDIA's later guidance on application trust, key release, logging and threats outside confidential VM protection.
Read the complete timestamped transcript
- 0:00
[upbeat music] AI is transforming everything: healthcare, finance, automation, digital marketing.
- 0:15
But one thing holds it back, and that's trust. How do you run models on sensitive data without handing it over? How do you deploy proprietary models without losing control?
- 0:27
And how do you collaborate, especially in non-deterministic environments, without relying simply on blind trust? Well, that's what confidential AI solves, and that's what Super Protocol makes real. GPU-less, trustless, limit-less.
- 0:47
And this session is about what those words actually mean and how developers can apply them to run, scale, and monetize AI workloads securely. So whether you're building with sensitive data, proprietary models, or untrusted partners, you'll see how confidential AI opens up new possibilities.
- 1:07
So we'll start by breaking down the core of technology behind confidential AI and then walk through a number of real demos to see how it works in practice. Let's start with the foundation, confidential computing.
- 1:21
This solves one of the most overlooked problems in AI today, which is that your data and your model are most vulnerable, not when they're stored or in transit, but while they're being processed, whether that's during training, fine-tuning, or inference.
- 1:36
And that's where trusted execution environments, or TEEs, come in. At the hardware level, a TEE is, it's a sec- secure and isolated part of the processor like Intel TDX or AMD SEV-SNP or NVIDIA GPU TEEs.
- 1:53
It creates what's called a confidential environment where code and data are protected even during execution. The chip itself provides the isolation using instructions built into it during manufacture.
- 2:08
So once a workload enters this environment, it's protected in memory, invisible to the host OS, hypervisor, or in fact, even anyone with system access, even the owner of the hardware.
- 2:21
And it's not just about isolation. A TEE also generates a cryptographic attestation. That's a signed proof that the workload ran inside verified hardware using unmodified code.
- 2:38
So this is important for two reasons. Not only do you need strong assurances that the workload is truly protected by the hardware, but attestation also allows us to make statements about the work- what the workload actually is.
- 2:53
So attestation lets you know not only what's in the TEE, but also that it's a real TEE in a properly manufactured TEE-capable chip. Because if you can't be sure of those two facts, then you can't be sure of anything about the workload or what it's processing.
- 3:12
So in short, a TEE lets you run sensitive computations securely and prove that they ran as intended, and that changes everything. It means we can now run AI models, even on sensitive data, without exposing the model or the data.
- 3:33
That's the foundation of what we call confidential AI.
- 3:39
So let's look at where and why you might care about this. In particular, what about some real-world problems that developers face, and why is this shift to confidential AI critical?
- 3:50
We'll start off with healthcare. If you've ever tried to build or fine-tune a medical AI pr- model, you know the hardest part isn't the model, it's the data, and not processing it, just getting it, or permission to use it in the first place.
- 4:06
Hospitals and labs just don't share raw data sets, even if your model could improve patient outcomes.
- 4:14
In research, access to clinical data is tightly controlled, expensive to generate, and often siloed. And you can't just bring your model to the data, not under current regulations or security policies.
- 4:27
And this all means that trying to train medical AI models on real data can take months of negotiation to get access to even small data sets, and working across data sets from multiple providers can be well-nigh impossible.
- 4:42
This is what confidential AI can help solve.
- 4:47
Another topic, personal AI agents. Those are the ones that manage your inbox, calendar, or documents, and they're already being built, but mass adoption is still out of reach. Why?
- 5:01
Well, one of the main reasons is because these agents need deep access to private, sensitive data to be truly useful, and that triggers concerns across the board. Users don't want to expose their personal data.
- 5:16
How can I be sure it's not being shared? Developers don't want to store it. How can they protect it from being stolen or misused? And enterprise and regulators won't green-light this use without strong guarantees.
- 5:31
How can we all be sure that we won't be sued? So confidentiality isn't a nice-to-have. It's a, the missing piece that's actually holding back real-world adoption of these technologies.
- 5:46
Our next example is digital marketing. In digital marketing and customer analytics, everyone wants to fine-tune models on real user behavior, tracking how users interact with various websites, content, and online services.
- 6:00
But between privacy laws, internal security rules, and, well, basic, basic ethics, working with that data often risks upsetting regulators, uh, and auditors, or is downright blocked. It's a massive gap between what's technically possible and what's actually allowed.
- 6:19
And what about AI model monetization? Let's say that despite the various complications and regulations that need to be navigated, you've built a domain-specific model for legal, medical, or financial use.
- 6:33
Of course, you want others to use it, and you wanna get paid for it. But you're not willing to give away your model or its weights for free, which you risk if you allow people to run it themselves without protection.
- 6:47
At the same time, customers aren't willing to expose their sensitive data, not for testing, not for production, so they won't trust you to run your model with their data.
- 6:57
In other words, both sides want the benefits without giving up control. And the good news is, with confidential AI, neither party has to relinquish that control.
- 7:10
Let's talk about model training and proof because there's another typically overlooked problem, and that is provenance. The key question's simple. Even if you have managed to train or fine-tune your model on sensitive data, how do you prove its provenance, allowing users to track back to the initial data sets?
- 7:32
In other words, how can you guarantee that a model was really trained where and how you say it was? With a tested execution, this becomes possible. The provenance of the data can be assured with proof that the answers or outputs that you get at the inference stage relate back to the initial data sets and only the original
- 7:54
data sets. So in all of the cases we've just discussed, traditional cloud setups fall short. They're built on trust and legal contracts, not on provable guarantees. And these limitations are exactly why we built Super Protocol to make confidential AI not just possible, but usable.
- 8:16
What we're gonna do next is walk through how it works and what it unlocks.
- 8:22
It's time to talk about Super Protocol. What is Super Protocol? Well, Super Protocol is a confidential AI cloud and marketplace built for secure collaboration and monetization of AI models, data, and compute.
- 8:38
What are some of the pieces? Well, we have, first of all, we have a TEE-agnostic infrastructure. What does that mean? Super already runs on Intel, NVIDIA, and AMD TEEs, and as major chip makers continue to include TEEs as a core part of their strategy, we'll support those platforms too.
- 8:58
It means edge-ready architecture. We've validated Arm confidential computing via Arm9, uh, emulation, confirming full compatibility with our architecture. So as Arm9-based chips roll out broadly across Android devices, now 70% of the smartphone market, we aim to deliver end-to-end confidential AI from personal edge devices
- 9:23
straight to the cloud. And we're built on swarm computing principles, which means that we scale across distributed GPU nodes with no single point of failure and automatic workload redistribution in case of server downtime.
- 9:40
And we're fully decentralized with no human intervention, entirely orchestrated by smart contracts on BNB Chain.
- 9:49
And there's no barrier to entry, zero barrier entry because you don't need TEE expertise to run or attest the workloads.
- 10:01
And maybe best of all, all parts of Super Protocol will be open source because it's a protocol, not a service. Think about the HTTPS protocol. It keeps your data safe when you send that data online, and Super Protocol does the same, but for AI.
- 10:19
It protects your data while AI is working on it. It sets a new standard for keeping data safe during AI computing.
- 10:29
What do we mean by GPUless? Well, this isn't about removing GPUs. It's about removing dependency because with Super Protocol, you can run accelerated AI workloads across independent GPU nodes without being locked into any cloud vendor or centralized provider.
- 10:47
You don't need to buy GPUs, nor do you need to rent them for longer than you're using them. Whether you're training on your own server or accessing GPUs through the marketplace, you keep control.
- 11:00
And thanks to the nature of TEEs and Super Protocol's open-source architecture, no unauthorized access is technically possible, not by the hardware provider, not by Super Protocol, not by any third party.
- 11:14
That's what makes confidential computing the foundation of trustless AI.
- 11:21
And then there's limitless. Limitless is about removing the blockers, the legal, the technical, and the organizational barriers. With confidential AI, you're not limited by policy, regulation, or infrastructure constraints
- 11:36
because traditional cloud platforms impose limits on data, on geography, and on control. You can't access GPU instances without approval. You can't access sensitive data sets, collaborate across borders, or monetize your mode- your model without handing it over.
- 11:56
And traditional clouds are especially unfit for agentic non-deterministic AI where autonomous agents interact, make decisions, and evolve in real time. Most cloud environments just weren't built for that kind of dynamic multi-party logic.
- 12:14
Super Protocol removes those limits. You can train, deploy, and monetize AI across organizations and jurisdictions with full confidentiality and ownership. Agents can compute, communicate, and adapt without predefined scripts or centralized control.
- 12:33
Confidential, permissionless, limitless. Now let's look at two great end customer case studies from digital marketing and the healthcare industries.
- 12:45
Digital marketing first. Imagine Mars, your favorite confectionery company, running hundreds of ad companies all over the world. The digital global ad market is massive, worth around $600 billion a year, but every week ad wastes budget.
- 13:05
Realeyes is a company that uses AI to measure how people react to ads by analyzing tiny facial expressions. They help brands like Coca-Cola and Mars choose ads that really truly connect with people.
- 13:20
But to make their AI even more accurate, Realeyes needed much more biometric video from external partners, and that's where the problem started. Privacy laws like GDPR and CCPA, along with concerns about data ownership, made providers reluctant to share sensitive footage.
- 13:42
So for its Mars project, Realeyes used Super Protocol's confidential AI cloud. AI training ran inside secure environments, in other words, TEEs, using powerful chips like NVIDIA's H100s and H200s and Intel Xeons.
- 14:00
Every step was automated by smart contracts and verified by both the hardware and Super Protocol's open source certification, which meant that throughout the process, the data and the models stayed completely secure, proven to be inaccessible even to the cloud provider, to Super Protocol, or to Realeyes themselves.
- 14:22
Verifiable confidentiality changed everything because once providers knew their data was truly protected, they shared four times more sensitive footage, growing the training set by 319%.
- 14:38
With that boost, accuracy jumped to 75% on par with human-level performance, and to Mars, it paid off, a 3% to 5% sales increase across 30 brands in 19 markets.
- 14:54
The takeaway, when data privacy is provable, locked data gets unlocked, powering better models, smarter AI, and real business impact. That's the Super Protocol advantage, transforming privacy into performance and confidence into revenue, not just for digital marketing, but for every data-driven industry.
- 15:17
Now it's time to talk about healthcare. In fact, let's talk about BEL, the Brain Electrophysiology Laboratory. They were racing to submit a new epilepsy diagnostic device to the FDA.
- 15:29
BEL creates advanced medical devices and AI tools to help diagnose epilepsy and sleep disorders. But to get FDA approval, they needed to submit perfect documentation. That usually takes two to four weeks of manual audits, multiple NDAs, and carries the risks of exposing trade secrets.
- 15:50
Even one small mistake could cause a 120-day delay in review, slowing down patient access and return on investment. They wanted to speed things up using Titonic's AI-powered audit tool, but they had one concern, one big concern.
- 16:09
How to keep BEL's data and Titonic's model safe from exposure in traditional cloud environments. The answer, Titonic's used Super Protocol's confidential AI cloud. The audit ran inside secure hardware environments in TEEs using NVIDIA H100 and H200 GPUs and Intel TDX CPUs.
- 16:32
Every step was automated, orchestrated by smart contracts, and backed by cryptographic proof. All files and models stayed encrypted, only readable inside the secure environment and completely hidden from Super Protocol, BEL, Titonic's, or anyone else.
- 16:51
The results were huge. Audit time dropped from weeks to just one to two hours. There was zero risk of leaks. Both BEL's and Titonic's IP stayed fully protected, and there were no re-review delays, cutting out those 120-day setbacks.
- 17:10
The bottom line, Super Protocol helped BEL move faster, stay secure, and deliver life-saving tools to patients much sooner. It proves that when confidentiality is guaranteed, even the most sensitive and high-stakes processes like FDA clearance audits can be transformed.
- 17:29
That's the Super Protocol advantage. You want to see a demo, don't you? Let's focus on the practical part of today's session so that you can see and feel how this works in action.
- 17:40
Remember, Super is a confidential AI cloud and marketplace built for secure collaboration and monetization of AI models, data, and compute.
- 17:49
Our first demo is of the Super AI Marketplace. We'll start with an overview of its interface and core value prop, and then walk through a step-by-step demo of deploying an AI model in just a few clicks entirely within a fully confidential environment.
- 18:07
Let's begin the marketplace demo with a short overview of the highlights. The Super AI Marketplace is built on a confidential and decentralized architecture. There are no centralized components or data centers.
- 18:19
A blockchain-based ecosystem is used to manage the relationships and financial settlements between the participants. Providers of AI models and data sets, providers of confidential computing hardware, and the clients.
- 18:31
Confidential computing ensures that the models remain private and authors retain full control and ownership. Models may be leased, but not downloaded. Nobody has access to the trusted execution environment, TEE, during processing, which means that the models and the user data are off-limits even to the clients.
- 18:51
The models are deployed in the TEE and are accessible via a link or API. One of the goals of Marketplace is to enable monetization for authors of closed source models.
- 19:02
A variety of scenarios are offered: per hour, fixed, and revenue sharing.
- 19:09
Now, let's do a speed run through the Marketplace UI and deploy one of the models.
- 19:15
The Marketplace supports two login methods, Web3 and Web2. Let's log in through Google.
- 19:26
This is the main marketplace of the models available for deployment in a variety of categories or tasks. You can also deploy or publish your own model. The published models will remain confidential and not be available for download.
- 19:41
In this demo, we will deploy one of the published DeepSeek models.
- 19:47
As you can see, there are many variants.
- 19:53
Let's take this one. You can see the description here,
- 19:59
and also a variety of quantizations, requirements, and pricing scenarios.
- 20:07
Let's deploy on the H100 GPU. The order is assembled automatically, but you can also modify it manually to adjust the compute configuration.
- 20:17
Let's deploy now. The order is now being created on blockchain.
- 20:26
The order is now being prepared for deployment. The engine and the model will be downloaded into the confidential computing environment and get ready for execution.
- 20:36
About twenty minutes have passed. The order is now deployed at this link. You can also deploy as an API and integrate into your own app, and you can also set up your own domain.
- 20:51
This is the text generation web UI interface. Here you can interact with the DeepSeek model.
- 21:06
All right, and now one final step, verification. Let's copy this link.
- 21:16
Now we input the link into this tool. It verifies that this model is deployed in a confidential environment, that the connection is encrypted, and that the AI engine has not been tampered with.
- 21:29
In the next demos, we will show the many more features and capabilities of Super Protocol. Thank you.
- 21:38
Now let's move to something more dynamic. Agentic AI is gaining traction across industries. Let's see how agentic automation can be built and run inside Super Protocol.
- 21:50
Let's explore how to build secure automated AI workflows for processing sensitive medical data using n8n deployed on Super Protocol.
- 21:59
By running everything inside TEEs, inaccessible even to server admins or Super Protocol, and combining low-code automation with a decentralized infrastructure, we deliver fully confidential, compliant, and verifiable medical AI.
- 22:15
In this demo, we will review a simple use case. A doctor uploads an X-ray image and the patient's personal data using a protected web form. That image, along with metadata, is passed into an automated workflow built with n8n, which runs inside a TEE on Super Protocol.
- 22:34
The workflow cleans the input data, invokes an AI model to analyze the X-ray, and generates a structured medical report. That report is then emailed securely to the doctor.
- 22:50
Let's take a look at the system in action. We've already deployed n8n on Super Protocol. Once deployed, the platform gives us a secure access link. Opening this URL brings up the n8n user interface.
- 23:03
In production, this direct UI access is disabled. Every interaction goes through secure APIs, web forms, et cetera. We register or log in and enter the n8n dashboard.
- 23:17
Instead of building a workflow from scratch, that will take some time. We'll import one that's already been prepared.
- 23:25
For the workflow to run, we need to add some credentials in the Credentials tab, API keys to access the AI model deployed on Super Protocol or elsewhere, Gmail credentials for sending email reports.
- 23:37
These are securely stored and isolated inside the TEE. We will add those behind the scenes.
- 23:44
This example workflow is simple, but demonstrates all the core ideas, image processing, data sanitization, AI analysis, and automated reporting.
- 23:55
Here's how the workflow runs. The webhook trigger starts the workflow automatically when data is submitted via the web form. Data extraction pulls out the uploaded X-ray and metadata, the patient's ID, name, age, and clinical information, as well as the doctor's name and email address.
- 24:15
Then personal data is separated from diagnostic input. The AI model receives only the X-ray and symptom description necessary to generate a diagnostic result.
- 24:26
This result is combined with the patient's personal data to form a medical report in text, HTML, or JSON. The latter may be needed to easily integrate the workflow with hospital systems or ERPs.
- 24:39
The report is sent to the doctor's Gmail
- 24:43
and also posted back to the web form endpoint.
- 24:46
Let's quickly walk through the n8n's user interface. We've already seen the Workflows tab. It's where you build or import automation flows. Nodes in n8n are highly customizable and allow you to make API calls, respond to webhooks, and write any JavaScript in your workflow.
- 25:04
In the Credentials tab, you can securely manage API keys and login details.
- 25:10
In the Executions tab, you can view current and past runs, successes, errors, and debugging data.
- 25:18
To debug, switch the workflow to inactive. Let's submit a sample form with a test X-ray.
- 25:28
Watch each node execute step by step. We can inspect the inputs and outputs of each node: image, metadata, AI result, et cetera.
- 25:46
Confirm that the form receives the response and the email arrives in the inbox. Everything works within a secure, confidential environment.
- 25:56
To conclude, this solution easily adapts to other use cases: CT scans, MRIs, ECGs, and even lab tests in minutes with n8n's visual builder secured by Super Protocol's TEEs.
- 26:11
No more choosing between functionality and privacy. Confidential AI made simple.
- 26:17
Let's look at scaling. You'll see how Super Protocol enables distributed inference using vLLM across multiple GPU servers without relying on any single provider. This is where GPU-less becomes real.
- 26:35
For this demo, we're distributing inference of a large language model across multiple GPU servers using vLLM.
- 26:43
Under the hood, vLLM partitions the model by layers and assigns each layer's computation to a different node in an overlay network. Great for memory efficiency and throughput, but by default, those machines run in unprotected environments, exposing your data, model code, and intermediate state to host operators.
- 27:02
Here's how Super Protocol secures it. Every vLLM node runs inside a confidential VM powered by TEE hardware, all tied together over a private overlay network. Data, model weights, and intermediate activations are decrypted and processed only inside each confidential environment, with all inter-node communication encrypted, so no sensitive material ever leaves the secure boundary or is exposed
- 27:27
to any host. Now let's see this in action. Launch distributed vLLM inference in confidential mode and retrieve the execution report. In our demo, we have four host owners: Alice, Bob, Carol, and David.
- 27:43
They provide TEE hardware with GPU H100/200 to Super Protocol. That allows running a single large LLM across four GPU nodes in fully confidential mode on Super Protocol.
- 27:56
Our custom Docker file is based on the official vLLM repository. We added a short helper script that can launch vLLM in different modes, head and workers. We also prepared configuration files for each mode since we need to run all four participants in different roles.
- 28:15
First, let's build the Docker image using the build command.
- 28:21
Next, let's export the built image to a tarball archive, which we'll need for the next step.
- 28:29
Then let's upload the archive into decentralized storage using a Super Protocol CLI tool called spctl.
- 28:37
Now it's ready to run on Super Protocol.
- 28:42
We've prepared four spctl configuration files, one per participant. First, we launch the master node head, which accepts all incoming connections. Since all orders are in the same overlay network and we know the internal IP addresses, this is easy to do.
- 29:01
Alice runs her vLLM to start the head node.
- 29:06
Super Protocol launches her confidential environment and returns an order ID.
- 29:15
Next, let's launch Bob and Carol in regular worker mode, and they automatically connect to Alice's head node and share GPU cycles.
- 29:25
David's node is special.
- 29:42
His node configuration file not only sets the mode, worker, but also specifies which model to run. In this case, it's Mistral with twenty-two billion parameters. Points to the domain with an SSL certificate and private key for secure connections.
- 29:58
Includes the head node's address, so it can join the overlay. Launches the model inference in addition to being a worker. This parameter shows that the setup uses four GPUs connected together.
- 30:09
We preloaded the Mistral model so that the hybrid node can immediately launch inference across all four GPU hosts in one confidential workflow. Here, Alice, Bob, Carol, and David are simply the owners of those hosts.
- 30:23
The job itself runs across their combined resources.
- 30:28
All four orders have deployed successfully. We can download the on-chain reports and verify that the image and model hashes match what we expect. We can do this verification for each of the four participants.
- 30:40
Each report passes integrity checks, confirming that the orders contain the correct model and application.
- 30:48
Finally, let's test the public endpoint. Anyone can access the provided domain, verify that everything works, and make requests.
- 31:08
Since processing is parallelized across four machines, responses return much faster than usual.
- 31:16
That's it. You've seen how Super Protocol enables GPU-less distributed inference, fully confidential, decentralized, and verifiable on-chain. The distributed setup provides both security through TEE hardware and improved performance through parallel processing.
- 31:33
So finally, let's talk about trust, one of my favorite topics, or rather, how you can move beyond it. In this demo, we'll show how Super Protocol replaces blind trust with built-in cryptographic proofs.
- 31:48
Every run is verifiable independently and transparently down all the way to the hardware level. So trustless doesn't mean insecure, it means verifiable by design, because every workload produces a cryptographic proof showing what ran, where, and how, without exposing the actual workload data.
- 32:12
Now, let's see what makes this truly trustless. Full verifiability and trust aren't required anymore. When a workload runs on Super Protocol, it generates a cryptographic attestation, a signed proof from the hardware itself, building on the attestation capabilities inherent in confidential computing.
- 32:35
This attestation verifies that your model executed in a real trusted execution environment, a TEE, using unmodified code on verified hardware inside a secure, open-source runtime.
- 32:50
You don't have to trust the provider. You don't have to trust the platform, 'cause you can verify. And even if you don't, the system won't expose your sensitive data if there are attempts to bypass it, simply 'cause the protocol won't allow your application and data to load and run if this happens.
- 33:10
Here's what that looks like in practice.
- 33:14
Hi. Today, we'll demo how Super Protocol helps data owners and AI model developers collaborate securely. One of the toughest business and technical challenges is training models on medical data, where privacy is crucial.
- 33:27
We'll show how Super Protocol solves this. We have three participants: Alice's lab, Bob's clinic, and Carol's research center. Alice and Bob each hold sensitive data sets. Carol brings a training engine.
- 33:40
There's no model yet. The goal is to train a brand-new model for early cancer detection on Alice's and Bob's data without exposing either the data or Carol's intellectual property.
- 33:51
All three inputs, Alice's data, Bob's data, Carol's training engine, run inside a trusted execution environment, or TEE. No one, not the cloud host, not Super Protocol, not even the participants can access what's inside.
- 34:07
Outside the TEE, each party keeps full custody of its assets. Inside, no one can see raw data, source code, or weights. Training is fully automated by the verified engine, the Super Protocol Certification Center, and smart contracts on opBNB, BNB Chain's layer two.
- 34:27
In the past, multi-party training meant legal paperwork, manual setup, and blind trust, so many projects stalled or took months or years to get underway. Super Protocol removes those trust barriers.
- 34:39
It hides the complexity and automates the entire process behind the scenes, and you don't need to be an expert in confidential computing.
- 34:47
At Super Protocol, a confidential virtual machine, or CVM, is launched once and then handles multiple jobs. No need to spin up a new VM for every task. On boot, the CVM contacts the open-source certification authority, also running in confidential mode for remote attestation.
- 35:06
If the check passes, the center issues a certificate proving the CVM is genuine and running inside an attested, trusted execution environment. But attesting the CVM isn't enough. Before any data enters, an open-source security mechanism inside CVM, the trusted loader, comes in.
- 35:25
First, it's attested and gets its own certificate. Then it creates a signed key pair and checks every component. If any of these checks fails, the process automatically stops to safeguard all parties and ensure nobody's data or models are compromised.
- 35:42
Now, let's walk through that flow. Carol builds a container-based training engine.
- 35:51
Here is its hash. She uploads her engine image to her own encrypted storage, provides its hash and the source code so that the data owners can verify them.
- 36:06
Alice and Bob check them. To be clear, Carol's engine is proprietary, but she privately shares its source code with Alice and Bob so they can verify it doesn't leak data.
- 36:17
If she's not happy doing this, or if Alice and Bob aren't security experts, an alternative is to have an external party inspect it and provide assurances to Alice and Bob that the model is safe to process their data.
- 36:30
Meanwhile, Super Protocol's open-source certification center lets anyone confirm that the whole process runs inside a trusted confidential environment.
- 36:40
Alice and Bob archive and upload their datasets using the Super Protocol CLI tool called spctl. The utility encrypts the files during upload. Bob uploads his dataset to his own decentralized storage.
- 36:53
Alice uploads data on her side to her storage.
- 37:07
Let's see what's inside Alice's file. Here is the hash encryption key and storage access. The same will be with Bob's file. Alice and Bob grant the CVM access and specify the verified engine's hash and the ID of the confidential virtual machine that will process the order.
- 37:25
In our case, it's the compute offer number [REDACTED:generic_id]. Its public key is already published on the blockchain.
- 37:34
Even Alice herself doesn't have access to this encrypted data, as only the specified CVM with ID [REDACTED:generic_id] has the private key to decrypt it. Bob's data is protected in the same way.
- 37:46
Carol places the main order to process the workload using her uploaded engine and Alice's and Bob's prepared access files. She uses the compute offer [REDACTED:generic_id]. When the job is submitted, the trusted loader checks the CVM certificate, calculates hashes for the engine, datasets, and config, compares them with the approved list, blocks the job if anything diverges.
- 38:09
Only if every hash matches does training start inside the TEE. Data and the engine are only ever decrypted inside the TEE. Eve- even the participants cannot access them during execution, and everything is protected from other parties, including the owner of the system executing the training.
- 38:28
Only Carol receives the encrypted output, the newly trained model and artifacts. Encryption keys never leave the TEE, so Alice, Bob, Super Protocol, and the hardware vendor remain blind to the results.
- 38:43
Let's check the order status. As we can see, the job is already done, so we can download the result now.
- 38:53
Here it is, and we can also see that it was decrypted. Spctl decrypts it using Carol's key specified in the config file. You can find more details about this process in the Super Protocol documentation.
- 39:07
Everything is explained there. Let's unpack the result and check what's inside.
- 39:15
The logs show that the application ran as expected. We can see files located in the input directories, meaning the input and reference data were pulled from those directories just as expected.
- 39:28
Then the training process ran and the results were saved. All output was successfully written into the SP output folder. Here's the trained model, the PKL file with its weights, evaluation matrix, and other output artifacts.
- 39:43
All of this was processed in a fully confidential environment. That means everything ran on a secure machine.
- 39:51
Security is great. Proof is better. Before training begins, the trusted loader creates an integrity report signed inside the TEE. That report is later published on opBNB as the part of order report, giving anyone public tamper-proof evidence that the job will run in a certified environment with the approved inputs.
- 40:12
Here's how we retrieve the report for this specific order using the spctl command. If the job has already started, this report has already been published to the blockchain. What we see here includes the certificates we discussed earlier, along with a list of processed inputs and the timing.
- 40:31
The image refers to the actual executable workload. Its hash matches exactly the one we saw earlier, the one trusted by both Alice and Bob. Right here, same hash.
- 40:43
We can also verify that these hashes correspond to Alice's and Bob's inputs. Let's take Alice's dataset. Its hash matches.
- 40:53
And now Bob's. Same thing. So yes, both Alice's and Bob's data were used in this job, and it ran with the correct training engine.
- 41:04
The job is complete. The result is encrypted and delivered only to Carol. After every job is finished, all raw inputs are wiped. An order report is published on chain, giving everyone public proof that the run was genuine.
- 41:19
The order report isn't just an audit log. During runtime, an app inside a CVM can sign data with its private key. Anyone on chain can verify that the signature came from a trusted, decentralized, confidential environment, crucial for Web 3 AI workflows.
- 41:36
You've just seen how Super Protocol lets Alice, Bob, and Carol train a medical AI without ever exposing data or models to each other or any other parties. Super Protocol turns complex, multi-party, trust-heavy collaboration into a push-button workflow.
- 41:52
Try it yourself. Build, verify, run, no expertise in confidential computing required. Thanks for watching.
- 42:02
This report shows exactly what ran, where it ran, and that it followed the expected logic, all verifiable by any participant. No NDAs, no manual audits, just built-in verifiable trust powered by confidential computing.
- 42:20
It's time to recap. Throughout this session, we've looked at real-world problems, shared impactful case studies in the most data-driven industries, digital marketing and healthcare, and walked through demos showing exactly how confidential AI actually works.
- 42:36
Running models on private data without exposure, deploying proprietary models without losing control, fine-tuning without compliance risk, and verifying execution with cryptographic proof.
- 42:51
With Super Protocol, you get all of that in a way that's simple to use, transparent and verifiable, secure by design, GPU-less, trustless, limitless, and it's not just a concept, but a practical path forward for developers.
- 43:07
We invite you to launch your own model in a confidential environment today. Try it now. Here are some links to some starting points. The Super Protocol website, the Super AI Marketplace, documentation about Super Protocol, and NVIDIA's article about Super Protocol.
- 43:26
Thank you for your time, and we hope to see you leveraging Confidential AI soon with Super Protocol. Have a great day.