Guide

AI Server Encryption: Security Leads Must Verify Attestation

2026-10-12

AI Server Encryption: Security Leads Must Verify Attestation

Protecting prompts, models, and AI outputs requires three layers working together: encryption at rest, encryption in transit, and, critically, encryption in use through confidential computing. That third layer, built on Trusted Execution Environments with attested key release, is the practical standard to insist on if you want a real guarantee that your provider cannot read your data. It blocks provider-side plaintext access and memory scraping, though it won't shield you from legal process or weak abuse monitoring. We'll walk through what to verify before you trust any AI host with sensitive workloads.

***

> TL;DR:

>

> - Require a published attestation policy showing code and firmware checks, because key release should depend on a verified runtime, not network credentials.

> - For sensitive prompts, require attested TLS that binds each session to its enclave; verify the token’s signature, code hash, firmware, audience, and nonce.

> - TEE protection blocks provider staff from reading plaintext in memory, but it does not stop prompt injection, model extraction, or lawful disclosure; add application controls.

> - Pilot TEE backed inference on sensitive workloads first, then choose on premises, dedicated cloud, or managed confidential space based on control and staffing.

***

Table of Contents

A quick primer: encryption at rest, in transit, and in use

Most teams evaluating AI hosting already know encryption at rest and in transit. The third category, encryption in use, is where AI workloads expose a gap that older application stacks never had to worry about as sharply.

Encryption at rest protects data sitting on disk, typically through Transparent Data Encryption (TDE) with keys managed by a Key Management Service (KMS). Backups, model weight files, and stored conversation logs all fall under this umbrella. It's table stakes: if a drive is stolen or a backup leaks, the data stays unreadable without the key.

Encryption in transit covers TLS between your client and the server. It's effective at stopping a network-level eavesdropper, but standard TLS terminates at the server's network boundary, not inside the chip that actually runs inference. Once a request lands on a shared host, the connection's job is done, and whatever process handles your prompt next is a matter of trust, not cryptography.

That's the seam encryption in use closes. Model weights and prompts have to exist as plaintext in memory for a GPU or CPU to process them, and that moment is exactly when a privileged insider, a misconfigured hypervisor, or malware on the host could, in theory, read them. Confidential computing runs that computation inside a hardware-isolated Trusted Execution Environment (TEE), encrypting data while it's actively being processed, not just before and after.

Mapped to a real request lifecycle, the controls stack like this:

  • Prompt leaves your device: protected by TLS, ideally with attestation binding (covered below).
  • Prompt reaches the server: decrypted only inside a TEE, never in general server memory.
  • Model runs inference: weights and intermediate activations stay encrypted in use inside the enclave.
  • Output returns: re-encrypted for transit, then stored at rest if logged.

Each layer covers a different window of exposure. Skipping any one of them leaves a gap an attacker, or a curious insider, can walk through.

Confidential computing and TEEs: how they protect AI workloads

A Trusted Execution Environment is a region of the processor that isolates code and data from the rest of the system, including the operating system, hypervisor, and cloud provider staff. The main hardware families in production today are Intel TDX, AMD SEV, and ARM Confidential Compute, each offering memory encryption and isolation enforced by the chip itself rather than by software that an administrator could override. Cloud vendors have started packaging these into usable products: Microsoft documents GPU and platform options for confidential computing that extend the same isolation to AI inference workloads, which is notable because GPUs historically sat outside the TEE boundary.

Processor enclave isolated from system layers

Hardware isolation alone isn't proof of anything to an outside party, though. That's where remote attestation comes in: a cryptographic report, signed by the hardware itself, that states exactly what code is running, what firmware version is loaded, and whether the environment matches an approved configuration. A relying party checks that report, often called an attestation token, against a policy before trusting the enclave with anything sensitive.

The key-release workflow is where this becomes concrete, and it's worth walking through step by step:

  1. The enclave requests a decryption key from a Key Management Service, presenting its attestation report as proof of identity and integrity.
  2. The KMS verifies the attestation against a published policy: does the code hash match an approved build, is the firmware current, is the hardware a recognized TEE family.
  3. The KMS wraps the key and delivers it only if every check passes, binding key release to a specific, verified runtime state rather than to a login credential or network address.
  4. The enclave unwraps the key internally, and only then can it decrypt the prompt or model weights, entirely inside the isolated memory region.

NIST's guidance on confidential computing for AI frames this attestation-driven key release as the mechanism that limits key exposure strictly to verified TEEs, which is precisely why a platform operator with root access to the physical machine still cannot read your data: the key was never released to anything outside the attested enclave.

Pro Tip: *Ask any AI host for their published attestation policy document, not just a marketing claim of "confidential computing." If they can't show you what gets checked at key-release time, there's no way to verify the guarantee actually holds.*

None of this is "set it up once and forget it," though. Firmware and microcode need regular patching, and every patch changes the measured hash the attestation check relies on, so policy management has to keep pace. Supply chain trust matters too: the attestation root ultimately traces back to the chip manufacturer's signing keys, which means you're extending trust to Intel, AMD, or ARM's own security practices, not just your cloud provider's. These are manageable risks, but they're ongoing operational work, not a one-time checkbox.

Protecting prompts and payloads: attested TLS and prompt-encryption SDKs

Confidential computing protects the inference step once your prompt arrives inside the enclave. The remaining question is how you make sure the TLS connection carrying that prompt is actually talking to the attested enclave, and not to some other process sitting in front of it.

The answer is channel binding, usually implemented through attested TLS. Google's Confidential Space documentation shows using TLS Exported Keying Material (EKM) as a nonce, a value derived from the TLS session itself, inside the attestation request. Because the EKM is cryptographically tied to that specific TLS handshake, binding it to the attestation token means the verified enclave and the encrypted channel are provably the same thing. Without this step, a man-in-the-middle could present a valid attestation token while sitting outside the TEE, intercepting traffic before it ever reaches the real enclave.

This is the conceptual basis behind prompt-encryption SDKs: client-side libraries that encrypt a prompt so it can only be decrypted by an endpoint that has already proven its identity through attestation. Rather than trusting TLS termination at face value, the SDK verifies the enclave's attestation token, checks it against an expected policy, and only then releases the prompt for transmission.

A practical developer checklist for wiring this up looks like:

  • Generate a nonce from the TLS EKM for each new session rather than reusing one.
  • Verify the attestation token's signature chain back to a trusted hardware root.
  • Check the measured code and firmware hash against your approved policy list.
  • Validate that the audience field and nonce in the token match your current session before sending anything sensitive.

Server-side, this usually shows up as middleware sitting in front of your inference endpoint, integrated at the ASGI or WSGI layer so every request passes through attestation verification before it reaches application code. It's a few extra lines of integration work for a guarantee that's otherwise impossible to get from TLS alone.

AI-specific threat model and realistic limits

Encryption in use is powerful, but it answers a specific set of threats, not every threat an AI deployment faces. Mapping attacks to defenses keeps expectations honest.

  • Privileged provider access: a cloud employee or compromised admin account with root on the host. TEEs plus KMS-gated key release neutralize this, since the key never reaches anything outside the attested enclave.
  • Memory scraping: malware or a rogue process reading plaintext straight out of RAM. A TDE-only setup remains vulnerable here, because data still decrypts into ordinary memory for processing. TEEs close this specific gap.
  • Prompt injection: malicious instructions hidden inside user input or retrieved documents. This is an application-layer problem, not a cryptographic one. No amount of encryption in use stops a model from following instructions it was tricked into reading.
  • Model extraction: an attacker trying to reconstruct weights through repeated queries. Rate limiting and output monitoring matter more here than enclave isolation.
  • Legal and subpoena risk: a valid legal order compelling data disclosure. Encryption doesn't prevent a provider from complying with a lawful order where it holds the keys, or where jurisdiction requires cooperation.

Homomorphic encryption is sometimes raised as an alternative that would let computation happen without ever decrypting the data at all, even inside memory. It remains computationally expensive relative to hardware TEEs, which is why TEEs are the practical standard for production-scale inference today rather than a stopgap.

Crypto alone isn't the full job, either. Pairing it with strict attestation policy enforcement, routine key rotation, disciplined firmware patch cadence, minimal privileged services running alongside the enclave, and solid audit logging turns a theoretical guarantee into one that holds up in practice.

Deployment patterns: private AI clouds and dedicated encrypted hosting

Teams generally choose among a handful of deployment patterns, and the right one depends on threat model, latency needs, and regulatory scope more than on raw preference.

On-prem single-tenant hardware offers the most direct control and the clearest trust boundary, since there's no third-party operator at all. It also carries the heaviest operational burden: you own patching, hardware refresh cycles, and physical security.

Dedicated cloud instances with TEEs hand infrastructure management to a vendor while keeping a single-tenant boundary and hardware-backed isolation. This is a middle ground many regulated teams land on, trading some control for far less maintenance overhead.

Confidential-space offerings from major cloud providers package attestation, key release, and TEE provisioning into a managed product, which lowers the integration burden but ties you to that vendor's attestation root and policy tooling.

Private AI clouds bundle dedicated, encrypted infrastructure with the operational layer, like model routing, backups, and persistent memory, on top, aimed at teams that want the privacy posture of single-tenant hardware without running the sysadmin work themselves.

Weighing them comes down to a short set of questions: how sensitive is the data moving through the model, how much latency can you tolerate from enclave overhead, how large is your inference volume, and does a specific regulatory framework (GDPR's data minimization and processing rules, or HIPAA's safeguards for health data) dictate where processing has to physically occur.

How ClawBase implements encrypted AI hosting

We run OpenClaw, the open-source personal AI assistant, on dedicated encrypted servers rather than shared infrastructure, specifically because prompts and persistent memory deserve a single-tenant boundary. Every deployment includes daily encrypted backups, CISA-hardened backup procedures, and 99.9% uptime, alongside support for persistent memory management and access to over 50 AI models through one account.

If you're evaluating any managed encrypted-hosting provider, including us, here's the checklist worth running through before you commit:

  1. Attestation support: does the provider's infrastructure run on hardware that supports remote attestation, or is "encrypted" limited to disk and transit only?
  2. KMS integration: are decryption keys gated behind policy checks, or released on simple network authentication?
  3. Published attestation policy: can you actually see what gets verified before a key is released?
  4. Audit reports or third-party attestations: is there independent evidence backing the claims, beyond a landing page?
  5. Firmware and patch cadence: how often is the underlying TEE firmware updated, and how are policy hashes kept current?
  6. Recovery and backup procedures: are backups themselves encrypted, and is the recovery process documented?

We cover the overhead side of this tradeoff, a modest performance cost, in more depth in our piece on encrypted AI hosting, and we walk through Customer Managed Key practices for data at rest in our guide to encryption at rest for AI.

Pro Tip: *Don't take "encrypted" at face value from any provider, us included. Ask specifically which of the three layers, rest, transit, or use, the claim actually covers.*

Where security leads should focus right now

Confidential computing for AI is still maturing. SDKs for prompt encryption and attested channels are usable today but not yet universal across cloud platforms, and hardware GPU support for TEEs is newer than CPU-side confidential computing.

Our priority list for security leads: pilot TEE-backed inference on your highest-sensitivity workloads first, make attestation a procurement requirement rather than a nice-to-have, and integrate prompt-encryption SDKs wherever prompts could expose regulated or proprietary data. Everything else can follow once those three are in place. For deeper defensive engineering guidance beyond encryption specifically, NullVector's work on enterprise AI security is worth a look.

> *— Iosif Peterfi*

How ClawBase solves encrypted hosting needs

If everything above sounds like a lot to verify yourself, that's because it is, and it's exactly why we built ClawBase around dedicated encrypted servers instead of shared ones.

Clawbase

Plans start at $16 per month for LITE, scale to PRO at $33 per month, and top out at MAX at $66 per month, each also available annually. If you want to see how dedicated, encrypted hosting fits your own workload, visit ClawBase to start a trial or compare plans directly.

FAQ

Can AI be used for encryption?

AI itself doesn't perform traditional encryption; algorithms like AES still handle the actual cryptographic work. AI systems can assist with key management automation, anomaly detection around key usage, or policy enforcement, but the encryption primitives themselves remain standard cryptographic algorithms, not machine-learning models.

What is the 30% rule for AI?

There is no established "30% rule" tied to AI security or encryption standards. If you encountered this phrase in a specific context, it's worth checking that source directly, since it isn't a recognized industry term in confidential computing or AI data protection.

Can AI crack AES-256 encryption?

No current AI or computing method can practically crack AES encryption; its key space remains computationally infeasible to brute-force with existing or foreseeable classical hardware. AES is the standard underlying most encryption-at-rest and in-transit implementations referenced throughout confidential computing guidance.

Is PGP still used today?

Yes, PGP (Pretty Good Privacy) remains in active use, particularly for email encryption and file signing, though it's distinct from the TLS and TEE-based mechanisms that secure modern AI server traffic and inference. Most AI hosting security today relies on TLS for transit and hardware-backed confidential computing for data in use, rather than PGP.

What does confidential computing actually prevent a cloud provider from doing?

Confidential computing, through attested key release into a Trusted Execution Environment, prevents a cloud provider's own staff or infrastructure from reading plaintext prompts or model data, since decryption keys are only released to a verified enclave rather than to the provider's general systems. It does not prevent a provider from complying with valid legal orders where they retain some access path.

Sources

Recommended