The keynote claims up front that this is tied to making AI workloads secure and confidential.

This is a global conference with viewers in Europe, Africa, United States, and more.

Edgeless Systems CEO comes on stage to briefly introduce himself and why this event is a thing. It started in 2021 when confidential computing was niche. This conference is to highlight use cases and techniques.

A focus on a "Truly Sovereign cloud environment". Speakers include OVH, Microsoft, and Google.

Data at rest, data in flight, and our focus, data in execution security. Several talks will be about attestation. Nvidia will be on stage too. Later Anthropic and Intel.

Hardware based "Confidential Accelerators" will be a thing soon.

• Confidential inference
• Confidential agents

The crypto currency and web3 community are early adopters of this technology too.

Edgeless is promoting their own OpenAI compatible API for confidential computing on open source models like GPT OSS, Kimi, and Qwen. (Only GPT OSS was demoed)

He sets up a private mode proxy that verifies the integrity of the backend and sets up a local endpoint that local AI tooling can talk to. His demo shows OpenCode working against the Edgeless Systems API to do agentic work.

As always with tradition, the live demo with OpenClaw failed over telegram. "Connection error." He steps off and an OVH cloud founder steps on stage (Octave Klaba).

#On building a global cloud champion – with confidential computing done right by Octave Klaba OVH Cloud#

I think I heard him say that OVH allows their customers to build up their own "cloud" in OVH. Europe having its own cloud providers is worth highlighting.

Reiterates that confidentialy needs to be offered everywhere (at rest, in transit, in execution). Encryption is happening between components too, like the CPU and along the PCI Express bus.

OVH's goal is to make the complex stuff managed away so customers can focus on their part.

Sovereignty is not a new concept to OVH. We need computers to work together, but allow isolation between countries. When you go outside of Europe (US, Canada, Singapore, and so on). Some things are forbidden in France that is allowed in Spain.

Need to be a "multi-local player", need to be able to respect the local laws at each site.

Using different subsidiaries for each country to operate with separate entities for legal vs operational. Operationally they're isolated. When you're subscribing to OVH, they have different backends (Europe, Canada, USA) for accounts too.

American companies are saying you don't need all this isolation. We have these technologies to do isolation. Where are the keys? Who has access to the keys? Who can dump them?

Zero trust infrastructure is where people are going and it's really hard to deliver this in a good way. Reading in between the lines, countries should not be able to dump data for another country.

OVH says they're not there yet. Confidential Computing is an essential step to get there.

"Is Confidential AI going to be the next big thing?" OVH responds with partnering with Edgeless to see if they can get workloads like this. Also says "Europe has a lot of talented people. We need to work together. Here in Europe, we are good also." The original question wasn't directly answered.

"Can you talk about the partnership with Edgeless systems?" "No, it is confidential. But it's really exciting."

"When can you communicate more?" "The goal is to bring the technologies together in a sensitive context to extend the data sensors, but the data is so sensitive that you can't do it today." I think he approximately meant "We can't scale the data processing because the data is so sensitive and we don't have the tools yet to operate confidentially at that scale."

#Regulations and standards for Confidential Computing by Mike Bursell through the Confidential Computing Consortium.#

If you're here, or online, you should be a member of the Confidential Computing Consortium because you care.

Why regulations and standards, why should we care about it? They lead to adoption. Regulations make requirements. Standards lead to implementations and ... auditors! There's an interplay between regulations and standards.

About Regulators and Regulations. National bodies, international bodies, and sector specific bodies set standards that implementors follow.

"Who's had to do PCI-DSS?" (Me!) "Don't be too happy about it, some of the rules are literally my fault." (That's okay.)

When we're thinking about what regulations to apply ... how do we know which ones we need to care about?

Standards tend to be reactive. Knee-jerk regulations can be flawed. "Particularly those which point at standards."

Regulators MUST and SHOULD (in the rfc sense). Watch what you should do before the regulations are in place

Sectors interested in confidential computing: finance, health care, digital sovereignty, agentic ai, data privacy, national security. The regulations aren't aligned at the moment with where the technologies are.

"Who thought Web3 had gone away? We're seeing a lot of interest in distributed Web3 type approaches for digital sovereignty and AI use cases. Crypto currencies have not gone away and Web3 has not gone away. Data privacy .. boring GDPR stuff, is vital for businesses and consumers. The original GDPR talks about data at rest, not as much for data in use."

"AI isn't just agentic AI. It is broader than that." (Agreed.)

Standards and Standards Bodies.

Regulations are easier to drive with standards, like IETF for network protocols, W3C for the application layer, ISO is a very large umbrella. ISO feels confidential computing is in scope for them. NIST is easy to engage with when it comes to security. Many bodies follow what NIST does, like Quantum-resistant cryptography.

There's also overlap between organizations, especially national standards bodies (like ETSI, ANSSI, NIST).

Technical standards are especially important in protocols, storage, networking, key exchange, attestation, trusted execution environments (and the ability to compose them). If you come to remote attestation as a noob, it is a very complex thing to understand.

GPU makers and CPU makers are all focused on their own little world. Coordinating between them is still a real challenge. We're going to see them everywhere soon.

"What is a CC-enabled app?" a confidential computing enabled app. Folks want to be able to sell apps that work which rely on confidential computing.

We don't have a formal definition of what a hardware based trusted execution environment is! So we can't stamp approval on things if we can't audit and sign off on them.

We don't need just standards experts, not just legal experts, not just technology experts. We need all of them. An invite to join in the committee.

He diffused a long venting thread from an audience member: "This is not the forum to address this. Any other questions, thank you."

"Not any one body knows what everyone needs."

"We've actually done quite a lot of work with standards bodies. There's a lot going. We have a lot of starting points. The question is what's next. We don't set the standards ourselves, we work with the IETF and [another] for setting them."

#Building the Trust Fabric for AI Agents by Ian Petrov & Patrick McGrath with Google Deepmind#

They plan to talk about MCP, bringing trust into the MCP ecosystem, and a demo at the end.

With a lot of conveniences comes several challenges, like data leakages.

MCP doesn't have a good credential story either. Especially if you have a gateway that unifies MCP services through a large one.

Tool descriptions can be edited to inject information too, or to pretend to be another tool entirely.

"Yes, we are now living in a world where text files are dangerous."

The MCP community is trending towards a central MCP registry. Even in this case, it is hard to verify the descriptions match the real service.

The next attack is "Tool Shadowing" where one tool says to use another tool afterwards to leak information.

MCP also allows for dynamic tool updates, so the descriptions can change after you first connect. Malicious descriptions can come over later.

Project Oak is a deepmind project about reasoning how data is processed on the server side.

The first obvious step is to make an accountable version of MCP.

Building MCP servers and tools that run in an Trusted Execution Environment with a transparency log on MCP configurations.

Patrick takes over the presentation about the implementation.

Oak Functions is a prototype built on wasm for execution and sqlite for data (read only), which is then run inside a TEE. The executioner can't guess what was queried (the input was processed confidentially) as the database was also encrypted to only be openable in the TEE.

Then a what if we have a MCP registry that only connects to TEE MCP servers?

The demo comes up next, I'll spare the screenshots. They were talking much faster than the information density on each slide.

Naturally they're using the gemeni CLI with their Oak Proxy. Gemeni then leverages the oak proxy to access oak functions to query.

Oak Functions appears to be a rust program that runs in a docker image that you can run in a confidential space. They show in the demo that the proxy will refuse to connect to an oak function when it can't be verified. It could not be trusted because the host was running a container that was not expected in the environment.

#Privatemode: Lessons learned from one year of running confidential AI in production by Moritz Eckert with Edgeless Systems#

A return to the conference intro slides.

They run open source models in a confidential computing environment. That's Privatemode. Encrypted confidential inference.

One of the hard problems of this is how agents are naturally stateful processes. They come back again and again as the context grows. Should you operate statelessly, the model has to run all the activtaions again. Other platforms use prefix caching, however this is a risk if someone else knows the prefix (the conversation history up until that point) and can measure it by it processing faster.

Their solution was to have a tenant specific prefix in the input at the start that others cannot adjust before it gets processed.

Another challenge was ensuring the connection remains confidential end to end too. They discussed an HPKE (see IETF RFC 9180) between the client and the inference endpoint.

They use a wasm module to offer the private mode SDK within the web browser. chat.privatemode.ai is available to see how it works.

What about performance? The Nvidia Hopper sets up a symmetric encrypted channel (AES probably) between the CPU and GPU, however it did not include encryption between GPUs.

Since Hopper, Blackwell launched that focused more on the encryption between protected GPU memory across cards.

With blackwell, they're able to operate larger models since they need to run across multiple GPUs and TDISP supports encryption between direct or switched GPU links.

Blackwell is expected in March 26 or so, it isn't out yet.

#Confidential Computing at Google Scale: An Inside Look by Will Grannis with Google Cloud#

This is a prerecorded video instead of being in person. Too bad! Also highly edited.

Nvidia is credited as the first to bring confidential computing the GPUs.

Global and industry specific standards and regulations comes up again as a serious consideration.

"Protecting data in-use" as well as tenant isolation (both in information security and performance) is their current focus. "Hardened VMs" is their answer. They're dog fooding confidential computing at google cloud to make sure its good enough to offer to the world.

"Confidential compute is more than hardened data centers." He shifts to talking about smartphones and the secure enclaves on them.

They're working to run Gemeni models on hardware that is fully attested to run confidential compute.

They see their work (and the community's work) in confidential computing to be important for protecting and securing people across the world.

#Late join to Memory Interposer Attacks: Out of scope, but not out of mind by Simon Johnson with Intel#

He began his talk about how the usage of secure tools follows along with the difficulty of using those tools. The story he told was about something NATO was doing and how several countries came together, one could do it in two clicks, another took twenty (or thirty) nine clicks. "Guess who used the tool most?" was obvious.

(The google cloud session happened here, so I don't have any notes in between)

Post Quantum Cryptography time!

They're working on memory encryption at 256 bits, SHA-384 hashes of components, implementing ML-DSA and ML-KEM by 2030 in hardware.

It seems Intel isn't shy about using AI generated imagery in their slides.

The elephant in the room: physical probes between memory and the CPU. The industry relies on AES-XTS that he describes as a "codebook" (sounds more like ECB). The key can be tweaked by an address (the XTS part).

"You had something that could solve it." "However, you had to do three memory reads for every memory write. You had to use twenty five percent of the memory to store counters and trees."

"I would like you to give me twenty five percent of your memory to store a tree." In other words, the solution they had to get all the protections was too wasteful.

Intel can say a relying party's stuff is running in a TEE. "Platform Owner Endorsement" is their way to say "And your code is running on this platform".

It sounds like they're moving away from SGX. It gets too much attention from attackers.

They are also concerned about Xeon processors (up to 192 cores) bottlenecking and contending (a few micro seconds vs nano seconds) to get attestations from local hardware.

AES-XTS adds about a 10% overhead to memory accesses. They expect that DDR6 will support additional metadata (that they could use in the tweak to AES-XTS).

AES engines take a lot of gates too.

Google and Microsoft found neat ways to discover bugs using AI accelerated research against Intel. Security assurance is changing with intelligent fuzzing.

"We're not done. There's still lots of innovation to come. We have a profile of what we can protect today. [There is so much more to do.]"

#Pushing the Boundaries of AI Workloads to Where by Daniel Roher with Nvidia#

Nvidia is helping solve 10x year over year model growth.

While tokens are getting cheaper to execute, the thinking and agentic deployments is driving up the demand for AI compute. There's a lot of competition to reduce token cost while increasing effective intelligence.

2022, they had Hopper to do confidential compute on a single GPU. Now with Blackwell, they can run a trillion parameter model in a fully confidential manner.

Many people don't realize that Arm CCA (the first arm based confidential compute chip?) 72 node confidential compute with end to end compute.

"We have an ambition to be an entire data center scale [doing confidential compute]."

A focus on lower latency on encryption's overhead without being limited by scale. It needs to be accessible too.

CUDA was pronounced as "Kuh-dah". Neat.

"Just in the latest generation, we've improved 5x with mostly software improvements in the stack." The experts that know their hardware are writing better software to use what's there.

A lot of agentic work is container shaped.

Links at the end:

Every server you buy today has a confidential compute enabled processor in it. Start pushing your data through it, take advantage of this technology.

#Remote Attestation of Imutable Operating Systems built on systemd by Lennart Poettering with Amutable#

The hardware has been there (like TPMs) to do attestation for a long time, though in practice the technologies to use these haven't been accessible or used widely by distributions.

SystemD cares about the whole ecosystem, not just one application or line of operating systems.

They want to "build the OS" a bit different from how the OS is typically built. Compose the OS with images (in the docker container sense) with each layer being attested. The linux kernel is ready to do immutable file systems.

They also want to stay close to the standards, like UEFI and TPMs. All the early boot stuff before the OS so they can say truthfully that it is end to end in scope.

"UKI" or "Unified Kernel Images" which have layers that can be signed ind installed as "one thing". Encrypted layers that go on /etc for example as extensions specific to the use case. "Verity enabled disk image" with overlayfs. And more on machine identities.

Lots more things to come, like recording if a volume was unlocked by TPM or by a user token, as well as if a human user connects into a system to debug things. "Break glass moment."

(I recall that it's a cumbersome / very loud / impossible process for Google to get into a machine running a customer workload.)

Platform Configuration Register (PCRs) are getting scarce. There are three that can be used, more could be added by users. "One or two, you should be able to do." "If you have a software TPM, you can do a lot more."

A "Cryptographic Locked Loop" around making extension images (and their activation) accountable.

(It sounds closer to a transparency log, honestly.)

Virtual TPMs are desirable. They don't want lock in to specific vendors. It is really painful to deal with PCRs on hardware TPMs tied to vendors.

#AWS EC2 Confidential Compute Options: Choosing the Right Protection for Your Workloads with Alexander Graf with AWS#

Alexander works on the EC2 nitro division. The underlying concept is keeping data contained during execution. The platform, the operators, shouldn't have access to the data. "I can deploy the code. I can trust the code, but not the person who runs the code."

Don't expose SSH! It has te bo non-interactive. The APIs need to be well defined so any and all operations are guaranteed to perform what they're supposed to, and not exfiltrate data.

Customers are asking about "memory encryption" too. DRAM needs refresh cycles, except when literally frozen with liquid nitrogen. They want to protect against the improbable adversary that breaks into a guarded data center, finding the exact server the workload is running on, breaks into the server, freezes it, and then pulls the stick out to retrieve its contents.

Even in this absurd user story, every instance starting six generations ago... [the main stage just got disconnected and the conference chat gets bothered].

According to Data Protection in EC2, Graviton 2 they have always on memory encryption, while Intel servers use Intel Total Memory Encryption and AMD provides AMD Secure Memory Encryption.

Unfortunately the stream was brought back just as the session ended.

#COCONUT – Beyond Secure Service Modules by Jörg Rödel with AMD#

This is a project prioritizes security over performance.

It's something between a hypervisor and guest OS. The virtual TPM runs inside a trusted environment.

(Another focus on virtual TPMs it seems.)

AMD wants to move COCONUT into a "Paravisor", a proxy between a confidential virtual machine and the host OS.

The use of "enlightened" word when labeleing an OS comes up again. My concurrent research here suggests this is about informing (enlightening?) a guest OS that it has a virtual TPM.

COCONUT is a kernel from the ground up for confidential computing. Small footprint, aimed to be general purpose. Why not run small workloads on COCONUT directly?

Rust software should be able to target it. They have support for the rust standard library on it.

Alternatively, they can implement enough linux system calls to run small workloads for support for other languages. Not 100% compatible. The aim is to develop and iterate on a linux environment and then verify on a COCONUT environment.

With a custom kernel, it's easier to attest to everything and start up to execute the workload.

AMD invites review of this to see what the community thinks.

(I think the systemd approach will be more successful, outside of cloud environments like nitro.)

"How do you decide on the syscalls you support?" "Not about being POSIX compliant – more about the things applications actually use like timing calls, file system calls, memory mapping and similar."

"Why not create a runtime for WASM?" "That's also possible. A runtime that can run WASM workloads is possible. There's a rust [crate] for this."

#Tech Leaders Panel by Daniel, Anand, Ravi, and Mark (Nvidia, Intel, AMD, Microsoft Azure respectively)#

A pre-recorded with tech leaders from , where everyone's logos were mirrored in the video feeds.

First question from Felix (the moderator or host): "What's holding us back?"

They lack gpu to gpu confidentiality fabric. "We don't have the CPU to GPU hardware acceleration." "We're in the early phase of confidential AI."

What's being worked on now? The complexities of making hardware platforms and providing application designs that can take advantage of it. Including attestation for confidential workloads.

"It used to be a lot harder to convince people of confidential AI." Now people want it as the hardware is coming, though it is not coming right now.

Anand recounts how the threat pictures people keep talking about are getting physical access to servers. That's a solved problem. The focus is shifting towards threats and risks that are more real like breaking TEE guarantees. The dominant threats that customers should care about should be closer to the software they produce. It is not a magic forcefield that can be turned on and forgot about. Customer programs need clear update processes and secure design to manage risk.

"What's the role of confidential computing in data sovereignty?"

Daniel: "Its about giving agency and control to data owners with how their workloads operate. Confidential computing builds out primitives that (through components like attestation) enable all sorts of local needs." Confidential computing allows data owners to decide who and what they trust.

Ravi: "It's not just where it's located. Who controls the data? Who has access to the data? Who can verify [the data's integrity] and handling? That defines data sovereignty."

Anand: "Location isn't enough. The technology of confidential computing is being used now too to secure data."

Daniel: "We're trying to provide a lively ecosystem to build things between data owners and the hardware they own."

"Is confidential computing largely a cloud technology or on prem or edge use case?"

Ravi: "Customers are trying things out in the cloud first. It leads in the cloud. Then they take it to on-prem. Though it's not a mere copy over. There are different regulations they need to work within too." When it comes to data footprint, they are going to scale their data on prem, not in the cloud. However, to learn and lean into it, they can get the latest things in the cloud.

Mark: "This transition is not complete. Not everything is in the cloud. Some workloads are on prem while others are on the cloud. Regulatory pressures can keep data out of the cloud.

It's not a question of how much, just when. It'll be adopted across all the clouds "with the people on this call".

Daniel: "No one likes to be asked to learn fiddly crypto to get their job done."

Felix: "I'd like to close this with a round robin question. If you're sitting here again next year and you look back, what you say the tipping point [is for its success]"

Anand: The tipping point is when it is seen changing a risk reduction technology to an AI-enabling technology.

Ravi: "There is no more computing, and confidential computing. It is [implied] confidential computing everywhere. It is what everyone will trust."

Daniel: The accessibility of the CC-enabled hardware is ubiquitous and not in the way of creating new and interesting applications. CC brings security as a feature-add.

Mark: We see confidential computing being discussed across all enterprises. The last tipping point was data sovereignty being equivalent to confidential computing. The next one is eliminating the performance overheads and remove the scaling overheads. The hardware Nvidia is bringing to market is changing that now. The default will become confidential computing.

Felix thanks the leaders for their discussion.

#Hermetik - An “Operating System” for Cross-Company Collaboration by Sven Trieflinger with Bosch Business Innovations#

Security, Compliance, and Trust.

Not the big Bosch company, this is a smaller one that Bosch seems to fund.

Coming from the automotive industry. Integration cycles are super long, up to 100x longer than the IT industry. 30% of logistic miles driven have empty trucks. Very wasteful.

We need to move towards a strategy with shorter cycles while staying secure. Usability needs to be a first principal. (I reflect on the NATO mention earlier)

We have to provide a trustworthy neutral ground that supports rather than impedes.

The system under control is managed like infrastructure as code that is mutually reviewed and approved. This provides an audit trail too. Also describing what governance is applied through code and infrastructure.

Hermetik is an implementation built on top of a kubernetes cluster with confidential containers.

What use cases do they have in mind? Securing intellectual property while enabling collaboration.

Its a CI system of sorts that allows components from both sides to test and integrate with one another on a mutually trusted platform.

Essentially, they want to enable cross-company debugging without sharing source code. Currently they meet in an air gapped room to debug things together.

This environment also have provable provenance through TEEs in the platform.

Their CI layer is built on Tekton.

#Confidential Computing on the Scaling Laws Curve by Jason Clinton with Anthropic #

Thinking about ways we can use confidential computing to do both model weight protections and data inference confidentiality. Things they're seeing to be aware of:

• Scaling laws
• Threat landscape
• CoCo (Confidential Computing)
• The latest tech to defend against threats

Models are getting 4x compute (and research?) year over year into them (to train them)

Concern for enabling (especially foreign) threat actors

They did this by getting around their jailbreak defenses. They augment the defenses and try to shut down the abusive actors.

The People's Republic of China attack was especially agentic. Used careful context management to separate inputs enough to avoid detection.

(Unfortunately my editor lost 45 minutes of my notes once I went to push my draft online. The following is a reproduction with the screenshots I had on disk and the memories I had while it was fresh.)

By spreading the work across several sessions, across several accounts, with layers of indirection, the threat actor was able to automate a lot of black hat research against someone using Claude to direct and orchestrate it all.

Claude is being used for good too. Recently Anthropic partnered with Mozilla to do analysis over their codebase.

The way Anthropic is seeing the world focuses on two areas with regard to confidentiality: model weights and user data.

Anthropic is deeply concerned about insider threats leaking the weights. Once the weights are out – which are proven to be quite powerful in the wrong hands – they can't be taken back. In fact, most of the presentation following this follows an emphasis against leaking the model weights.

Claude is deployed to heterogeneous environments too, which makes this concern even more problematic to deploy in practice. Not all data centers have the same chips, the same security and confidentiality guarantees, or even the same architecture.

Anthropic's Responsible Scaling Policy ties security requirements to model capability.

ASL-3 and beyond: We commit to preventing model weight theft by increasingly capable adversaries as model risk increases.

Confidential computing is not optional infrastructure — it is a necessary component of keeping that commitment as threat actors scale their efforts alongside our models.

Like PCI DSS, it is ideal if you shrink the scope of what is certified and audited. Anthropic focused on the interface between the outside world and the engine that executed against the encrypted weights.

The trusted loader was only "A few hundred megabytes" while everything around it, apart from the weights would be "several gigabytes". It would be much more difficult to constantly attest to every artifact on heterogeneous environments.

Like Google, Anthropic prohibits runtime execution from an outside agent (person or automated). The server must be attested to even unlock the model weights anyway, which is described next:

A server does not get to unlock the weights unless the trusted hardware attests from start to runtime that everything is in order with the expected software.

Once again, Jason Clinton repeated how important it is for insider threats to never get access to the weights. An insider or outsider will also be so bandwidth constrained (tokens do not take much bandwidth – weights do) so even if this trusted application that interfaces with the accelerated inference hardware leaks weights, the weights cannot be exfiltrated within a working timeframe to provide value.

Anthropic appears to be looking forward to more gpu to gpu confidentiality, something Broadwill will bring (and oh my how many data centers will need the newest chips to sate Anthropic and OpenAI.)

Naturally, Anthropic dog foods its best model to do code review, both for its own code and the code it imports as a dependency. (This might also be why they bought Bun. They can control the very runtime they're shipping to customers for when they eventually get trusted execution on customer machines too.)

At the ending, he reminds us to pay attention to how much is going into each model in its training and inference.

#Device Attestation, Confidential Identity, and Generic vTPM Support in Trustee by Tobin Feldmann-Fitzhum with Nvidia#

This is the last presentation of the conference on the main stage.

Tobin introduces Trustee, an open source project that both asserts things and verifies things as a relying party.

Trustee can be on both sides, the host, the guest VM, and the application on the outside that relies on it. They're aiming to reduce friction to enable confidential computing workloads with a setup that is as easy as docker compose up.

Plugins are especially important as the TPM and hardware landscape continues to grow. Evidence collection needs to be attested and the verifier has to also attest that the claims all make sense. For example, copying an attestation from hardware in the past, or another virtual machine could trick a naïve verifier.

All parties in this attestation dance need to be sure the resources that confidential workloads are deployed to are in fact what they're deciding on.

Tobin spends some time describing the various cases, like evidence coming from an entirely different guest virtual machine, or another GPU in the same machine, or another device in an entirely different machine. The whole set of information must be verified as a bundle.

He then shifts to talk about identity and identifiers.

It is easier to talk about identifiers, concrete things. Less so about identity which is not so well defined.

In fact, identifiers are "just a string" that has meaning in another system's context. It is also another thing to attest to the identifier from the other system. Are we sure that drivers license number exists, actually?

We pivot back to the identity of machines.

Often the identity of a confidential computing worker is hash detached from the information that went into the hash.

The solution is to have a way to look back up the info tied to a hash based identity. This information can be tacked on in an extension. (I am reminded of X.509 extensions.)

He shifts back towards the end back to virtual TPMs. This process or concept is safe from the Paravisor and host. It can't manipulate or record what it is computing.

He ends the discussion by saying something like "A few years ago, creating an attestation service was all about getting a signature from the CPU. It was easy then. I do not recommend you start now. Attestation is much more than saying you can run workloads inside SGX.

He invites contributions to this project and recommends joining the CNCF workspace to talk and contribute.

That's the end of Open Confidential Computing Conference!

#My thoughts#

That was a lot of information to take in. I've attended for several years now. I heard "enlightened" several times last year and looked it up again this year. They also discussed again and again how it will be useful in AI though they weren't able to articulate back then the clarity they have now in its relevancy. Three years ago, all they talked about were use cases in crypto currency workloads. This trend seems far more constructive and less theoretical as the scene evolves.

The next keyword to watch out for is "CoCo" for Confidential Computing. Speakers didn't make the first time. I only made this connection towards the very end of the conference.

I noticed that OpenAI didn't have a place at the conference.

This conference takes place in Germany, so many European opinions are expressed throughout. They seem wary of all United States based cloud providers. This puts model authors like Anthropic in a difficult spot. The workloads need to be confidential too and hyper local where possible to abide by data processing laws that are being enacted.

I personally suspect that open-weight models will remain a priority for European government and health data. Given the direction US labs are going, it doesn't look like capable open source models will be released from US sources. Europe's Mistral's AI capabilities are a joke compared to the models coming out of China and Google's Gemma series.

It won't be enough to "Trust Anthropic" to do the right thing when they're being threatened by the United States government. Similarly, trusting AWS and Amazon to keep data local seems to be a regularly broken promise when an outage in US-EAST-1 affects data centers across the globe.

OVH directed the spot light onto themselves to highlight how they isolate tenants based on the tenant's legal jurisdiction, in addition to the geographic jurisdiction where workloads are executed.

At the same time, I'm reminded of the OVH fire that happened while one of my family members was in town:

Europe will need to seriously inspect and verify OVH tells the truth when they claim something. A mistake of this scale that truly disrupted and destroyed entire businesses (because their backups were in "another region") cannot happen again. I have doubts that Europe will be investing more into AI at this critical time when all their post world war 2 infrastructure is crumbling.

Anyway, I appreciate how confidential computing appears far more "real" than a concept that Web3 latched onto. Before it was DRM, then Web3, and now with good reason: inference confidentiality.

While the hope is that inference eventually becomes confidential, I have to wonder: how are they going to detect abuse like threat actors breaking into utility grids with their weights and infrastructure?

Thanks for hosting the conference again, Edgeless. I look forward to what the next year brings. The AI ride is wild.