Confidential AI on AWS: Nitro Enclaves, Attestation, and Protecting Data in Use

Encryption at rest protects stored datasets. TLS protects data moving between systems. Neither control, by itself, protects sensitive information while an application is actively processing it in memory.

That gap matters when an AI workload handles financial records, medical data, customer communications, proprietary documents, credentials, or valuable model weights. The application still has to decrypt the input before tokenization or inference, and an operator, compromised host, overly privileged process, or malicious dependency may be inside the traditional trust boundary.

Confidential computing narrows that boundary. On AWS, Nitro Enclaves provide isolated CPU and memory environments attached to EC2 instances. Cryptographic attestation lets another party verify which enclave image is running before releasing data or keys to it. AWS KMS can use those measurements as policy conditions, so decryption is tied to an approved workload rather than only an IAM principal.

This is not a universal security layer and it does not make an AI system trustworthy by definition. It is a specialized architecture for reducing who and what can see plaintext during computation. This guide explains where it fits, how the data and key paths work, and what teams must operate around it.

---

Start with the Threat Model

Do not begin with an enclave. Begin with the people, systems, and failures from which the workload needs protection.

A confidential AI design may aim to prevent plaintext exposure to:

• administrators with access to the parent EC2 instance;
• processes, agents, or containers running on that parent;
• a compromised host operating system;
• infrastructure automation with broad runtime access;
• another participant in a multi-party data workflow;
• a cloud service operator who should not handle customer content;
• accidental collection through logs, traces, crash dumps, or support tooling.

The same design does not automatically protect against:

• malicious or vulnerable code included inside the approved enclave image;
• compromised client devices before encryption or after results are decrypted;
• prompt injection, model manipulation, or unsafe tool execution;
• authorized users submitting data they should not possess;
• sensitive information intentionally returned in model output;
• flaws in the surrounding business authorization model;
• every possible hardware side channel;
• weak dependencies or a compromised build pipeline.

Write these boundaries down. If the primary risk is a public API with broken authorization, an enclave is not the first control to implement. If the risk is that a host administrator must operate infrastructure without gaining access to customer plaintext, confidential computing may be directly relevant.

For broader regional, legal, and vendor-boundary decisions, see our guide to data sovereignty for SaaS and AI systems on AWS.

---

What AWS Nitro Enclaves Provide

A Nitro Enclave is created from an EC2 parent instance and receives dedicated CPU and memory resources. It has no persistent storage, no interactive login, and no external network interface. Communication with the parent uses a local virtual socket, or vsock.

These restrictions are useful because they remove common access paths. The parent can forward encrypted requests and responses, but it should not receive the plaintext or keys required to process them. The enclave can be terminated and recreated from an immutable enclave image file.

The parent is still operationally important. It starts the enclave, accepts network traffic, applies admission controls, moves encrypted messages over vsock, reports health, and participates in scaling. The design should assume that the parent might observe, delay, replay, reorder, or drop messages. Confidentiality inside the enclave does not guarantee availability or message integrity around it.

Nitro Enclaves are appropriate for narrow, high-value processing boundaries. Examples include:

• decrypting and redacting sensitive documents before an AI workflow;
• running classification or inference where inputs must remain hidden from the host;
• protecting model weights or proprietary decision logic;
• tokenizing or detokenizing regulated identifiers;
• joining data from organizations that do not fully trust one another;
• generating embeddings from private records before encrypted storage;
• signing high-impact AI decisions with keys released only to approved code.

They are less attractive when the workload requires unrestricted outbound networking, large GPU capacity, interactive debugging, or frequent access to many external services. In those cases, place only the smallest sensitive operation inside the enclave.

---

Reference Confidential Inference Architecture

A practical design keeps networking and fleet operations outside the enclave while keeping plaintext and sensitive key material inside it.

Client or trusted data producer
  |  encrypt payload for approved enclave
  v
Load balancer / API gateway
  |
Parent EC2 service
  |  encrypted request over vsock
  v
Nitro Enclave
  - present attestation document
  - obtain attested KMS response
  - decrypt data key inside enclave
  - validate and process input
  - run model or protected processing
  - encrypt or sign result
  |
  v
Parent forwards encrypted result
  |
  v
Client decrypts and verifies result

The parent should handle only ciphertext and non-sensitive routing metadata. The enclave validates the request, obtains or unwraps the required key, performs the protected operation, and encrypts the result before returning it.

Not every system needs end-to-end client encryption. A trusted service can terminate TLS and re-encrypt the payload for the enclave. That is simpler, but it places that service inside the plaintext trust boundary. The correct choice follows from the threat model, not from a generic reference diagram.

Use stable request identifiers, authenticated encryption, bounded message sizes, timestamps or nonces, and replay protection. A hostile parent must not be able to substitute ciphertext from another tenant or replay an approved payment, signature, or model decision.

---

Attestation Connects Identity to Running Code

Traditional service identity answers which workload or principal is making a request. Attestation additionally proves properties of the environment and image that produced it.

A Nitro Enclave can create a signed attestation document containing measurements of the enclave image and platform. It can also bind a nonce, user data, or an ephemeral public key to that document. A verifier checks the signature chain, measurements, freshness information, and expected request context before trusting the enclave.

The measurements are platform configuration registers, commonly called PCRs. They represent properties such as the enclave image and signing identity. Treat them as deployment inputs:

• define which measurements a policy accepts;
• record the expected values with each release;
• verify them in CI before promotion;
• preserve the signer and source revision that produced the image;
• support a controlled overlap while old and new releases coexist;
• remove old measurements after rollback windows close.

Pinning a single image measurement gives a narrow policy but changes with every rebuilt image. A signing-based policy can support a managed release family, but it places more trust in the signing process. Either approach needs protected signing keys, review, provenance, and an emergency revocation procedure.

Attestation must be fresh and bound to the current session. Reusing an old document without a challenge can allow replay. A common pattern places the verifier's nonce and the enclave's ephemeral public key in the signed attestation document. The verifier can then encrypt a session secret to that key, knowing that only the attested enclave should possess the corresponding private key.

Service identity remains necessary outside this boundary. SPIFFE, SPIRE, and mTLS workload identity can authenticate services and parents, while attestation identifies the enclave image executing the protected operation.

---

Use KMS Policies as a Release Gate

AWS KMS supports cryptographic attestation conditions for Nitro Enclaves. The KMS request is made with an attestation document, and the key policy can require expected enclave measurements before allowing a cryptographic operation.

For decryption, KMS does not need to return plaintext to the parent. An attested request can include the enclave's ephemeral public key. KMS encrypts its response to that key, allowing the parent to relay an opaque response that only the enclave can open.

A production key flow typically looks like this:

1. The data producer creates a data key and encrypts the payload with authenticated encryption.
2. The data key is wrapped by KMS or another approved key authority.
3. The parent passes the encrypted payload and wrapped data key to the enclave.
4. The enclave creates fresh attestation that includes its ephemeral public key.
5. KMS evaluates IAM authorization and the attestation conditions.
6. KMS returns the decrypted material protected for the enclave's public key.
7. The enclave opens the response, decrypts the payload, processes it, and clears temporary key material.

Use separate KMS keys for environments and major data classes. Keep authorization dimensions independent: IAM identifies who may ask, encryption context identifies the tenant or purpose, and attestation identifies which code may receive the result. Avoid a single broad key whose policy accepts every enclave and every dataset.

Plan policy changes as carefully as application deployments. If a new enclave measurement is deployed before KMS accepts it, requests fail. If an old measurement is never removed, retired code retains access. A safe rollout adds the new measurement, deploys a canary, verifies decrypt operations and business outputs, shifts traffic, and then retires the old measurement.

---

Choose the Smallest Protected Boundary

Running the complete AI stack inside an enclave sounds simple, but it can create a large image, slow startup, difficult debugging, and an unnecessarily broad trusted computing base.

Consider three patterns.

Full Inference Inside the Enclave

The model, tokenizer, preprocessing, and postprocessing all run inside the enclave. This maximizes isolation from the parent and is suitable for models that fit the available CPU and memory envelope.

Benchmark model load time, peak memory, token throughput, concurrency, and enclave startup on the exact instance family. Large accelerator-dependent models may not fit this architecture.

Sensitive Preprocessing Inside the Enclave

The enclave decrypts, validates, redacts, tokenizes, or extracts approved features. A less trusted inference tier receives only transformed data. This reduces the protected runtime but is safe only if the transformation truly removes the sensitive information for the stated threat model.

Embeddings and tokens can still reveal source data. Do not label them anonymous without a documented privacy evaluation.

Protected Key and Decision Service

The enclave protects a small operation such as key release, policy evaluation, signing, or detokenization. The main model runs elsewhere, and the enclave authorizes or signs only approved results. This is often the most operationally practical pattern for high-impact workflows.

For GPU-heavy serving outside the enclave, our guide to GPU inference optimization and AI model serving covers capacity, batching, memory, and cost engineering.

---

Build Reproducible and Reviewable Enclave Images

The enclave image is part of the security policy. A dependency update can change its measurement and therefore its authorization.

The build pipeline should:

• pin base images and dependencies;
• scan operating-system and application packages;
• produce a software bill of materials;
• run unit, integration, and known-answer tests;
• build the enclave image in controlled CI;
• capture PCR measurements and source revision;
• sign approved artifacts with a protected release key;
• publish immutable artifacts and provenance;
• require review before KMS policy promotion.

Do not place long-lived secrets in the image. Bootstrap them through attested KMS operations or a service that independently verifies attestation. Keep the image small enough that reviewers can understand the trusted code path.

The parent binary and infrastructure also require supply-chain controls even though they cannot read enclave memory. They control traffic, availability, rollout, and what inputs reach the enclave. Apply the practices from software supply chain security, SBOM, and SLSA to both sides of the boundary.

---

Design for Failure and Scale

Enclaves are ephemeral. Design request processing to tolerate enclave replacement and parent-instance failure.

Prefer stateless enclave workers. Put durable encrypted state in an external store and release keys only to approved images. If a workflow spans several steps, keep an encrypted checkpoint and make transitions idempotent.

The parent should expose separate health signals for:

• process and instance health;
• enclave running state;
• vsock connectivity;
• successful attestation;
• KMS decrypt or sign operations;
• model readiness;
• end-to-end synthetic requests.

Scale on meaningful pressure: queue depth, enclave concurrency, processing latency, and error rate. CPU utilization on the parent alone may not represent protected workload capacity.

Use admission control before forwarding to the enclave. Bound request size, concurrency, and processing time so a client cannot exhaust enclave memory. Apply tenant quotas and backpressure at the external API, then enforce limits again inside the trusted boundary.

Availability remains a responsibility of the surrounding system. A malicious or failed parent can stop traffic even if it cannot decrypt it. Multi-AZ capacity, replacement automation, health-based routing, and tested recovery are still required.

---

Observability Without Plaintext Leakage

Confidential workloads are difficult to operate if teams either log everything or see nothing. Build a telemetry contract before production.

Safe operational signals can include:

• request count and latency histograms;
• payload size bands rather than payload content;
• attestation and KMS outcome codes;
• model and enclave release identifiers;
• input schema validation failures;
• resource pressure and queue depth;
• policy decisions represented by non-sensitive categories;
• encrypted audit records for authorized review.

Never log prompts, source documents, decrypted keys, model outputs, stack-local buffers, or raw exception values by default. Scrub error messages inside the enclave before returning them to the parent.

Use synthetic canary inputs that contain no customer data. They can verify attestation, key release, processing, and encrypted response paths continuously. Track canary results by release and Availability Zone.

For model quality, evaluate outputs through a separately authorized path with sampled, consented, and minimized data. The evaluation program described in production AI agent evaluation is still necessary; enclave isolation does not demonstrate accuracy or safety.

---

Measure the Cost of the Security Boundary

Confidential computing consumes dedicated instance resources and introduces work for encryption, copying, attestation, and enclave lifecycle management. Measure it against a non-enclave baseline.

Benchmark:

• cold startup and model load time;
• median and tail request latency;
• throughput at expected concurrency;
• peak enclave memory;
• ciphertext and vsock transfer overhead;
• KMS request volume, latency, and quotas;
• failure recovery time;
• instance utilization and cost per successful operation.

Cache only what the threat model permits. Reusing a data key or attestation session can reduce latency, but it expands the impact window if the process is compromised. Set a lifetime, request limit, and rotation trigger rather than keeping secrets indefinitely.

Compare the architecture with alternatives. Data minimization, tokenization before the workload, a dedicated account, strict IAM, a private network, or a managed model service may satisfy the requirement with less operational complexity. For managed foundation-model controls and governance, see foundation model integration, data management, and compliance with Amazon Bedrock.

---

Security Tests That Matter

A production review should test the negative path, not only a successful demo.

Verify that:

• an unapproved enclave image cannot use the KMS key;
• a retired measurement stops working after the rollout window;
• an attestation document with the wrong nonce is rejected;
• ciphertext copied between tenants cannot be decrypted in another context;
• replayed requests are rejected or remain idempotent;
• the parent never receives plaintext during success or failure;
• malformed and oversized messages cannot exhaust enclave resources;
• logs and traces remain free of protected content;
• dependency and image provenance are available for each release;
• key-policy rollback and enclave rollback are tested together;
• instance and Availability Zone failure do not corrupt workflow state.

Also review the application inside the enclave as ordinary security-critical software. Attestation proves that expected code is running; it does not prove that the code is correct.

---

A Focused 30-Day Pilot

A useful pilot validates one sensitive operation rather than attempting to move an entire AI platform.

Week 1: Threat Model and Baseline

Choose one data flow, identify the plaintext boundary, classify operators and services, define measurable security goals, and benchmark the existing path.

Week 2: Protected Data and Key Path

Build a minimal enclave service, encrypted request format, attestation verifier, KMS policy, and end-to-end test. Confirm that the parent observes only ciphertext.

Week 3: Release and Operations

Add reproducible image builds, measurement capture, canary rollout, structured safe telemetry, health checks, and rollback across both the image and KMS policy.

Week 4: Adversarial and Performance Validation

Test wrong measurements, stale attestation, replay, cross-tenant ciphertext, malformed input, instance replacement, and expected peak traffic. Compare latency, throughput, recovery, and cost with the baseline.

The pilot should finish with an explicit decision: deploy the protected boundary, narrow it further, use another control, or stop because the complexity exceeds the value.

---

Where BoundLayer Helps

Confidential AI crosses application security, AWS infrastructure, cryptography, data governance, model serving, and production operations. The difficult work is not launching an enclave. It is defining a boundary that remains secure through builds, releases, scaling, failures, and audits.

BoundLayer can help teams:

• create the threat model and confidential-data architecture;
• select the right enclave boundary for an AI workflow;
• implement attestation, KMS policies, and envelope encryption;
• build secure parent-to-enclave protocols;
• package and benchmark inference workloads;
• create reproducible release and measurement pipelines;
• design safe telemetry, audit evidence, and incident procedures;
• run adversarial tests and production-readiness reviews.

The result should be a small, evidence-backed trust boundary, not an expensive security label around an unchanged system.

---

Further Reading

• AWS Nitro Enclaves concepts
• Using AWS KMS with Nitro Enclaves
• Cryptographic attestation support in AWS KMS
• Setting up attestation for AWS Nitro Enclaves