Confidential AI extends zero trust into runtime execution

At a glance

What this is: This is an analysis of why zero trust stops short of AI runtime execution and why confidential computing is presented as the next control layer.

Why it matters: It matters because IAM and NHI programmes now have to govern not just who gets access, but what protects sensitive data and models after access is already approved.

Context

Zero trust is an access control model, not a runtime protection model. It was built to answer who can get in and under what conditions, but AI changes the problem because sensitive prompts, model weights, embeddings and outputs are processed after access has already been granted.

That gap matters for IAM, NHI and AI governance because the security boundary shifts from authentication to execution. Zero Trust Identity Guide is a useful baseline for understanding why identity-centric policy alone does not secure workloads once they are running.

Key questions

Q: How should security teams implement zero trust for workloads and AI agents?

A: Start by giving each workload or agent a verifiable runtime identity, then enforce request-level policy and issue short-lived credentials only after the identity and context checks pass. The practical goal is to remove standing secrets and make access decisions at the point of use, not at deployment time.

Q: Why does Confidential AI matter for security teams?

A: Confidential AI matters because it protects sensitive data and model workloads while they are being processed, not only when stored or transmitted. Security teams use it to reduce exposure of prompts, training data and inference outputs to infrastructure operators and neighbouring workloads. Check attestation, key handling and isolation assumptions before relying on it.

Q: What are the signs that a company is relying too much on perimeter security for AI access?

A: A company is over-relying on perimeter security when AI agents already hold valid credentials, can reach multiple internal systems, and security confidence is weakest for machine-to-machine connections. If teams focus on wall height instead of what an authenticated agent can touch, the organisation is managing location rather than trust. That usually means blast radius is still too large.

Q: Should organisations prioritise attestation or access control for AI systems?

A: They should treat them as linked controls, but attestation comes first when the goal is to protect sensitive in-use data. Access control decides who may request action, while attestation decides whether the environment is trustworthy enough to receive keys and datasets. Without proof of environment integrity, access control alone is incomplete.

Technical breakdown

Why zero trust stops at the point of access

Zero trust verifies identity, device posture and policy before access is issued, then assumes the session itself is acceptable if the request passes control gates. That works well for users and conventional workloads with predictable execution paths. AI workloads are different because the high-value asset is often present only while the model is running, in memory, on shared infrastructure, or inside a temporary inference path. The result is a protection gap between access approval and runtime exposure. Identity controls still matter, but they do not prevent host visibility, privileged inspection or execution-time leakage once the workload is live. See the Zero Trust Identity Guide.

Practical implication: Treat runtime exposure as a separate control problem from access approval.

How confidential computing changes the trust boundary

Confidential computing shifts trust from the operator and host environment to a verifiable execution enclave, usually a trusted execution environment or TEE. The workload proves it is running in an approved state through attestation, and only then are keys or sensitive inputs released. In practical terms, this means the environment identity becomes part of the access decision. The value is not that encryption disappears, but that data remains protected while in use, not only at rest or in transit. For AI, that matters because the model and its inputs are most exposed during inference and processing. See the Confidential Computing Guide.

Practical implication: Use attestation as a release condition for data and model access.

Why key release becomes a runtime control for AI

The article’s strongest technical point is that encryption keys should not be released simply because a caller is authenticated. They should be released only when the runtime environment has been verified. That makes key management part of the execution plane, not just the identity plane. It also reduces the value of stolen credentials if the attacker cannot reproduce the attested environment. This is especially relevant for AI systems that handle proprietary data, model weights or regulated information across shared GPUs and hybrid infrastructure, where access without runtime validation leaves too much trust in the host.

Practical implication: Tie sensitive key release to verified runtime state, not just to authenticated requests.

NHI Mgmt Group analysis

Runtime trust is now the missing layer in zero-trust programmes. Identity controls can decide who may initiate a session, but they do not govern what happens once AI starts processing sensitive material. That means the most important control boundary for AI is no longer the login event, it is the verified execution environment. Practitioners should stop treating runtime protection as an optimisation and start treating it as a governance requirement.

Confidential AI is best understood as execution-time assurance, not a replacement for zero trust. The article is right to frame confidential computing as an extension of zero trust rather than a competing model. Access decisions remain necessary, but they are insufficient when the crown jewels are prompts, weights and outputs in memory. This is where confidential computing changes the security conversation from permission to proof.

Runtime verification gap: the governance assumption that access approval equals safe use fails in AI systems. That assumption breaks because AI workloads create value and exposure after authorisation, often in shared or partially trusted infrastructure. If runtime attestation is weak, keys and data may still be handed to an untrusted execution context. Practitioners should treat attestation quality as a control objective, not a technical detail.

AI governance now has an identity dimension that traditional security models miss. When workloads, not people, are the active consumers of sensitive data, identity policy has to extend to machine execution state and environment identity. That makes NHI governance and agentic trust models increasingly relevant to AI security architecture, especially where workloads authenticate repeatedly or scale across environments. Security teams should align workload identity, attestation and access policy as one control chain.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Confidential Computing Guide

What this signals

Runtime verification will become the practical test of mature AI governance. As AI adoption expands into higher-value workflows, teams will be judged less on whether they can authenticate access and more on whether they can prove the execution context is safe before secrets are released.

Execution-time control will reshape how identity teams think about trust. Workload identity, attestation and key release are converging into a single governance problem, especially where AI systems move across shared GPUs, hybrid environments and third-party infrastructure.

NHI governance will increasingly intersect with AI security because the object being trusted is no longer only the caller. The runtime environment itself becomes an identity-adjacent control point, and teams that cannot verify it will keep treating AI as a partially trusted workload.

For practitioners

• Separate access approval from runtime assurance Document zero trust as the entry control and add a distinct control for workload execution so sensitive AI assets are not treated as safe once authentication succeeds.
• Require attestation before releasing sensitive keys Make key release conditional on verified enclave state so inference systems only receive secrets after the runtime environment passes trusted execution checks.
• Inventory where AI workloads handle sensitive material Map prompts, model weights, embeddings and outputs to the environments that process them, then flag shared GPU and hybrid deployments as higher-assurance workloads.
• Align workload identity with execution policy Treat workload identity, environment attestation and policy-driven key management as one chain of control instead of separate projects owned by different teams.

Key takeaways

• Zero trust still leaves AI runtime exposure unresolved, because authentication does not protect the point where prompts, model weights and outputs are processed.
• The article ties AI risk to execution, showing why attestation and confidential computing matter most when sensitive data is handled in memory.
• IAM and NHI teams should align workload identity, key release and runtime verification so trust is proven at execution, not assumed after login.

Related NHI Mgmt Group resources: Zero Trust Identity Guide · Confidential Computing Guide · Guide to SPIFFE and SPIRE · Zero Trust for AI Agents

Key terms

• Confidential Computing: A method of processing sensitive data inside a protected hardware enclave so the cloud operator cannot inspect the data while it is in use. It combines isolation, attestation, and controlled execution to reduce exposure during cloud-side computation without forcing plaintext access.
• Runtime Attestation: Runtime attestation is a control that cryptographically proves a request came from the expected system or workload. It adds evidence to machine-to-machine access decisions, which is especially valuable when bearer tokens alone cannot distinguish a real integration from an attacker replaying credentials.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management and the identity controls that underpin zero trust. It is designed for practitioners who need to connect identity governance to broader security programmes.