VB Intelligence | Partner Analysis

As confidential computing comes to GPUs, it can protect sensitive workloads, but enterprises also need evidence that they can identify agents, isolate tenants and revoke access without disrupting operations.

If an AI agent is compromised, can your enterprise stop it and keep the business running? That question connects AI security to an operational requirement: controlling access at the level of an individual workload.

I recently sat down with Nir Chervoni, head of security products at Nebius, an AI-specialized cloud provider. He helped outline an agnostic, infrastructure-first approach built on distinct agent identities, scoped credentials, customer-controlled encryption keys, and auditable activity. We also discussed GPU confidential computing as an additional protection for data and models during processing, with explicit limits in place.

In my view, the central implication for enterprise buyers is that AI infrastructure evaluation should extend beyond compute capacity and security certifications. Buyers need evidence that controls work under failure conditions: a compromised identity, a failed integrity check, or an attempted crossing of tenant boundaries.

Confidential computing can strengthen that foundation. It does not establish that an agent’s actions are authorized, its application is secure, or its outputs are appropriate.

Key takeaways

Individual agent identities support containment. Shared credentials complicate attribution and make selective revocation harder. Enterprises should test whether stopping one agent also interrupts unrelated workloads.

Access policies and model guardrails serve different purposes. Permissions should constrain what an agent can reach regardless of how the model responds to a prompt.

GPU confidential computing adds a specific protection. Its value depends on the supported configuration, the integrity verification process and the policy governing key release.

AI-specialized cloud tenant isolation requires operational evidence. Hardware turnover rigor, management networks, shared control planes and GPU interconnects belong in provider due diligence.

Sovereignty requirements extend beyond location. Customers need to examine access, processing, retention and control over protections across the deployment.

What happened

In our August VB Pulse Survey, half of respondents said their organizations had agents in production. Among that group, 61% reported at least some credential sharing among agents. In the September VB Pulse Survey research, only 14% of respondents answering the revocation question said a named owner could revoke an agent’s access within minutes.

This raises a practical concern about whether agent deployment is advancing faster than access governance.

Chervoni’s perspective emphasized familiar security foundations: a separate identity for each agent, short-lived credentials scoped to their tasks, managed secrets, customer-controlled keys, and audit logs feeding the enterprise’s security monitoring system.

“Never rely on a guardrail to enforce something an access policy could enforce deterministically,” he said.

Chervoni said Nebius has invested in identity and access management, key management, secrets management, and audit logging, while working with clients who want to bring in their own key management system (KMS) or other security components. I believe those statements are a good starting point for determining what validation should look like.

Why it matters

Agent containment should be a business continuity requirement

A shared credential creates a dependency between workloads. Revoking it may stop a compromised agent, but it may also interrupt other agents using the same access.

My assessment is that enterprises should evaluate access control and resilience together. A named owner, distinct identity and bounded permissions create the conditions for selective containment. An exercise must then establish whether that containment works, including what happens to active sessions and work already underway.

Model guardrails remain useful, but they answer a different question. Steering an agent away from an inappropriate action does not remove its underlying permission to perform that action. Infrastructure and application authorization should independently enforce the boundary.

Confidential computing makes the trust boundary more explicit

Chervoni described GPU confidential computing as extending protection into GPU processing, including protection against certain privileged infrastructure actors in supported implementations. Attestation provides evidence about the environment that a customer can evaluate before releasing keys.

NVIDIA’s reference architecture reinforces that this is a system-level implementation. Its required capabilities include a measured confidential virtual machine image, confidential computing on both the CPU and GPU, an attestation verifier, key management that supports secure key release, and logging that avoids exposing processed content.

For buyers, the meaningful question is which components and access paths are protected in the proposed deployment. A confidential computing label alone does not answer that.

Chervoni also acknowledged the limits: the technology does not fix application vulnerabilities, stop prompt injection, or govern model outputs. A compromised identity may still exercise its legitimate permissions. Enterprises therefore need to evaluate confidentiality protections alongside authorization and application security.

Isolation and sovereignty need evidence customers can inspect

Chervoni proposed a concrete set of agnostic tenant-isolation questions:

Hardware: How is hardware prepared between customers?

Sanitization: How are firmware integrity and GPU memory sanitization handled?

Machine isolation: Can tenant workloads reach management interfaces?

Shared-nature: Which control-plane components are shared?

Network isolation: How are high-speed networks partitioned, and has isolation been tested independently?

These questions turn a broad assurance into an assessable claim. Why I like this is that the relevant evidence is the procedure, configuration and test result applicable to the service the customer will actually use.

This might be the most important point for many organizations, as it causes significant confusion about the differences between data residency and sovereignty. Chervoni made the distinction between data residency and sovereignty. In his framing, in addition to geography, customers should examine who can access information, how it is processed and who controls its protections. Again, this goes beyond mere location to the heart of sovereignty.

His example of a regulated European deployment included dedicated capacity, customer-controlled keys, attestation-based key release, approved and logged staff access, and zero-retention inference. This was an illustrative architecture, not evidence that every Nebius service provides those characteristics.

What to watch for

The next proof points should be operational:

Revocation effectiveness: Can a customer disable one agent and verify that its access has ended while unrelated workloads continue?

Attestation enforcement: What happens when verification fails, and can an override bypass the key-release policy?

Deployment-specific performance: What latency, throughput and cost changes appear on the customer’s workload with the required protections enabled?

Isolation coverage: Do independent tests cover hardware reassignment, management interfaces, shared services and the interconnect configuration being purchased?

Observable access and retention: Can customers verify that staff access, logs, backups and inference retention match the agreed requirements?

So what

In my view, the buying criterion for AI infrastructure should be demonstrable control over a running workload. GPU confidential computing expands the protections enterprises can apply, but operational security still depends on identity, authorization, isolation and recovery.

CISOs and AI platform leaders should start with a representative agent workflow.

Establish identity: Give it a distinct identity

Assign ownership: Assign an accountable owner

Analyze Permissions: Document its permissions and test revocation

Test & Measure: Measure both the time to contain access and the effect on dependent services.

For workloads that require stronger protection during processing, infrastructure teams should then test confidential computing in the intended deployment. Validate the attestation and key-release path, exercise failure conditions and measure performance against the application’s requirements.

Procurement should use those results to define acceptance criteria. A provider’s ability to demonstrate selective containment, protected processing and verifiable isolation should influence workload placement alongside capacity and price. As agents gain more authority, the enterprise’s ability to withdraw that authority becomes a core measure of production readiness.

Rob Strechay is Lead Analyst at VB Intelligence.

VentureBeat is a paid media partner for Nebius, the sponsor of VentureBeat’s event coverage. Neither Nebius nor other sponsors have editorial control over content on VentureBeat, VentureBeat Intelligence, or VentureBeat Research. Perspectives and opinions are those of VB Intelligence.