Your LLM Runs in a Nitro Enclave. Who’s Checking the Enclave?

Author: Guillermo Ruiz, guest contributor. Guillermo works at Amazon Web Services on efficient compute and confidential computing topics and contributes to open-source security tooling. Views are his own.

Prowler co-author: Lydia Vílchez López — Detection & Remediation engineer at Prowler. Lydia works on cloud security checks across every provider Prowler supports, and implemented the Nitro Enclaves check suite covered in this post.

TL;DR: AWS Nitro Enclaves are becoming the default answer for protecting LLM weights, prompts, and cryptographic keys on AWS. But until now, no CSPM tool could tell you whether your enclaves were actually configured securely. We’re changing that: 11 new Prowler checks bring dedicated security posture coverage to confidential computing workloads on AWS, from AWS KMS attestation policies down to detecting enclaves running in debug mode… without ever touching the instance.

Generative AI changed what “sensitive workload” means. It’s no longer payment data and private keys. It’s model weights that cost millions to train, system prompts that encode your business logic, and user conversations full of PII flowing through inference endpoints. More and more organizations are answering that challenge with AWS Nitro Enclaves: isolated, hardened compute environments with no persistent storage, no interactive access, and no external networking, purpose-built for processing data that not even the parent instance’s admin should be able to see.

While enclave adoption grows, visibility into how those enclaves are deployed and configured has been close to zero. At the time of writing, no widely adopted third-party CSPM or cloud security assessment tool offers dedicated posture checks, compliance validation, or best-practice assessments for AWS Nitro Enclaves, not even AWS Security Hub. You could run 1,700+ Prowler checks against your AWS account and get exactly zero findings about the most sensitive compute in your fleet.

That gap closes today. Prowler brings 11 automated security checks for confidential computing workloads. The first CSPM coverage for AWS Nitro Enclaves.

Why enclaves, and why now?

A quick refresher. AWS Nitro Enclaves let you carve out CPU and memory from an Amazon EC2 instance to create an isolated environment with a few radical properties:

• No network interface. The only communication channel is a local vsock socket (a lightweight host-only channel) to the parent instance.
• No persistent storage, no SSH, no operator access. Not even root on the parent can inspect enclave memory.
• Cryptographic attestation. The Nitro Hypervisor measures the enclave image via Platform Configuration Registers (PCRs), unique hashes that identify the code that ran, and signs an attestation document. You can write AWS KMS key policies that only release key material to an enclave whose measurements match, meaning only your exact, measured code can ever decrypt.

For LLM workloads, this maps beautifully: keep model weights encrypted at rest, and configure AWS KMS so decryption only happens inside an attested enclave. Prompts and completions never touch the parent’s memory in plaintext. It’s the strongest isolation story you can build on Amazon EC2.

But strong primitives don’t guarantee strong posture. A single misconfiguration (a KMS policy that allows bypassing attestation conditions, or an enclave accidentally left running in debug mode) can quietly undo the entire security model. And because enclaves are invisible to traditional tooling, nobody notices until an auditor (or an attacker) does.

The technical challenge: there is no API for “is my enclave OK?”

Building these checks wasn’t a matter of wiring up another AWS API call. AWS Nitro Enclaves present a unique problem for CSPM tools: there is no AWS API to query enclave runtime state remotely. The nitro-cli describe-enclaves command (the only way to see enclave state, debug flags, and resource allocation) runs locally on the parent instance. It has no Amazon EC2 API endpoint and no boto3 equivalent. The only enclave-related signal in the EC2 API is a single boolean: EnclaveOptions.Enabled.

That constraint shaped a fully passive architecture. Every check operates through standard AWS APIs and log sources: boto3 describe/list calls, KMS GetKeyPolicy, and CloudTrail LookupEvents. No commands are executed on customer infrastructure, no agents are deployed, and no SSH is required, preserving Prowler’s read-only model.

The 11 checks

Confidential workload host (EC2):

• ec2_confidential_workload_host_imdsv2_not_enforced — HIGH
• ec2_confidential_workload_host_public_ip — MEDIUM
• ec2_confidential_workload_host_unrestricted_ingress — HIGH
• ec2_confidential_workload_host_vsock_proxy_exposed — MEDIUM
• ec2_confidential_workload_host_not_running — MEDIUM

KMS attestation policy:

• kms_key_enclave_attestation_not_enforced — HIGH
• kms_key_enclave_attestation_bypassable_path — HIGH
• kms_key_enclave_attestation_no_deployment_binding — INFO
• kms_key_enclave_debug_attestation_detected — HIGH
• kms_key_enclave_attestation_pcr_mismatch — MEDIUM
• kms_key_enclave_attestation_unknown_image — MEDIUM

Four of these deserve a closer look, because they map directly to how confidential AI deployments fail in practice.

Check 9: Detecting debug mode through CloudTrail

Launching an enclave with --debug-mode does two things: it zeros the image, kernel and application PCRs (PCR0, PCR1, PCR2) in the attestation document, and it exposes enclave memory to the parent instance through a debug console. An enclave in debug mode is, from a security standpoint, not an enclave. It’s a very expensive process.

Debug mode is genuinely useful during development. It also has a habit of surviving into production, because nothing was watching for it.

This check connects two documented AWS behaviors into an automated detection: enclaves in debug mode produce attestation documents where the image/kernel/application PCRs (PCR0/1/2) are zeroed (documented by AWS in the aws-nitro-enclaves-cli README), and when an enclave calls AWS KMS with a Recipient parameter, CloudTrail records the full attestation context, including those PCR values. A CloudTrail query filtering for zeroed PCR0/1/2 reveals debug enclaves that called KMS.

PASS: No zeroed-PCR (PCR0/1/2) attestation events found in CloudTrail

FAIL: KMS events detected with PCR0=PCR1=PCR2=000...000 (debug mode enclave)

MANUAL: No KMS events with RecipientAttestation found (enclaves may not use KMS)

Limitations you should know about: This check is only capable of verifying debug enclaves that are actually calling KMS during the CloudTrail lookup window (default: 90 days, configurable via enclave_debug_lookback_window_hours). An enclave in debug mode that never interacts with KMS, or that ran before the window, is invisible to this method. That’s why the check reports MANUAL when no attestation events are found at all: absence of evidence is not evidence of absence. Definitive coverage of runtime state would require instance-level access, which is out of scope for Prowler’s read-only architecture.

The value here is practical: for organizations using enclaves to protect KMS-encrypted secrets (the most common pattern for LLM weight protection), any debug enclave will inevitably call KMS, making it observable without requiring SSM deployment on enclave hosts.

Check 7: The attestation policy that doesn’t actually protect anything

This is the most operationally impactful check. Many organizations correctly add kms:RecipientAttestation conditions to their key policies… then forget to remove the pre-existing admin access statement that grants the same kms:Decrypt permission without any attestation requirement.

The result: attestation is enforced on one path but trivially bypassable on another. The key policy has the appearance of attestation security with none of the guarantees. Any principal matching the unrestricted statement can pull your model weights directly, enclave or not.

PASS: All Allow statements for Decrypt/GenerateDataKey* require attestation OR are denied without it

FAIL: An Allow statement grants Decrypt without attestation, alongside one that requires it

A subtle point on the trust model: AWS KMS evaluates RecipientAttestation conditions independently of the caller’s IAM permissions. Even a wildcard IAM role (kms:*) doesn’t bypass attestation on statements that require it. The risk isn’t in the host’s IAM role, it’s in the composition of the key policy itself. That’s what this check audits.

Checks 6 & 8: Attestation is the whole point, verify it exists and has depth

The value of an enclave for LLM inference collapses if the AWS KMS key protecting your model weights doesn’t actually require attestation. Check 6 flags enclave-associated keys whose policies grant sensitive operations without any kms:RecipientAttestation condition, meaning any principal with decrypt permission can pull your weights, enclave or not.

Check 8 goes a level deeper: a policy conditioned only on PCR0 (the enclave image hash) can be satisfied by any enclave built from the same EIF, deployed anywhere, by anyone. Binding additional measurements (PCR3 for parent IAM role, PCR4 for parent instance ID, or PCR8 for EIF signing certificate) gives you defense-in-depth on the deployment context of the code allowed to touch your keys. AWS recommends PCR3 + PCR8 together for the best flexibility. This is reported as INFO (many legitimate deployments use PCR0-only), but it’s a meaningful signal for high-security environments.

Checks 10 & 11: Image provenance — is that the enclave you expect?

These checks address supply-chain risk for enclave images. Check 10 compares the PCR values authorized in your KMS key policies against a customer-maintained list of “golden” values from your CI/CD pipeline. A mismatch means drift: either a stale policy still authorizes an old image, or an unauthorized image was promoted.

Check 11 complements this with a detection framing: it scans CloudTrail for attestation activity from enclave images whose PCR values don’t match any known record. The finding: “Attestation activity detected from an enclave image whose identity cannot be verified against any known record.” For some organizations, that’s operational noise. For others, it’s an indicator of compromise.

What this doesn’t cover (and why we’re telling you)

Good security tooling is honest about its boundaries. These checks are point-in-time snapshots. An attacker could toggle debug mode between scans, which is why we recommend scheduled execution for continuous assessment. CloudTrail-based checks (9, 11) are bounded by the lookup window and can’t observe enclaves that never call KMS. Side-channel resistance is an architectural property, not something a scanner can assert. Each check is grounded in and cited against official AWS documentation, from the IMDS configuration guide to the KMS condition keys reference for Nitro Enclaves.

Compliance coverage: 23 frameworks out of the box

These 11 checks aren’t just operational findings. They map to 23 compliance frameworks including NIST 800-53, PCI-DSS v3.2.1 and v4.0, ISO 27001:2022, SOC 2 Type II, and HIPAA. The KMS attestation checks (6-11) additionally map to the AWS AI Security Framework, covering model weight protection, inference confidentiality, and attestation-gated key access. This is directly relevant for organizations certifying their LLM deployments.

When someone asks “how do you know your model weights can only be decrypted inside an attested enclave?”, the answer stops being a diagram and starts being a scan result with framework citations.

Why does this matter?

If you’re running (or planning to run) confidential AI workloads on AWS, you now get what every other part of your cloud already had: automated, repeatable, evidence-producing posture validation. Enclave findings flow into the same Prowler workflows you already use, alongside the compliance frameworks your auditors already ask about.

Confidential computing is how the industry will run its most sensitive AI. Making it auditable is how it becomes something you can actually certify.

Beyond enclaves: EC2 Instance Attestation

AWS Nitro Enclaves aren’t the only path to cryptographic measurement guarantees for LLM workloads. EC2 Instance Attestation uses the NitroTPM to provide boot-time cryptographic measurements of the entire instance environment, without requiring you to architect your application around an enclave’s vsock-only communication model. For teams that want to prove their inference environment hasn’t been tampered with but don’t need the memory-isolation properties of an enclave, instance attestation offers a lighter-weight entry point into confidential computing on AWS. The two approaches are complementary: enclaves isolate specific secrets at runtime; instance attestation verifies the broader host environment at boot. Future Prowler checks may extend coverage to NitroTPM-based attestation flows as well.

Get started

The fastest way is with Prowler Cloud: add your AWS account, run a scan, and the 11 confidential computing checks light up alongside continuous scanning, guided remediation, and framework-mapped evidence out of the box.

Prefer the CLI? The same checks are available in the open-source SDK:

# Scan your account, including the new confidential computing checks
prowler aws

# Or target specific checks directly
prowler aws --check kms_key_enclave_debug_attestation_detected kms_key_enclave_attestation_not_enforced kms_key_enclave_attestation_bypassable_path

Questions, feedback, or want to extend the coverage? Join the Prowler community on Slack.

From detection to remediation: Prowler Cloud

Detecting a debug-mode enclave in your CloudTrail logs is the start of the story. Someone still has to be watching, and someone still has to act on it. And here’s the part worth trusting: the same open-source checks documented here are available in Prowler Cloud from day one. It’s not a black box. It’s the exact detection logic you can already read and run yourself. The open source is the proof. Prowler Cloud is how you run those checks continuously.

Don’t take our word for it. Here’s what Cloud adds on top of a manual CLI run:

• Continuous scanning across your whole AWS footprint. New debug-mode attestation events surface as findings automatically, with no waiting for the next scheduled scan on someone’s laptop.
• Prescriptive remediation guidance. Every finding includes the exact KMS policy statement, IAM change, or security-group rule that resolves it, with routing to Jira, ServiceNow, Slack, or email so it lands with the right owner.
• Multi-account, single pane. If your enclave workloads live in dedicated compute accounts while KMS keys sit in a security account, Prowler Cloud stitches the picture together across the whole organization.
• Auditor-ready evidence. The 23-framework compliance mapping from OSS becomes exportable evidence packages (NIST 800-53, PCI-DSS, ISO, SOC 2, HIPAA, AWS AI Security Framework) with per-finding attribution.

For teams shipping confidential AI to production, that’s the difference between “we run scans occasionally” and “we can prove, with evidence, that our LLM weights are only ever decrypted inside attested enclaves, and we’re alerted within minutes when they aren’t.”

Stop checking. Start knowing. → Try Prowler Cloud for free.

Disclaimer: This is a community contribution, not an official AWS product feature. Prowler is an independent open-source project. The checks validate customer-managed configuration; they do not audit the AWS Nitro Enclaves service itself, whose isolation guarantees stand independently.