NVIDIA’s Confidential Computing Architecture Makes Attestation Critical for AI Cloud Security

An AI agent can appear productive, follow instructions and complete complex tasks while quietly becoming a security liability. The decisive question for an enterprise is not simply whether the system can prevent every attack. It is whether the organization can identify a compromised agent, withdraw its access and contain the damage without bringing unrelated business operations to a halt.

That challenge is becoming more pressing as companies move AI agents from controlled experiments into production. These systems increasingly interact with business applications, internal information and operational workflows. Their usefulness depends on access. Their risk depends, in part, on how that access is granted, monitored and revoked.

The central issue is therefore one of control. AI infrastructure must do more than deliver computing power and display security certifications. It must provide evidence that its protections work when something goes wrong.

A discussion with Nir Chervoni, head of security products at AI-focused cloud provider Nebius, highlights an infrastructure-first approach built around distinct agent identities, limited credentials, customer-controlled encryption keys and auditable activity. GPU confidential computing adds another layer by protecting sensitive data and models during processing in supported configurations.

These technologies address different parts of the security problem. Together, they point toward a more demanding standard for enterprise AI: organizations must be able to demonstrate control over each running workload, not merely trust that the platform is secure.

Production Adoption Is Moving Faster Than Access Governance

Two findings from VentureBeat's VB Pulse Survey research illustrate the challenge.

In the August survey, 50% of respondents said their organizations had AI agents in production. Among that group, 61% reported at least some credential sharing between agents. In September's research, only 14% of respondents who answered the question about revocation said a named owner could revoke an agent's access within minutes.

These figures measure different aspects of the problem. One concerns the use of shared credentials among organizations with production agents; the other concerns the ability to revoke access quickly. They should not be treated as proof that every deployed agent is insecure. They do, however, raise a practical question about whether access governance is keeping pace with adoption.

An agent may need permission to read a document repository, query a database or trigger an operational process. If several agents share the same credential, the organization may struggle to determine which system performed an action. More importantly, revoking that credential could interrupt every workload that depends on it.

The result is a difficult trade-off between containment and continuity. Security teams need to stop a compromised agent quickly, but operations teams cannot afford indiscriminate shutdowns whenever a threat emerges.

Chervoni's recommendations return to familiar security fundamentals: give every agent a separate identity, issue short-lived credentials scoped to its tasks, manage secrets securely, support customer-controlled keys and send audit logs into the enterprise's security monitoring system.

His guiding principle is straightforward: “Never rely on a guardrail to enforce something an access policy could enforce deterministically.”

The distinction matters because model behavior and infrastructure permissions are not interchangeable. A model may be instructed not to access a sensitive resource. An authorization policy can instead deny that access regardless of what the model says or how a prompt changes.

Individual Agent Identity Changes the Economics of Containment

Identity is often treated as a basic administrative requirement. In agentic AI, it becomes a mechanism for limiting operational damage.

When each agent has a distinct identity, a security team can associate actions with a specific workload, define the permissions that workload requires and revoke its access independently. The organization can then investigate what happened without automatically treating every connected agent as equally compromised.

Shared credentials undermine that separation. They blur attribution and create dependencies between workloads that might otherwise operate independently. A single credential can become a common point of failure.

Consider a customer-service agent that can retrieve order information and a finance agent that can access payment records. If both use the same broadly privileged identity, a compromise involving one may require a wider shutdown or credential rotation. If their identities and permissions are separate, the organization has a clearer path to containing the affected workload.

The benefit is not simply stronger security. It is potentially lower recovery cost and less disruption to legitimate activity.

However, separate identities alone do not guarantee effective containment. An organization still needs to verify that revocation ends the agent's access, including relevant active sessions and credentials already issued. It must also establish what happens to transactions or tasks already underway.

A meaningful security exercise therefore measures both the time required to withdraw access and the consequences for dependent services. If stopping one agent unexpectedly interrupts unrelated workloads, the architecture has not yet demonstrated the degree of isolation that production operations require.

GPU Confidential Computing Extends Protection Into Processing

Encryption at rest and encryption in transit are established protections. AI workloads introduce an additional concern: sensitive information must often be available in usable form while a model processes it.

GPU confidential computing is designed to strengthen protection during that stage. In supported implementations, it can extend confidentiality protections into GPU processing and help defend against certain privileged infrastructure actors.

That is important for organizations running workloads involving regulated information, proprietary models or commercially sensitive data. Yet the protection depends on the actual configuration and the mechanisms used to establish trust in the computing environment.

Attestation is central to this process. It provides evidence about the environment in which a workload is running. A customer or its security system can evaluate that evidence before permitting sensitive keys to be released.

NVIDIA's reference architecture illustrates why confidential computing should be evaluated as a complete system rather than a single feature. Its described capabilities include a measured confidential virtual machine image, confidential computing across both CPU and GPU, an attestation verifier, key management that supports secure key release and logging designed to avoid exposing processed content.

The security outcome depends on how these components work together. If verification fails, the key-release process should respond according to a defined policy. If an override can bypass the policy without appropriate controls, the intended protection may be weakened.

Enterprises should therefore ask which components, interfaces and access paths are protected in the specific deployment they intend to purchase. A provider's use of the term confidential computing is not, by itself, evidence that every relevant workload or administrative pathway is covered.

There are also important limits. Confidential computing does not automatically fix application vulnerabilities, prevent prompt injection or ensure that model outputs are appropriate. Nor does it prevent a compromised identity from using permissions that identity legitimately possesses.

Confidentiality, authorization and application security must be assessed as separate but complementary controls.

Tenant Isolation Requires Evidence From the Actual Infrastructure

AI cloud environments introduce another layer of complexity because multiple customers may rely on shared infrastructure, management systems and networking components.

Chervoni identifies several areas that enterprise buyers should investigate before trusting a provider's tenant-isolation claims.

Hardware preparation is one. Customers should understand how hardware is handled when it moves between tenants and what procedures establish that it is ready for reassignment.

Sanitization is another. Buyers need to examine how firmware integrity is addressed and how GPU memory is sanitized between workloads. The relevant question is not whether a provider has a general procedure, but whether that procedure applies to the hardware and service configuration being purchased.

Machine isolation also matters. Tenant workloads should be assessed for their ability to reach management interfaces or other infrastructure that falls outside their intended security boundary.

Shared control-plane components require similar scrutiny. A service may isolate customer data at one layer while relying on shared services elsewhere. Buyers should understand which components are shared, how access is restricted and what the provider has tested.

Finally, high-speed networking deserves attention. AI workloads can depend on GPU interconnects and specialized networks to exchange data efficiently. Security reviews should establish how those networks are partitioned and whether isolation has been independently tested for the relevant configuration.

These questions turn broad security assurances into claims that can be examined against procedures, configurations and test results. They also help procurement teams distinguish between a provider's general capabilities and the controls available in the particular service under consideration.

Data Sovereignty Extends Beyond Geographic Location

For European enterprises and other organizations operating under strict regulatory or contractual obligations, data sovereignty is often discussed alongside data residency. The terms are related, but they do not describe precisely the same concern.

Data residency focuses on where information is stored or processed. Sovereignty requires a broader examination of who can access that information, how it is handled and who controls the mechanisms protecting it.

A workload can remain within a specified geography while still raising questions about administrative access, key ownership, retention or the operation of shared infrastructure. Geographic placement is therefore an important consideration, but it is not a complete security assessment.

Chervoni described an illustrative architecture for a regulated European deployment that included dedicated capacity, customer-controlled keys, attestation-based key release, approved and logged staff access, and zero-retention inference.

That example demonstrates how several controls can be combined to address different requirements. It should not be interpreted as proof that every Nebius service provides all these characteristics. Enterprises must verify the terms and capabilities of the exact offering they plan to use.

Customer-controlled key management can be particularly relevant. Some organizations want to retain control over their own key management system or integrate existing security components into the provider's environment. Nebius has said it has invested in identity and access management, key management, secrets management and audit logging while working with customers that want to bring their own security systems.

For buyers, the next step is to determine which controls are available, who operates them and what evidence demonstrates that they work as agreed.

The Commercial Value Lies in Verifiable Control

Nebius's approach reflects a broader distinction in the AI infrastructure market. Computing capacity is easy to compare in broad terms through available hardware, performance and price. Security is harder to evaluate because the decisive questions often concern behavior under failure conditions.

A platform's commercial value depends partly on whether it enables customers to operate sensitive workloads with acceptable risk. That means identity controls, key management, isolation and auditability are not merely compliance features. They can affect which workloads an enterprise is willing to deploy and how quickly those workloads can move into production.

The provider's role is to make the controls available and demonstrate how they operate. The customer's role is to define the requirements, validate the configuration and decide whether the evidence meets its risk threshold.

This is especially important for agentic systems, where permissions can connect model decisions to consequential actions. An agent that can only summarize public documents presents a different risk from one that can modify financial records, access regulated data or initiate operational transactions.

Security investment should reflect that difference. Organizations should prioritize the workflows where unauthorized access or an interruption would have the greatest business impact.

Open questions also remain about deployment-specific performance. Confidential computing and associated verification mechanisms must be evaluated against the latency, throughput and cost requirements of the actual application. The source material does not provide a quantified benchmark establishing a universal performance penalty, so enterprises should measure their own workloads rather than assume a fixed result.

The same discipline applies to claims about isolation. A general assurance is useful as a starting point, but acceptance decisions should depend on evidence from the relevant hardware, network and control-plane configuration.

Existing Security Tools Are Not a Substitute for Architectural Proof

Agent security draws on established disciplines, including identity and access management, secrets management, encryption, monitoring and incident response. These controls remain relevant even as the technology changes.

Model guardrails also have a role. They can help steer an agent away from inappropriate behavior. But a behavioral instruction does not replace an enforceable permission boundary. If an action must never occur, the underlying access policy should prevent it where technically feasible.

Likewise, confidential computing addresses protection during processing, not every possible route to compromise. A secure processing environment can still run vulnerable software or receive manipulated instructions. A correctly isolated workload can still possess excessive permissions.

The practical lesson is that enterprises should avoid treating any single security technology as a complete solution. They need layered controls that remain effective when another layer fails.

That requires coordination among AI platform teams, security operations, application developers and procurement. Security teams need visibility into identities and access events. Application teams need to understand the permissions their agents require. Procurement teams need to turn requirements into verifiable contractual and technical acceptance criteria.

Operational Tests Should Determine Production Readiness

The most useful next step is to test a representative AI agent workflow under realistic conditions.

First, assign the agent a distinct identity and an accountable owner. Document its permissions, the resources it can reach and the tasks it is authorized to perform.

Second, test revocation. Disable the agent's access and verify that the change takes effect within the required timeframe. Confirm that active sessions and previously issued credentials do not preserve unintended access. At the same time, measure whether unrelated workloads continue operating.

Third, test the confidential computing path if the workload requires protection during processing. Verify the attestation process, confirm how keys are released and deliberately exercise failure conditions. The organization should understand what happens when the environment cannot be verified and whether the policy can be bypassed.

Fourth, validate isolation across the actual deployment. Examine hardware reassignment, memory sanitization, management interfaces, shared services and network segmentation. Where appropriate, request independent test results that cover the purchased configuration.

Fifth, verify observability and retention. Customers should be able to establish whether staff access is approved and logged, whether audit records reach the expected monitoring systems, and whether backups and inference processes conform to agreed retention requirements.

Finally, repeat these tests when models, prompts, permissions or infrastructure configurations change. Security assurance should reflect the system that is running today, not only the design that was approved at launch.

The results should inform workload placement and procurement decisions alongside capacity, price and performance. A provider's ability to demonstrate selective containment, protected processing and verifiable isolation should be part of the acceptance criteria for sensitive AI workloads.

The larger shift is from trusting security claims to testing operational control. As AI agents acquire greater authority, the ability to withdraw that authority becomes a core measure of production readiness. The question is no longer simply whether an enterprise can deploy an agent. It is whether the organization can stop that agent when necessary, prove that access has ended and keep the rest of the business running.

NVIDIA’s Confidential Computing Architecture Makes Attestation Critical for AI Cloud Security

AI cloud security, AI agent security, GPU confidential computing, Nebius AI cloud, agent identity management, AI access control, confidential AI workloads, tenant isolation, data sovereignty, customer-controlled encryption, AI security governance, cloud key management, AI infrastructure security, enterprise AI agents