Search papers, labs, and topics across Lattice.
This paper investigates the reliability of LLM assistants, specifically ChatGPT-5.2 and Claude Opus-4.6, when used as security advisors for Trusted Execution Environments (TEEs). The authors introduce TEE-RedBench, a novel evaluation methodology comprising a TEE-specific threat model, a structured prompt suite, and an annotation rubric to assess the LLMs' performance across various TEE-related tasks. The study reveals that certain failures transfer across LLMs and proposes an "LLM-in-the-loop" evaluation pipeline to mitigate these failures, achieving an 80.62% reduction in errors.
LLM security advisors for TEEs can fail in similar ways, but a simple "LLM-in-the-loop" pipeline slashes those failures by 80%.
Trusted Execution Environments (TEEs) (e.g., Intel SGX and ArmTrustZone) aim to protect sensitive computation from a compromised operating system, yet real deployments remain vulnerable to microarchitectural leakage, side-channel attacks, and fault injection. In parallel, security teams increasingly rely on Large Language Model (LLM) assistants as security advisors for TEE architecture review, mitigation planning, and vulnerability triage. This creates a socio-technical risk surface: assistants may hallucinate TEE mechanisms, overclaim guarantees (e.g., what attestation does and does not establish), or behave unsafely under adversarial prompting. We present a red-teaming study of two prevalently deployed LLM assistants in the role of TEE security advisors: ChatGPT-5.2 and Claude Opus-4.6, focusing on the inherent limitations and transferability of prompt-induced failures across LLMs. We introduce TEE-RedBench, a TEE-grounded evaluation methodology comprising (i) a TEE-specific threat model for LLM-mediated security work, (ii) a structured prompt suite spanning SGX and TrustZone architecture, attestation and key management, threat modeling, and non-operational mitigation guidance, along with policy-bound misuse probes, and (iii) an annotation rubric that jointly measures technical correctness, groundedness, uncertainty calibration, refusal quality, and safe helpfulness. We find that some failures are not purely idiosyncratic, transferring up to 12.02% across LLM assistants, and we connect these outcomes to secure architecture by outlining an"LLM-in-the-loop"evaluation pipeline: policy gating, retrieval grounding, structured templates, and lightweight verification checks that, when combined, reduce failures by 80.62%.
