GPU confidential computing can strengthen protection for sensitive processing. Production readiness also requires evidence that organisations can revoke access, enforce isolation and recover safely when controls fail.
An AI agent may complete its assigned task successfully while still carrying permissions that make it dangerous to operate.
For enterprise buyers, that creates a security question beyond model accuracy: can the organisation contain a compromised agent without interrupting unrelated services?
GPU confidential computing adds another layer to this assessment. Supported configurations can extend protections into GPU processing, but the implementation involves more than selecting compatible hardware.
NVIDIA’s reference architecture calls for a measured confidential virtual machine, confidential-computing capabilities on both the CPU and GPU, an attestation verifier, secure key release and carefully controlled logging. These are requirements of that architecture, rather than evidence that every GPU cloud service supplies them.
The practical task for buyers is to turn security claims into observable acceptance tests.
1. Test whether one agent can be stopped independently
A distinct identity makes it easier to attribute actions and apply targeted restrictions. It does not, by itself, prove that revocation will stop an active workflow.
A useful containment exercise starts with two test agents performing separate tasks. Security staff disable one identity and check whether its existing sessions, tokens and queued operations can still reach protected resources.
The second agent should continue operating within its authorised scope.
This exposes dependencies that an identity inventory may miss. Two agents might have different names but still use the same downstream credential. Alternatively, disabling new authentication may leave an established session usable until it expires.
Measure the interval between the revocation request and the last successful protected operation. Also record which unrelated services were affected.
The objective is an evidenced containment time, not an assumption that clicking “disable” ends all access immediately.
2. Test authorisation separately from model behaviour
An instruction telling an agent to avoid restricted records is not equivalent to a permission boundary.
A model may misunderstand a request or encounter hostile instructions in retrieved material. The service executing its tool call must still decide whether the operation is authorised.
OWASP’s AI Agent Security guidance recommends resource-level and tool-level restrictions, explicit authorisation for sensitive operations, and enforcement outside the agent’s context.
For example, a document-summary agent should be unable to modify the source repository even if it generates a convincing request to do so.
The test should attempt the prohibited operation through the underlying interface, rather than merely ask the model whether it would comply. A refusal in conversation demonstrates behaviour; a denied operation demonstrates an enforced boundary.
3. Verify what happens when attestation fails
Attestation provides signed evidence about aspects of a computing environment. A verifier assesses that evidence against an approved policy.
In NVIDIA’s referenced architecture, model keys should be released only when fresh evidence satisfies policy. The architecture also specifies that mismatched evidence or policy must cause the system to fail closed.
A meaningful test therefore includes deliberately invalid conditions:
- An unapproved workload image.
- Stale or missing attestation evidence.
- An unexpected platform configuration.
- An unavailable verification service.
- An attempted bypass of the normal key-release path.
The expected response should be documented before testing. Otherwise, an availability fallback could quietly undermine the intended confidentiality protection.
Attestation also has a defined scope. Evidence that approved software is running does not establish that the application has no vulnerabilities or that every action it takes is appropriate.
4. Examine tenant boundaries and hardware reassignment
“Isolated infrastructure” can refer to several different controls. Buyers need to establish which resources are dedicated, which are shared and how those boundaries are maintained.
The following questions provide a starting point for provider assessment:
| Area | Evidence to request |
|---|---|
| Hardware reassignment | Sanitisation procedures and completion records |
| Management interfaces | Network restrictions and access-test results |
| Shared control plane | Tenant separation design and relevant testing |
| GPU interconnects | Supported topology and isolation configuration |
| Administrative access | Approval, logging and emergency-access procedures |
| Backups and diagnostics | Retention rules, access controls and deletion processes |
These are due-diligence questions, not claims that a particular provider has failed them.
Independent testing is most useful when its scope matches the service being purchased. A report for a different configuration, region or product tier may leave important questions unanswered.
Buyers should also understand responsibilities at the boundary: which protections the provider operates and which depend on customer configuration.
5. Measure recovery and performance with protections enabled
Security controls need to be tested alongside operational requirements.
A benchmark run without the intended confidentiality, logging or access settings may not represent the production deployment. Teams should evaluate representative workloads with the required controls enabled.
Relevant measures include:
- Response latency and throughput.
- Startup and key-release time.
- Behaviour during verification-service outages.
- Recovery after credential rotation.
- Cost per successfully completed task.
- Effects on dependent applications.
Recovery testing should include queues, retries and work already in progress. Restarting an agent without understanding those states could repeat a transaction or resume an operation that security staff intended to stop.
Data location is only part of the assessment
Choosing a hosting region answers where specified infrastructure resides. It does not fully answer who can access information or where related logs, backups and support records are handled.
Procurement teams should examine those paths separately.
Customer-managed encryption keys also require precise questions: who can request decryption, which policies govern release, what happens after revocation and whether plaintext already available to an application remains accessible.
Similarly, a zero-retention statement needs a defined scope. Buyers should establish whether it covers prompts and outputs only, or also telemetry, abuse-monitoring records, caches and diagnostic material.
These details belong in the deployment agreement and acceptance criteria.
Make evidence part of the production decision
A practical evaluation can produce a compact evidence pack:
| Test | Result to retain |
|---|---|
| Selective revocation | Last successful access and effect on other workloads |
| Authorisation enforcement | Denied operations and corresponding policy decisions |
| Attestation failure | Evidence that keys were withheld |
| Tenant isolation | Findings applicable to the purchased configuration |
| Recovery | Safe restart behaviour and unresolved dependencies |
| Performance | Results with required protections enabled |
Passing these tests does not establish that a system is invulnerable. It provides a more useful basis for deployment than an untested feature list.
Confidential computing, identity controls and application security address different risks. Enterprise readiness depends on how they operate together—and whether the organisation can demonstrate what happens when one of them is challenged.
