Should organisations use confidential computing or runtime controls for agent security?

When runtime isolation is the stronger control

Confidential computing and runtime controls solve different parts of the same problem. Runtime isolation becomes the better choice when the agent is handling sensitive data, calling tools, or taking actions that cannot be safely reversed, because the control boundary has to include the execution environment, not just the model prompt or application code. For agentic systems, that usually means thinking in terms of layered agent security rather than a single hardening measure.

It is also the more direct control when you need to limit what infrastructure operators, debugging access, or adjacent workloads can observe while the agent is actively reasoning or using credentials. In those cases, the security question is not only whether the agent is well configured, but whether the runtime itself prevents exposure of the decision context, session material, or tool inputs.

When the design includes delegated access, tool invocation, or other high-impact actions, runtime controls should be treated as part of the authorization story, not as an optional hardening layer. That is why AI agent authorisation matters alongside confinement: the agent needs both limited rights and a controlled place to exercise them.

What confidential computing actually adds

Confidential computing is most valuable when the main concern is protecting data and decision material while it is being processed, especially in shared or partially trusted infrastructure. It reduces exposure by using hardware-backed isolation, attestation, and controlled key release so that the workload can prove where it is running before secrets are released. That makes it a strong fit when the agent must access sensitive inputs, tokens, or keys but the organisation does not fully trust the host layer.

For agent security, the practical benefit is that you can narrow who can inspect memory, tamper with the runtime, or casually harvest sensitive context from the platform. The control does not replace good software design, but it changes the trust boundary in a way ordinary application hardening cannot. The Confidential Computing Guide is the right conceptual reference when the issue is trusted execution, attestation, and key release for a workload that must process protected material.

That said, confidential computing is not a substitute for disciplined agent behaviour. If the agent can still choose the wrong tool, over-share data, or act on poisoned context, the hardware boundary may protect the runtime but not the decision quality. In practice, the best deployments pair confidential execution with tight permissions, audited tool access, and explicit session handling.

How to choose between them in practice

The decision usually comes down to what you are trying to protect. If the primary problem is exposure of the runtime itself, confidential computing is the better anchor control. If the primary problem is what the agent can do while running, runtime controls such as isolation, sandboxing, approval gates, and tool scoping are usually the first line of defence. Many real deployments need both, but they are not interchangeable.

For teams building agentic workflows, a useful rule is to start with runtime controls whenever the agent can touch production systems, credentials, or customer data, then add confidential computing when the remaining risk is that the environment itself is too visible or too trusted. That sequencing is especially important when the agent can issue commands or change state across systems. The AI Agent Observability, Audit and Incident Response Guide is a useful complement here because containment without attribution leaves you unable to tell whether the control actually held.

For broader architecture decisions, confidential computing is best viewed as a trust-bounding mechanism, while runtime controls are behaviour-bounding mechanisms. The first protects the place where the agent runs, the second limits what the agent may do there. If you only do one, you should be very clear about which failure you are accepting.

Risk and Threat Considerations

The core risk is that an agent often combines sensitive context, delegated credentials, and tool access in one execution path. If that path runs on ordinary infrastructure with weak isolation, an attacker, operator, or adjacent process may gain enough visibility to steal secrets, manipulate context, or hijack the agent’s actions.

Failure mechanism: The runtime boundary is too soft, so confidential prompts, tokens, or tool outputs can be observed, copied, replayed, or influenced before the agent finishes its work.

Impact: That can expose credentials, widen blast radius, and turn a single compromised agent into a pathway for irreversible actions, lateral movement, or high-confidence data exfiltration.

Practitioner Guidance

What to prioritise: If the agent can use credentials or trigger production-side effects, treat least privilege and runtime containment as mandatory together, not as alternatives. Do not wait for a breach to decide that the execution boundary matters.

What to verify: Confirm whether the runtime can actually protect memory, isolate sessions, and restrict operator visibility for the exact workload path the agent uses. If attestation or controlled key release is part of the design, verify that it is enforced before the agent receives sensitive material.

Common mistake: Teams often harden the model layer and then assume the platform is safe by default. That leaves the agent’s own execution environment, which is where tool use and irreversible action actually happen, underprotected.

Practitioner takeaway: Use confidential computing when you need to reduce trust in the platform itself, and use runtime controls when you need to constrain what the agent can do while it runs, because the safest design usually needs both layers to cover different failure modes.

Related resources from NHI Mgmt Group

• Should organisations use prompt filtering or action-boundary controls for agent security?
• Should organisations rely on model guardrails or runtime controls for agent security?
• How should security teams use IAST and RASP in NHI governance?
• Why is single-provider AI agent governance not enough for enterprise security?