Future of confidential infrastructure & why we're betting on Intel TDX

Most infrastructure security models still assume one thing:

If an attacker gains physical access to the machine, the game is already over.

At the edge, that assumption becomes a real problem.

Servers end up in remote offices, retail stores, factories, vehicles, branch locations, tactical environments, and third-party facilities where physical control is limited or inconsistent. Even inside traditional datacenters, infrastructure is increasingly shared between operators, tenants, vendors, and automation systems that do not fully trust one another.

That changes the threat model.

One of the most overlooked risks in distributed infrastructure is cold memory extraction.

If an attacker can physically access a machine, memory contents can potentially be extracted, analyzed, or moved into another system for inspection. Historically, once sensitive data reached DRAM, protecting it became much harder. Encryption at rest protects disks. TLS protects data in transit. But data in use, workloads actively executing in memory, remained exposed to privileged infrastructure layers and physical attack scenarios.

That is exactly the problem confidential computing is designed to address.

And it is why we believe Intel TDX represents one of the most important infrastructure security shifts happening right now.

What Intel TDX actually changes

Intel Trust Domain Extensions, or TDX, creates hardware-isolated virtual machines called Trust Domains.

Inside those trust domains:

• VM memory is encrypted in hardware
• CPU state is protected
• The hypervisor is removed from the trusted computing boundary
• Memory contents cannot simply be read directly from the host
• Remote attestation can verify workload integrity before execution

This matters because traditional virtualization implicitly trusted the host itself. If the hypervisor or host OS became compromised, workloads running on top of it were exposed as well.

TDX narrows that trust boundary substantially.

For edge infrastructure, this becomes especially important in scenarios involving:

• physically accessible infrastructure
• hostile environments
• remote deployments
• sovereign workloads
• regulated AI systems
• defense and intelligence workloads

The workload becomes cryptographically isolated from much of the surrounding infrastructure.

That is a major architectural shift.

Why this matters for AI

AI infrastructure makes the problem even more urgent.

Models, embeddings, inference pipelines, and sensitive datasets increasingly run outside centralized datacenters. Organizations want AI inference happening closer to where data is generated: factories, hospitals, branch offices, retail environments, field deployments, and tactical systems.

But those environments often have weaker physical security guarantees.

Confidential computing allows organizations to protect workloads even when the surrounding infrastructure environment cannot be fully trusted.

That is a very different security posture than traditional virtualization.

What TDX-Connect is trying to solve

Today, confidential computing mostly protects CPU memory and VM execution boundaries.

But modern systems are larger than CPUs.

Workloads interact with GPUs, accelerators, NICs, PCIe devices, storage controllers, and increasingly complex composable hardware architectures. As AI infrastructure grows, those device trust boundaries become just as important as the VM itself.

That is where TDX-Connect enters the picture.

TDX-Connect is designed to securely identify, authenticate, and establish trusted communication with accelerators and devices connected to confidential workloads.

The important shift is this:

TDX-Connect extends confidential computing trust models beyond just encrypted VM memory.

It begins establishing cryptographically verifiable trust relationships between the confidential VM and attached hardware devices such as accelerators, GPUs, and I/O subsystems.

In practical terms, this matters because future confidential workloads, especially AI workloads, will depend heavily on devices outside the CPU trust boundary.

Protecting only system RAM is no longer enough.

The industry is moving toward infrastructure where:

• accelerators participate in attestation flows
• devices establish verified identities
• workloads can verify hardware trust before attaching resources
• secure communication channels extend across the broader platform
• confidential computing spans more of the actual machine, not just the VM boundary

That is an important evolution for real-world confidential infrastructure.

Why we're working closely with Intel

We believe Intel is approaching confidential computing as infrastructure, not as a niche security feature.

That distinction matters.

A lot of security technologies remain difficult to operationalize because they require specialized expertise, fragmented tooling, or entirely separate deployment models.

Intel's direction with TDX is different.

The ecosystem is moving toward making confidential workloads operationally deployable at scale:

• standard virtualization models
• hardware-backed attestation
• confidential AI infrastructure
• trusted accelerator integration
• workload portability
• orchestration-aware trust models

That aligns closely with how we think about Starlight.

Where Starlight is going

At Mainsail, we do not think confidential computing should feel exotic.

Operators should not need to become firmware engineers or hardware security specialists just to deploy protected workloads.

Long term, we believe confidential infrastructure should become automatic:

• hardware capabilities discovered automatically
• confidential workloads scheduled automatically
• attestation handled natively
• trust-aware placement integrated into orchestration
• secure accelerators attached transparently
• protected execution enabled by default where hardware supports it

As TDX-Connect matures, we expect Starlight to align closely with that ecosystem and support the broader confidential infrastructure model Intel is building toward.