Scaling trust in confidential AI requires a common language

Confidential computing changes an important assumption about how trust works in modern infrastructure.

Traditionally, attestation has largely been an internal concern for infrastructure providers. Within a data center, operators can use attestation to check the integrity of servers and determine whether services should be allowed to run or connect to other resources. These trust decisions are important, but they generally remain inside the boundaries of the infrastructure being managed.

AI systems increasingly bring together CPUs, GPUs and other accelerators, firmware, software and services from multiple suppliers. At the same time, more parties have a stake in whether those systems can be trusted. Model providers want assurance that valuable models will run only in appropriately protected environments. Users want confidence that their data remains protected while it is being processed. And infrastructure providers still need to verify the integrity of the underlying platform.

Attestation therefore becomes much more than a server-management function. Trust decisions can occur when workloads are deployed and when individual connections are made. And the information required to make those decisions can come from many different places across the hardware and software supply chain.

These factors create a scaling problem the industry needs to address.

When every component speaks a different language

At its simplest, remote attestation allows a system to produce evidence about its identity and state so that another party can decide whether it should be trusted. But evidence alone is not enough.

A verifier also needs authoritative information against which that evidence can be evaluated. This can include endorsements establishing information about hardware, or reference values describing the expected state of firmware and software.

In a heterogeneous AI system, those sources may come from multiple suppliers. One component could require one mechanism for finding the information needed to verify it, while another component uses something entirely different.

Multiply those differences across CPUs, accelerators, roots of trust, firmware, software and potentially many different platform configurations, and system builders quickly face an integration tax: an expanding collection of vendor-specific interfaces, formats and sources that each verifier must understand.

The problem becomes even more pronounced because multiple verifiers may be also involved. Some may operate as remote services. Others may run locally inside an application or endpoint.

Without a common way to connect those verifiers with the information they need, every new combination of components and suppliers risks creating another bespoke integration. And that’s difficult to scale.

Building a common foundation for attestation

A more sustainable model is to give the ecosystem a common way to discover and retrieve the endorsements and reference values required to make attestation decisions.

That is the problem being addressed through the Internet Engineering Task Force’s Remote ATtestation procedureS, or RATS, working group.

RATS provides a common architectural framework for attestation and develops standards around the formats, interaction models and mechanisms needed to make different parts of that architecture work together. Rather than solving individual attestation problems independently, the objective is to establish interoperable building blocks that can be combined across implementations.

Working to this model, the RATS working group has created standards at different stages maturity and adoption, including the Entity Attestation Token (EAT) and the Concise Reference Integrity Manifest (CoRIM). So far, the focus has been on data formats and broad interaction patterns. However, to address these challenges of diversity and scale, and to create a truly interoperable ecosystem, we need to go further. We need to define complete APIs.

 CoSERV, the Concise Selector for Endorsements and Reference Values, is an important new step forward. CoSERV is an adopted work item within the IETF RATS working group designed to provide a common conveyance mechanism through which verifiers can obtain endorsements and reference values from potentially complex supply-chain sources.

The important idea is not to dictate how every supplier creates its trust information. It is to provide a more uniform way for verifiers to get the information they need.

Through a single API, a verifier can query for relevant artifacts, collect them into useful bundles and cache them for appropriate periods. Standard HTTP caching semantics can also reduce unnecessary network traffic for artifacts that may be used frequently but change relatively infrequently.

For developers building attestation infrastructure, that common layer has the potential to replace many point-to-point integrations with reusable tools and interfaces.

And for the wider ecosystem, it provides something equally important: a common language through which different parts of an increasingly diverse computing supply chain can participate in trust.

From standards to running code

Standards are only useful if they work in real implementations. That is why the work does not stop with specifications.

Arm, Fujitsu, Linaro and others across the ecosystem are also working through Veraison, an open-source project that provides both a proving ground for emerging attestation standards and reusable software components for developers building attestation systems.

This creates an important feedback loop. Standards can inform open-source implementation. Implementation can uncover practical questions or requirements that are difficult to identify from specifications alone. Those lessons can then help the industry refine the standards before they become widely deployed.

The result is a model in which standards development and open-source engineering reinforce one another rather than happening in isolation.

That is particularly important for work such as CoSERV, which is still evolving. Its pre-RFC status means the specification is not yet finalized. But it also means there is still an opportunity for vendors and implementers to test the approach, bring forward real-world requirements and help shape how it develops.

Trust has to scale with the system

Confidential AI is one example of a broader change underway across computing.

Systems are becoming increasingly heterogeneous. Hardware and software supply chains are becoming more complex. And trust can no longer depend on every vendor, platform and verifier building one-off connections to every other participant.

Attestation needs to scale along with the systems it is protecting.

That will require more than strong roots of trust or secure individual components. It will also require shared mechanisms that allow those components, their suppliers and the parties verifying them to work together.

The work underway through IETF RATS, CoSERV and Veraison points toward that model: open standards defining common interfaces, backed by open-source implementations that demonstrate how those standards can work in practice.

At OCP, Arm and Fujitsu are sharing more about that effort and why a common approach to endorsement and reference-value distribution matters for the future of confidential computing and confidential AI.

Because as the computing ecosystem becomes more diverse, the mechanisms we use to establish trust need to become more interoperable, not less.