When it comes to processing sensitive data in the cloud, Confidential Computing has become the gold standard. By keeping data encrypted even while it’s actively being processed inside hardware-based Trusted Execution Environments (TEEs), it allows organizations to run sensitive workloads in untrusted cloud environments without losing control.
However, as workloads evolve, especially with the explosive rise of AI and complex data-sharing ecosystems, new security and privacy challenges naturally emerge.
To help solve these emerging hurdles, the Confidential Computing Consortium (CCC) is excited to announce $91,000 in research grants awarded through our Academic Research Grant program! Chosen from a competitive pool of 35 proposals across 32 organizations, two standout university projects are receiving $45,500 each in unrestricted funding.
Here’s a look at the two cutting-edge projects and how they plan to make confidential computing even safer and more robust.
The Winning Research Projects
1. Securing AI at Scale: Leakage-Aware Security in Confidential GPU LLM Serving
Researchers: David Oswald and Qifan Wang (Durham University)
The Challenge: As Large Language Models (LLMs) move into TEEs, particularly via confidential GPUs, we need to ensure side-channel attacks can’t compromise privacy.
The Project: This research dives into Key-Value (KV) cache management in confidential GPU LLM serving under a standard threat model (e.g., a malicious cloud host). The team is analyzing whether side-channel observations, such as operation timing or power measurements, could accidentally leak prompt details, prompt lengths, or request boundaries. Identifying these potential leakages is a critical step toward fully securing AI workloads in the cloud.
2. Beyond Data Isolation: Verifiable Privacy Policy Enforcement with Deko
Researcher: Chenghong Wang (Indiana University)
The Challenge: While TEEs are fantastic at protecting data in use, hardware isolation alone doesn’t automatically prove that a dataset was processed according to specific, agreed-upon privacy governance policies.
The Project: Enter Deko, a hardware-software co-design built for Confidential Virtual Machines (CVMs). Deko enables end-to-end verifiable data provenance. With Deko, data owners and downstream users can verify the exact methodology and lineage behind a dataset, what inputs were used, which policies were enforced, and how final outputs were generated.
Why This Research Matters
“The projects selected this year reflect the breadth and depth of innovation happening across the confidential computing ecosystem. As confidential computing scales to new workloads like GPU-accelerated AI and privacy-preserving data sharing, rigorous security analysis and verifiable guarantees become more important than ever.” — Mingshen Sun, Program Committee Chair & CCC Governing Board Member
The CCC Academic Research Grant program focuses on three core pillars:
Scaling: Tackling emerging operational challenges in modern environments.
Novel Applications: Expanding privacy-preserving use cases like data sovereignty and transparent data sharing.
Hardening & Verification: Rigorously auditing, analyzing, and verifying TEE security components.
What’s Next?
Once these research projects wrap up, we will publish summary reports detailing their findings and contributions to the open source community. We will also release a new Request for Proposals (RFP) for our next round of grant funding.
Interested in learning more about our research initiatives or submitting a proposal in the future? Head over to the CCC Research Fund Page to explore past work and upcoming opportunities!
Across two days and dozens of sessions, the same conclusion surfaced from cloud providers, silicon vendors, a frontier AI lab, regulators, and nation-state buyers alike. The agentic era arrived faster than the security models built to contain it, and Confidential Computing has crossed from promising primitive to the foundation that production AI, sovereign deployments, and frontier-scale model protection are already being built on.
1. The category quietly redefined itself, from confidential VMs to confidential systems
The center of gravity moved this year, and the language moved with it. The conversation is no longer about confidential VMs in isolation; it is about confidential systems that span CPU, GPU, networking, and storage, all hardware-enforced rather than governed by contract. Google’s Nelly Porter made the case that as AI workloads move across devices and domains, confidentiality has to travel with them end to end, and the arrival of protocols for mutual attestation and encryption between CPUs, GPUs, and AI accelerators is what finally makes that practical at performance parity.
Microsoft’s Mark Russinovich showed where that road leads. After a decade of work, Microsoft has moved its own most sensitive services into Confidential Computing, from token signing, payment processing, licensing keys, not to sell a feature but to protect its own data from its own infrastructure. He framed the journey as a maturity curve that ends somewhere striking. A stage he calls Confidential Tenancy, which aims to take the cloud provider out of the trust equation entirely through a virtual data diode, a one-way gate that gives the customer cryptographic control over what data can ever leave, so even a compromised or compelled provider cannot exfiltrate it. The economic signal underneath is the real headline: the cost, performance, and complexity penalties that once justified avoiding enclaves are on track to disappear this year, which turns “why would we run confidentially” into “why wouldn’t we.”
2. Agents stopped answering and started acting, and the threat model broke
The defining realization of the event was that AI crossed a line from generating answers to taking consequential actions, and the security assumptions underneath did not move with it. AMD’s Hugo Romero opened with a real case. An agent placed in a live environment under a code freeze that acts anyway and deletes a commercial database. Agents now reach for tools, credentials, sensitive data, and APIs on our behalf, so every workflow has to be followed, verified, and attested rather than trusted by default. Mike Bursell of the Confidential Computing Consortium put the consequence plainly: when agentic AI goes wrong, accountability lands on you and your customers, and reactive defenses are too slow to catch it, which is why a hardware-based boundary delivering integrity, confidentiality, and attestation has to be the floor beneath everything built on top.
Monique Dumais, CIO of Capital Group, made the risk concrete and more alarming. The agents she loses sleep over are not the ones her engineers build but the ones her business users build, what she calls rogue IT rather than shadow IT. She has no visibility into whether a non-technical employee has hardcoded a credential into a prompt or pointed an agent at a forbidden data source. Her asks mapped exactly onto what Confidential Computing promises, verifiable execution, enforced data boundaries, runtime policy, and proof that sensitive data was never exposed, paired with a plea that technologists reach legislators before unworkable AI rules harden into law.
The field was also honest about its limits. Raghu Yeluri from Intel made the sharpest version of the point. Proving the same code ran is no longer sufficient, because an agent can execute exactly the right code and still be corrupted by what enters its context, and long-term memory is where attackers will plant dormant manipulations that gradually bend an agent’s objectives and behavior. The question has moved from “did the right code run” to “is this agent doing the right thing, and why, right now.”
3. Identity is the missing primitive, and it describes what, not who
If agents are the new actors, the field’s old notion of identity breaks, and nearly every thread converged on the same fix. Workload-based identity, attesting to what an agent is, its code, configuration, and the policies that let it run, rather than who assigned it. Humans remain the “who,” but confidential, measured, attested workloads become the “what,” and only Confidential Computing makes that distinction enforceable. That work is already underway: the Confidential Computing Consortium’s Trusted Workload Identity Special Interest Group is turning the idea into shared standards.
That carried a hard consequence about governance. Policy enforced by humans clicking “approve” does not scale, because we cannot know what an agent needs to reach or why. The consensus moved from human-in-the-loop to human-on-the-loop, with agents acting as auditors when privileges escalate. Manu Fontaine, founder of Hushmesh, makes a sharp point. To move off the inherited institutional trust the internet runs on, the DNS records, certificate authorities, and privileged insiders, every entity needs a cryptographic identity that is also its key, generated from within and verifiable in hardware rather than granted by any authority. He is not theorizing; the approach is being deployed with NATO’s DIANA accelerator, where zero trust across nations and domains is exactly the problem.
4. The new standard is verifiable, not trustworthy
A striking consensus emerged that the goal is not to be trusted but to be verified, with cryptographic evidence customers can check rather than a vendor’s word, because no single provider should be the sole authority on trust. Amazon’s Matt Wilson made the engineering case, framing his pitch as “trust me, but please verify my work.” He pushed back on a popular piece of the discourse. Software-based and hardware-based execution environments are not opposites, since every real system blends both and all attestation is ultimately implemented in software, so the right bar is to demand rigorous proof that software is sound rather than to wave hardware as a trump card.
Apple’s Ivan Krstić set the ceiling for what verifiable can mean. He laid out a four-level framework for trustworthy AI inference and argued most systems in production today reach at most the first level. His non-negotiable principle was non-targetability, the idea that a system should force an attacker to compromise the entire fleet rather than single out one known user, which makes attacks expensive to scale and strips any leaked data of attribution. Most forward-looking was his demonstration that this bar can be extended onto third-party confidential hardware without lowering it, using multi-party control across vendors so trust is minimized even in the hardware supplier.
5. Sovereignty has a floor, a deadline, and rising stakes
Sovereignty was the connective tissue of the event, and the sharpest insight was about its limits. TII’s Najwa Aaraj drew the line from experience. An organization can own its models, agents, key management, and cryptographic stack and still hit a hard wall at the silicon and infrastructure layer, where true sovereignty stops. That turns sovereignty from a checkbox into a supply-chain question, and points toward provenance you can verify from design through fabrication.
The deadline came from Anthropic’s Jason Clinton, who delivered the sharpest warning of the summit. Advanced cyber capability emerged in a frontier model as an unintended byproduct of training for better coding, and it will eventually reach every model, including open-weights ones. His explicitly personal estimate, that defenders have roughly seven to ten months before an open-weights model carries advanced autonomous cyber capability, turned an abstract risk into a countdown. Use the lead now to harden pipelines, make zero-trust real, and point capable models at your own detection and response. He tied it back to Confidential Computing as the mechanism that lets frontier labs distribute defensive capability to trusted parties without leaking the model to adversaries.
Brittany Kaiser of Alpha Compute named the rising stakes most pointedly, bringing a human-rights lens to a room of engineers. Personal data is the most valuable asset most people own and have never controlled. Confidential Computing, in her framing, is what finally makes ownership enforceable, turning the technology into a front in the larger contest over who holds power in the AI economy.
6. The point of all this is not protection, it is what protection unlocks
For all the talk of threats and defenses, the breakouts reframed the value proposition around what confidentiality makes newly possible. Jonathan Dotan of EQTY Lab offered the most resonant framing of the event: a private conversation is simply a better conversation. When you speak to a lawyer or a prospective employer in confidence, you bring your full and honest self; strip the privacy away and the exchange degrades, so confidentiality becomes not defensive overhead but the precondition for the most valuable AI interactions. He grounded it in the use case that gets him up in the morning, personalized medicine, which requires combining a person’s own data with population-scale data, the only path to capabilities like automated clinical trials, with proofs portable across environments so maximum data can be brought to bear without anyone surrendering control of it. It was the clearest articulation all event of why the Consortium frames confidentiality as an enabler of progress rather than a constraint on it.
Why This Year Felt Different
Underneath the six signals was a single change in tone. The hardware foundation is no longer the thing being argued for. It is the thing being built on, and the honest open problems have moved up the stack, to agent identity, memory integrity, governance at machine speed, and attestation that holds across clouds and on-premises alike. None of these belong to a single company. They are being worked out in the open, across competitors, inside the Confidential Computing Consortium, which is the quiet argument the event kept making: the organizations treating Confidential Computing as the foundation they build on, rather than a feature they bolt on later, are the ones who will still be standing when the window closes.
This recap only scratches the surface of two content rich days. The full keynotes and breakouts, the four-level inference framework, the maturity-curve taxonomy, the frontier-security warning, and the architecture deep-dives, are available on demand.
If you missed any of the sessions you can access the Confidential Computing Summit 2026 sessions here.
By Laura Martinez, Chair of Outreach Committee, Confidential Computing Consortium
Agentic AI is moving faster than most security frameworks were designed to handle, and the organizations deploying it, including some of the most sophisticated enterprises in the world, are navigating new territory. The question isn’t whether your team is experienced enough. It’s whether the security model you’re working with was built for this moment.
The gap traditional security doesn’t reach
The Confidential Computing community has long understood something the broader security world is catching up to: encrypting data at rest and in transit leaves a critical window open. When data is actively being processed, it has to be decrypted. In a standard cloud environment, that moment of computation is exactly when it’s most exposed.
For years, that gap was an acceptable tradeoff. Workloads were bounded. Humans were in the loop. The blast radius of a compromised execution environment was contained.
Agentic AI changes all of that at once.
An AI agent executing autonomously across enterprise infrastructure isn’t a bounded workload. It’s continuously processing sensitive data, calling tools, accessing live data pipelines, and making decisions, all without a human checkpoint, and all inside a cloud environment where the hypervisor, the host operating system, and the cloud operator sit above the workload in the trust hierarchy. The assumption that the infrastructure that traditional security was built on is trustworthy no longer holds when the workload is this autonomous.
Hardware-based Trusted Execution Environments address this directly. By creating isolated execution environments where memory is encrypted and managed at the CPU level, they make the underlying infrastructure irrelevant to the trust model. The hypervisor, the host OS, and the cloud operator are no longer in the trust boundary. The silicon is.
Why the GPU layer matters for agentic AI
Most enterprise security conversations about AI are still CPU-centric. But agentic AI workloads are GPU-heavy by nature. Inference, reasoning, and multi-step planning all run on GPU infrastructure. And extending the Confidential Computing trust boundary from the CPU to the GPU has been one of the industry’s most important recent advances.
GPU-side Confidential Computing means the trust chain can now extend from the CPU through a trusted and attested interconnect to the full inference stack. The agent’s reasoning, the model weights it runs on, and the data it processes can all sit within a hardware-rooted boundary. For organizations running agentic AI at scale, that progression closes the last major gap in the end-to-end trust architecture.
The deployment layer: making this real without rebuilding everything
Hardware-rooted trust at the CPU and GPU layer is the foundation. But for most enterprise teams, the practical question is how to deploy it without rebuilding their entire infrastructure stack.
Confidential containers on Kubernetes are one answer to that question for cloud-native environments. By running pods inside hardware-isolated virtual machines, memory inside the container becomes invisible to the host OS and the underlying administrator. Secrets are provisioned only after the execution environment has been verified through attestation. For organizations already running AI workloads in cloud-native environments, this is a clear path from awareness to production without a full infrastructure rebuild.
Attestation: the trust anchor for autonomous systems
Across all of these layers, the mechanism that ties everything together is cryptographic attestation. Before any sensitive data enters a Trusted Execution Environment, the TEE generates verifiable cryptographic proof of its hardware and software state. That proof can be verified remotely, confirming that the agent is running unmodified code in a genuine, trusted environment and can even be repeated at various points in the lifecycle to ensure continued security. Attestation is what makes Confidential Computing different from every other privacy-enhancing technology. It doesn’t just claim security, it proves it.
For an autonomous system operating with no human oversight, attestation is the architectural trust anchor. It answers the question every enterprise security team needs to be able to answer: how do we know the environment our AI is running in hasn’t been compromised?
Open standards: the CCC’s role in making this interoperable
The hardware is here. The deployment tooling is maturing. What the industry now needs is open, vendor-neutral guidance that helps organizations navigate the best technology stack choices, validate their architectures, and move confidently from evaluation to production.
Adoption-focused technical guidance and reference architectures, built collaboratively across hardware vendors, cloud providers, and software developers, designed to give enterprise teams a practical and interoperable path forward regardless of which cloud or hardware stack they’re running on.
The goal is straightforward: make Confidential Computing the default for AI infrastructure, not a specialized capability reserved for the most security-conscious organizations.
The conversation we want to have with you
We’re bringing together three of the people closest to this problem for an open, practical conversation about what securing agentic AI actually looks like at every layer of the stack.
Felix Schuster, CEO of Edgeless Systems, is a pioneer in the Confidential Computing (CC) space, creating usable and deployable across every vertical. Jesse Schrater is a hardware visionary in the CC space, and brings Intel’s perspective on hardware-rooted trust and enterprise adoption of TDX and SGX. Daniel Rohrer from NVIDIA has been at the forefront of extending Confidential Computing at rack scale across CPUs, GPUs and networking where agentic AI and the world’s largest models and workloads run.
Together we’ll walk through LIVE the architecture, the deployment reality, and the practical steps organizations can take to start building AI infrastructure that’s secure by design.
Agentic AI in the Wild: Rethinking Trust When Your AI Has the Keys
Confidential Computing Consortium hosted live webinar ahead of CC Summit 2026.
This is the conversation the Confidential Computing community needs to be leading. We’d love for you to be part of it.
Sweden’s Integritetsskyddsmyndigheten (IMY), the national data protection authority, has published a final report providing detailed legal guidance on the use of Trusted Execution Environments (TEEs) for processing personal data outside an organization’s own infrastructure. The report, released through IMY’s innovation sandbox programme, is the first European regulatory assessment of TEEs grounded in a real operational deployment scenario, conducted in collaboration with Volvo Group, Ericsson, and CanaryBit. It represents a significant step forward for Confidential Computing adoption across regulated industries.
The Use Case: Vehicle Telemetry and the Data Sovereignty Problem
The project centered on a concrete challenge in the connected vehicle space. Trucks equipped with cameras and sensors generate continuous streams of video, positioning, and telemetry data. Processing this data onboard is not technically feasible, but transmitting it to an external cloud environment raises an immediate GDPR question: once data leaves a controlled environment, does the data controller retain the technical control that Article 32 requires?
IMY examined whether TEEs – hardware-enforced enclaves in which code executes and data is processed in cryptographic isolation from the surrounding infrastructure – could provide a legally sufficient answer. The conclusion: yes, under specific architectural conditions.
What IMY Found
IMY’s report establishes several findings of broad relevance to the Confidential Computing community:
TEEs qualify as a technical safeguard under GDPR Article 32. Unlike contractual controls alone, properly implemented TEEs provide cryptographic rather than merely contractual assurance. The enclave’s isolation is enforced by hardware; it cannot be overridden by the infrastructure provider. IMY describes this as shifting the basis of trust from promises to verifiable proof.
The verifier (attestation function) is where GDPR accountability lives. IMY’s most significant finding concerns the role of remote attestation, the mechanism, standardized in IETF RFC 9334, by which a relying party verifies that a TEE is genuine and operating in an approved state. When the data controller retains control of the attestation function and the encryption keys, IMY concludes the infrastructure provider cannot be considered a data controller or joint controller, and may not even meet the traditional definition of a data processor. Effectively, the provider supplies compute, and nothing more, because it has no technical pathway to the data.
Architectural choices determine legal outcomes. IMY’s analysis makes clear that the specific implementation matters: who controls attestation, who holds keys, and how frequently integrity checks occur all affect how GDPR roles and obligations are assigned. This provides actionable guidance for architects designing TEE-based systems in regulated environments.
Why This Matters for the Confidential Computing Ecosystem
Regulatory uncertainty has been one of the persistent friction points slowing Confidential Computing adoption. Organizations in healthcare, financial services, automotive, and other sectors understand the technical value of TEEs but have faced difficulty mapping that value onto compliance frameworks written before hardware-enforced confidentiality was practical at scale.
The IMY report, alongside prior assessments such as Germany’s BSI guidance, begins to fill that gap. It provides a jurisdiction-specific, use-case-grounded framework that compliance teams can reference, and it does so in terms that speak directly to how TEE architectures function in practice, drawing on established standards like RFC 9334.
For CCC projects and the broader open source Confidential Computing ecosystem, this kind of authoritative regulatory clarity is a meaningful accelerant. It reduces the cost and complexity of compliance analysis for organizations evaluating TEE-based architectures and establishes a precedent that other regulators across Europe and beyond may follow.
Read the Report
The full IMY publication, “Use of Trusted Execution Environment,” is available in English at imy.se.
This post was contributed by CanaryBit, a CCC member and participant in the IMY innovation sandbox project that produced the guidance described above.
AI Disclosure
This post used artificial intelligence tools for research, structural assistance, or grammatical refinement. The final content was reviewed, edited, and validated by human contributors to CCC to ensure accuracy and alignment with our community standards. We remain committed to transparency in the use of generative technologies within the open source ecosystem.
There’s a gap opening up in enterprise security right now, and most organizations can feel it but haven’t named it yet.
AI agents are no longer a roadmap item. They’re running in production environments, calling APIs, querying databases, reading documents, and making decisions on behalf of employees and customers. The speed of this shift has been remarkable. The security thinking hasn’t kept up.
When organizations talk about securing AI, they usually mean one of a few things: access controls on who can use the model, guardrails on what the model can say, or governance frameworks for AI outputs. These are all necessary. None of them address what happens inside the computation itself.
Traditional security was designed for a world where data moved between defined endpoints, rested in known storage, and was accessed by authenticated humans. AI agents break every one of those assumptions. A single agent can autonomously traverse dozens of systems in a single session, combine sensitive data sets that were never meant to touch, and pass outputs to other agents in a chain that no human directly oversees.
The threat surface has changed. The security stack largely hasn’t.
According to IDC’s 2025 Confidential Computing Study of 600 global IT leaders, 87% of organizations identified data breaches by remote outside attackers as an area needing improvement, and 83% flagged malicious insider threats. Those numbers reflect a security posture still oriented around perimeter defense and identity management — exactly the tools that offer the least protection once an AI agent is operating inside your environment with legitimate credentials.
What Confidential Computing actually solves
Confidential Computing is the protection of data that is actively in use — during computation, not just at rest or in transit. It does this through hardware-based trusted execution environments (TEEs): isolated enclaves where sensitive workloads run encrypted and verifiably protected, even from the operating system, the hypervisor, and cloud infrastructure administrators.
This matters for agentic AI in a specific and concrete way.
When an AI agent processes your customer data, it isn’t just reading a file and returning a result. It’s loading data into memory, running inference or retrieval operations, passing context between components, and often logging intermediate states. Each of those moments is a potential exposure point. TEEs close that window. The computation happens inside a hardware-isolated environment that can cryptographically prove its own integrity to any party that asks — a capability called attestation.
Attestation is what makes Confidential Computing different from every other privacy-enhancing technology. It doesn’t just claim security. It proves it.
That distinction matters increasingly as AI systems grow more autonomous. An agent that can attest its own execution environment gives organizations something they don’t have today: a verifiable chain of trust from silicon to output.
The adoption signal is already there
IDC’s July 2025 study surveyed 600 IT leaders across 15 industries and found that 75% of organizations are already using or piloting Confidential Computing — 18% in full production and 57% actively testing. Another 19% plan to deploy within 24 months.
That trajectory is being accelerated by two forces happening simultaneously.
The first is regulatory. The EU Digital Operational Resilience Act (DORA) mandates that financial institutions maintain high standards of availability, authenticity, integrity, and confidentiality for data whether at rest, in use, or in transit. “In use” is the new requirement — and Confidential Computing is one of the few technologies positioned to satisfy it. IDC found that 77% of organizations are more likely to consider Confidential Computing specifically because of DORA’s requirements.
The second is the agentic AI wave itself. Agentic AI doesn’t just process sensitive data — it reasons across it, combines it, and acts on it in ways that amplify both the value and the risk. Organizations that want to deploy AI agents in regulated environments — healthcare, financial services, government — need a security architecture that can operate at that level of autonomy. Confidential Computing is the layer that makes that possible.
The two forces compound. Regulation creates urgency. AI creates the use case. Confidential Computing provides the infrastructure.
Where most organizations are still stuck
Despite the adoption momentum, IDC’s research surfaces a telling pattern: the barriers to Confidential Computing are no longer about whether it works. They’re about how to implement it.
The top challenge cited by 85% of respondents was validating attestation chains of trust. Seventy-eight percent flagged that it still carries a reputation as a niche technology with limited proof points. Seventy-five percent pointed to skills gaps.
These are solvable problems. But they’re not solved by waiting for the technology to simplify on its own. They’re solved through community — through practitioners sharing what they’ve built, security architects exchanging what they’ve learned, and vendors demonstrating real deployments against real threat models.
That’s precisely what CC Summit 2026 is designed to produce.
The question that matters now
75% of organizations are piloting or deploying Confidential Computing. The regulatory window is narrowing. Agentic AI is already running in production environments across every major industry.
The organizations moving fastest are the ones who stopped asking whether they need this security layer and started asking how to build it.
If you’re responsible for AI infrastructure, security architecture, or data governance in a regulated or high-stakes environment, that’s the conversation happening at CC Summit 2026.
Don’t let your security architecture fall behind your AI capabilities. The blueprints for the future of data security are being drawn right now—and you need to be in the room.
Secure Your Spot: Register today for the Confidential Computing Summit 2026 to connect with enterprise peers, explore real-world deployment frameworks, and solve the attestation and skills gaps holding your organization back.
Get Involved: Shape the standard for secure, autonomous AI. Learn how you can contribute to open-source initiatives, collaborate with industry leaders, and join the mission by becoming a part of the Confidential Computing Consortium.
The Confidential Computing Consortium (CCC) has recently submitted formal responses to two major government consultations on AI security: the US National Institute of Standards and Technology (NIST) Request for Information on the secure development and deployment of AI agent systems (NIST-2025-0035), and the UK Government’s Department for Science, Innovation and Technology (DSIT) Call for Information on Secure AI Infrastructure. Taken together, these responses make a consistent and compelling case: as AI systems become foundational to national security, public services, and economic competitiveness, hardware-enforced trust must become a foundational layer of AI infrastructure.
A Shared Threat Landscape
Both responses begin from the same premise: AI agent systems face a category of risk that conventional cybersecurity tools were not designed to address. The threats are not merely traditional data breaches, they target the unique characteristics of AI itself.
Key risks highlighted across both submissions include:
Model weight theft, where proprietary model weights can be exfiltrated through API abuse or direct memory dumps by malicious insiders or compromised infrastructure
The infrastructure trust gap, where standard cloud security protects against external attackers but leaves model weights and inference data accessible to the cloud provider’s hypervisor or privileged administrators
Memory scraping and cold boot attacks, which can extract sensitive context, credentials, or cryptographic material from unprotected RAM
Memory poisoning, where adversarial content injected into an agent’s long-term memory is triggered later, with the temporal gap between injection and execution making detection very difficult
MCP-specific threats (highlighted in the NIST response), including shadow servers, tool poisoning, and confusion attacks that undermine the integrity of agent-to-tool communication
“Confused deputy” attacks in multi-agent systems, where a compromised agent manipulates another into sharing sensitive data without adequate authentication
Why Confidential Computing Is the Answer
The central recommendation of both responses is that protecting AI systems requires moving beyond perimeter-based controls toward architectures rooted in hardware-enforced trust; specifically, attested, hardware-based Trusted Execution Environments (TEEs).
Confidential Computing addresses several of these risks directly:
Data-in-use protection encrypts agent memory and model weights during processing, ensuring that even cloud providers and privileged infrastructure operators cannot access sensitive workloads
Remote attestation cryptographically verifies that the correct, unmodified agent code is running on a genuine, trusted platform before any secrets are released, providing technical guarantees rather than mere contractual assurances
Cryptographically assured workload identity gives each agent an ephemeral identity rooted in hardware attestation, replacing static API keys with dynamic, verifiable credentials
Key Broker Services release decryption keys and credentials only after successful attestation, meaning that if the environment doesn’t match an approved policy, keys are simply not released
Confidential Inference (highlighted in the UK response) keeps user prompts encrypted in transit, decrypting them only inside an attested TEE, preventing cloud operators or intermediaries from accessing prompt contents
The UK response also draws attention to the need to extend these protections to accelerators such as GPUs, which in multi-tenant environments represent a significant attack vector, and to future-proof the transport layer against “Store Now, Decrypt Later” attacks using Post-Quantum Cryptography (PQC).
Looking Ahead: Agentic Zero Trust and Standardisation
As AI agents become more capable and autonomous, potentially holding wallet keys, signing transactions, and communicating with other agents, the CCC’s responses call for a shift toward what we describe as Agentic Zero Trust: a model where every inter-agent interaction is cryptographically authenticated, and where an agent’s identity is bound to its code measurement rather than a pre-shared secret.
Both responses also call on governments to take an active role in standardisation. The NIST response urges the US to define clear “Confidential AI” assurance levels so that AI providers can credibly demonstrate they are technically unable to access user data. The UK response similarly highlights the need to standardise attestation reports across hardware vendors – AMD, Intel, Arm, and NVIDIA – to enable a unified root of trust across the UK AI sector.
On the supply chain side, the NIST response raises a specific concern: MCP authentication is currently optional by design and package signing is inconsistently required, creating risks at every startup. Both responses make clear that governance assurances are not a substitute for cryptographic guarantees.
Read the Full Responses
These are just highlights from two detailed submissions that together cover threat modelling, technical controls, patching challenges for stateful agents in TEEs, monitoring constraints imposed by Confidential Computing, and much more.
By Laura Martinez, Chair of Outreach Committee, Confidential Computing Consortium
In mid-October of last year, many experts arrived in SF for a mini Confidential Computing Summit. They each shared stories of how they are revolutionizing their industries through something as innocuous sounding as Confidential Computing.
Last week at the Open Confidential Computing Conference, top tech experts joined forces to tackle one massive challenge: building the highly secure, next frontier of trusted infrastructure. Historically, tech companies kept their security strategies locked down as a competitive advantage. But this event flipped the script.
Moving Beyond Moats: The Power of Open Ecosystems
Thanks to the ongoing vision within the Confidential Computing Consortium (CCC) and thought leaders that span every industry, there is a shift away from private security “moats” toward a shared foundation. I was an early convert to the vision of Confidential Computing and how it could and would change the world for good. It is the new business enabler that will drive the next wave of global tech innovation.
This year highlighted a fundamental shift of the modern digital economy: no single organization can solve the challenge of “data in use” in isolation – you need to lower the drawbridge to collaborate securely. True scalability requires an open-source ethos, on open standards and shared frameworks. All of this works together to enable the next frontier of technology while securing it for future generations.
Key strategic themes from the event include:
The AI-Trust Convergence: As generative and agentic AI move into the enterprise, the demand for trusted execution environments (TEEs) has shifted from “niche” to “necessity.”TEEs unlock privacy-preserving LLMs, allowing organizations to innovate with sensitive data without compromising intellectual property. Confidential Computing is helping us get there by fulfilling the need for flexible zero trust architectures.
Regulatory Interoperability: Through ecosystem-wide collaboration, the industry is proactively addressing global standards and regulations. This collective approach reduces friction, ensuring that security architectures are interoperable across borders and cloud providers such as the real-world Bosch Hermetik trusted collaboration environment which allows stakeholders, such as automotive manufacturers and suppliers, to jointly train AI models and integrate software pipelines without exposing their proprietary source code or intellectual property.
Shift to Industrial-Scale Production: We have moved past the “proof of concept” phase. From healthcare and enterprise systems to the decentralized frontiers of Web3, Confidential Computing is now powering live, mission-critical production environments. TikTok, for example, has showcased their innovations in confidential computing, particularly hardware-based TEEs, to protect sensitive user data while it is being processed, safeguarding AI tasks, and enabling secure, multi-party data analytics through its open-source ManaTEE data clean room.
Attestation as the New Currency of Business: The focus on rigorous attestation and verification frameworks proves that transparency is the bedrock of distributed systems. Intel, Edgeless Systems, NVIDIA and others covered the opportunities in moving toward a model where “trust” is computationally verified rather than just contractually assumed. I believe the next frontier of attestation services (verifiability that the entire TEE stays secure through all phases of use) will be attesting the workload while it is running at every company using Confidential Computing today.
A Collective Vision for the Future
The CCC serves as the vital hub for this evolution. Industry participants across hardware, cloud, and software such as NVIDIA, IBM, Intel, AMD, Google, Microsoft, TikTok and others are contributing to the open collaboration and standards development that advance Confidential Computing. When we foster a space for shared innovation across open-source and interoperable frameworks, we are collectively lowering the barrier to entry for secure computing. Together we can accelerate the maturity of the entire market, creating a “rising tide” that enables every participant to build more ambitious, secure, and sovereign technology solutions.
We extend our gratitude to the contributors and visionaries who are turning this collaborative spirit into a world safe for exchanging digital information. To learn more about the CCC and fostering that future together, reach out to us at: Confidential Computing Consortium.
The Confidential Computing Consortium (CCC) is pleased to welcome Modelyo as a new Start-up Member of the community.
About Modelyo
Modelyo is a confidential computing platform built for government and regulated industries, where strong security guarantees and data sovereignty are essential. The platform uses OpenStack together with Intel SGX and Intel TDX to enable organizations to run sensitive workloads with hardware-level protection, while maintaining full control over their infrastructure and data.
Modelyo’s work focuses on bridging strict security and compliance requirements with the flexibility of modern cloud infrastructure. This approach is particularly relevant for organizations that cannot compromise on sovereignty, regulatory alignment, or trust in how their systems handle sensitive data.
Why Modelyo Joined CCC
Modelyo brings direct, hands-on experience deploying confidential computing technologies in government environments. Their team has worked extensively with trusted execution environments (TEEs) in private cloud deployments and has built attestation workflows designed to meet real regulatory requirements, not just theoretical models.
Joining CCC is a natural next step in that work. Through participation in the consortium, Modelyo aims to contribute practical deployment experience to the broader community, helping accelerate adoption and improve operational understanding of confidential computing in regulated contexts.
What Modelyo Hopes to Contribute and Gain
Modelyo is particularly interested in collaborating on interoperability standards and contributing to efforts that make confidential computing easier to deploy, integrate, and trust across diverse environments. They are also looking forward to engaging with the wider CCC ecosystem, including hardware vendors, cloud providers, and system integrators who are shaping the future of this technology.
Modelyo is currently evaluating several CCC-hosted projects for potential integration and looks forward to contributing more actively as their involvement in the community deepens.
Member Perspective
“Confidential computing is moving from an emerging technology to essential infrastructure, especially for government organizations that need strong guarantees around data protection. We joined CCC to contribute what we’ve learned deploying these solutions in the field and to help shape the standards that will make confidential computing more accessible and trustworthy across the industry.” — :Artem Barger, VP of R&D, Modelyo
The CCC community is excited to welcome Modelyo as the newest Start-up Member of CCC and look forward to the perspective and practical experience they bring to the community.
The Confidential Computing Consortium (CCC) is pleased to welcome Invary as a new General Member of the community!
About Invary
Invary is a cybersecurity company focused on continuous Runtime Integrity attestation, enabling organizations to verify that systems remain in a trusted state throughout execution, not just at boot. This capability is increasingly critical for confidential computing environments, where trust must persist across the full workload lifecycle.
Invary leverages technology exclusively licensed from the NSA’s Laboratory for Advanced Cybersecurity Research to continuously verify kernel integrity, eBPF programs, and trusted execution environment (TEE) operations. These protections span physical hosts, virtual machines, confidential VMs, containers, and processing units, providing cryptographic proof of integrity from launch through termination.
Runtime Integrity is available as a SaaS offering or for on-premises deployment and integrates with existing SIEM and SOC workflows. By delivering verifiable trust signals, Invary’s technology complements hardware-based isolation controls across hybrid cloud, containerized, and multi-tenant environments.
Why Invary Joined CCC
As confidential computing adoption grows, ensuring trust during runtime has become a foundational requirement rather than an optional enhancement. Invary’s work addresses a critical gap by extending integrity verification beyond initial attestation and into continuous execution.
Joining the Confidential Computing Consortium allows Invary to collaborate with industry leaders who are shaping the future of trusted execution. Through CCC participation, Invary aims to help advance industry understanding of runtime integrity and contribute to standards that support verifiable trust throughout the workload lifecycle.
What Invary Hopes to Contribute and Gain
Invary is particularly interested in collaborating on runtime attestation standards and interoperability efforts that strengthen confidential computing deployments in real-world environments. The company brings hands-on experience securing complex infrastructure across diverse execution models and looks forward to sharing practical insights with the CCC community.
Through engagement with CCC members across hardware, cloud, and security domains, Invary aims to help accelerate adoption of confidential computing by making continuous verification more accessible, operational, and trustworthy.
Hear from Invary
“Runtime Integrity attestation provides continuous verification that systems remain in a known-good state throughout execution,” said Jason Rogers, CEO of Invary. “For confidential computing to deliver on its security promise, continuous verification is essential.”
The CCC community is excited to welcome Invary as a General Member and looks forward to the expertise and perspective they bring to advancing confidential computing.
By Mike Bursell, Executive Director, Confidential Computing Consortium
TL;DR
Agentic AI, unprotected, allows unauthorised and malicious people and systems with access to the machines on which Agents run to tamper with the Agents, their execution and their data. Confidential Computing isolates workloads such as Agents, protecting them. It also provides other capabilities that can underpin Agentic AI security
Introduction
The growth in generative AI has recently led to sufficient capabilities for a new set of AI applications: Agentic AI. One way to characterise generative AI is by its ability to generate and information – video, audio, text, numeric – in response to a query by one or more human actors. Agentic AI, on the other hand, is designed to operate (semi-)autonomously, performing multiple tasks, including possibly branching and creating new Agents, in order to fulfil a request. Agentic AI instances may query other systems, including humans, non-AI applications, generative AI and other Agentic AI entities.
Confidential Computing is defined by the Confidential Computing Consortium (CCC) as “protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment”.
This article considers some of the key security requirements for Agentic AI and how Confidential Computing may be used to meet them. It is intended to encourage interest in the subject and prompt technical conversations between practitioners in these and related fields.
The security problem
Agentic AI entities (“Agents”) will often be operating in environments that are not owned or operated by the owner of the Agent itself. Even where the environment is owned by the company owning the Agent (such as a private cloud or data centre), the people who run the infrastructure are likely to have different responsibilities and authorisations to those associated with or delegated to the Agent. A system admin is not likely to have the same authority as the CFO and therefore the CFO’s Agent, for example. The problem here is that when you run any application – including an Agent – on a machine which you do not completely control, then that application is at risk from people and applications with sufficient permissions, who can read or change data within the application, or even the application itself. This is just a function of how standard computing works, including cloud computing and virtualisation, whether with containers or virtual machines: with standard computing, if you have control over the infrastructure, then you have control over everything running on it. In this model, every Agent with any significant capabilities or access to sensitive data would need to run on separate servers, owned, controlled and operated by the Agent’s owner.
This causes a significant problem for agents. Most agents, by their very nature, need two specific things: an identity, and a way to authorise or approve actions. This latter may well be associated with the identity, but may not be. The standard way to provide an identity within computing is with a unique identifier such as a UUID, and the standard way to provide capabilities for authorisation is with a public-private cryptographic key, where the public part is published and the private part is kept confidential. Both of these are at risk and fundamentally insecure for Agents running on standard computing infrastructure.
In a world where you can have no assurance that the Agent you think you are talking to is actually the correct one – because someone may have changed its ID – you can have no trust in that Agent. Equally, what if somebody steals the private key from your Agent? In this case, the thief will have all the capabilities you delegated to your agent, which could include anything from access to private files to the ability to charge unlimited transactions to your or your company’s credit card.
Isolation requirements
In order to operate safely and as expected, Agents need to be isolated from the infrastructure on which they are running, breaking the standard model of computing where whoever controls the infrastructure controls the workloads. This isolation needs to be enforced in at least two ways: their identities need to be integrity protected, and their capabilities must be confidentiality protected. In fact, there are typically other assurances required: protection of the integrity of the Agent itself (to stop someone changing the “mission” of the Agent) and protection of the confidentiality and integrity protection of most, if not all, of the data held by the Agent (if I have used the Agent to book flights, for example, I want to know that the itinerary that it returns to me is correct and that no unauthorised parties can see it).
These requirements are actually very similar to those for standard applications in highly-regulated industries where data privacy is a concern, such as healthcare, finance, telecommunications, pharmaceutical research and government. In these contexts, protecting both the integrity and the confidentiality of data is a key requirement, often enforced by regulations. Where Agentic AI overlaps with these sectors, we can expect to see these regulations being applied directly. It is also likely that specific legislation and regulations will be created to apply to Agents specifically, simply due to the fact that they are going to be looking after and manipulating sensitive personal and business data.
Confidential Computing to protect Agentic AI
Confidential Computing is a set of chip-based technologies – whether on CPUs, GPUs or beyond – that are widely available both in the cloud and in server-grade technology available to organisations wishing to build private clouds and data centres or even to individual consumers. It provides exactly the protections required – integrity and confidentiality of data and applications – using hardware-based isolation, rooted in silicon.
Workloads, including Agents, are protected in-use – while they are executing – when run using Confidential Computing: the memory they are using is protected from tampering and viewing by all other entities with access to the machine, including administrators, the kernel and hypervisor. Additionally, Confidential Computing allows attestation measurements of applications and data can be verified by third parties to verify that these protections are in place and that the workloads are as expected. It also provides the underpinning technologies required to allow identity to be created and managed.
This is a perfect fit for Agentic AI, providing solutions to the problems explained above with protections that are available now, allowing owners to trust their Agents and for those interacting with them to be sure that they have not been compromised or their data exfiltrated. There are also opportunities for commercial providers of Agentic AI environments to build and sell services that owners of Agents can prove are safe for their Agents, because they do not need to trust these commercial providers, but the Confidential Computing infrastructure instead.
Conclusion
Confidential Computing allows Agentic AI to flourish without requiring infrastructure that is itself trusted: Agents from multiple owners can execute and interact on the same infrastructure. Confidential Computing’s remote attestation also allows identity to be established and proved both to owners of Agents and to other Agents and systems.
The Confidential Computing Consortium
The Confidential Computing Consortium is part of the Linux Foundation and the industry body dedicated to defining and accelerating the adoption of confidential computing. Members include businesses, research organisations and not-for-profits across the ecosystem who work on technical and outreach projects to further the Consortium’s goals.
