Threat Model for a Confidential LLM Inference Endpoint

A threat model is only as useful as its boundary map. "The cloud is untrusted" is a sentiment, not a model. To reason precisely about where controls go and what residual risk remains after they are applied, you need to name each boundary explicitly and characterize what crosses it.

Five distinct boundaries matter in a confidential inference deployment, and none of them are interchangeable.

The client-to-network boundary is governed by TLS. Content is encrypted, but traffic timing and volume remain observable. An adversary who cannot read the payload can still learn from when requests arrive and how much data flows in which direction. This is easy to underestimate precisely because TLS is so well understood.

The network-to-inference-host boundary covers authentication, rate limiting, and endpoint exposure. It is the perimeter most commonly misconfigured in practice. GreyNoise honeypot data logged more than ninety thousand attack sessions targeting exposed LLM endpoints in roughly a three-month window between late 2025 and early 2026. That number does not suggest a sophisticated adversary problem; it suggests a hygiene problem, one that is widespread enough to be treated as a baseline assumption.

The host operating system and hypervisor boundary separates privileged software from the inference process. Root compromise or a rogue hypervisor can read process memory directly. This boundary is the primary motivation for Trusted Execution Environment deployments, which we will return to.

The CPU-to-GPU boundary, meaning the PCIe bus and GPU memory, is where model weights and activations travel continuously during inference. Without confidential GPU support, that crossing can be observable to a sufficiently positioned attacker. This boundary receives surprisingly little attention in enterprise deployments given how much sensitive material crosses it.

The fifth boundary is the one least discussed: the inference process to application layer, where prompt parsing, tool calls, RAG retrieval, and agentic function calls actually execute. No hardware isolation mechanism touches this boundary. Its exposure is total, and it is often where the most consequential attacks land.

Two canonical roles structure the trust problem itself. The cloud provider holds model weights and operates infrastructure; the client holds sensitive prompts. Both can be simultaneously adversarial in different directions, which makes this framing unusual compared to most security models. The provider follows the protocol to maintain business trust but may have incentive to analyze prompts and responses, reconstruct client attributes, or improve the model on client data. The client follows the protocol to receive outputs but may probe to reverse-engineer weights or extract other users' information. Neither behavior requires bad faith in the colloquial sense. An honest-but-curious framing is sufficient to motivate the threat, and that distinction matters: you cannot screen for it, because the surface behavior is identical to legitimate use.

Multi-tenancy amplifies every boundary risk. Shared infrastructure means one tenant's cache state, memory allocation, or timing signal can become observable to another. The boundary between tenants is itself a trust surface, and most cloud deployments treat it implicitly rather than explicitly.

Agentic pipelines extend the map further still. Each tool integration, external API call, and memory store is an additional trust boundary that inherits all upstream risks. An agent that retrieves from an external knowledge base and calls a third-party API has a trust surface orders of magnitude larger than a simple prompt-response loop. It is rarely modeled as such.

Attacker Profiles Ranked by Capability and Position

Threat modeling loses its precision when adversaries are treated as a monolithic category. The controls appropriate for a nation-state actor with physical hardware access are different from, and far more costly than, those appropriate for an authenticated user making API calls. Getting specific about attacker position, capability, and goal prevents controls from being simultaneously under- and over-specified, which in my experience is the failure mode that shows up most often in security architecture reviews: teams spending on the wrong threat because they never disaggregated the attacker.

Tier 1: Privileged insider or compromised infrastructure operator. This attacker can read process memory, access GPU VRAM, inspect KV-cache storage, or replay network traffic before encryption. Their goal is to extract client prompts, reconstruct sensitive inputs, or exfiltrate model weights. What makes this tier realistic rather than theoretical is that cloud administrators routinely hold this access as a feature of conventional deployments. The threat model does not require malice; routine access is sufficient.

Tier 2: Physical attacker with node access. Apple's Private Cloud Compute threat model explicitly names this actor: sophisticated, well-resourced, and capable of subverting hardware security properties to extract data from active compute nodes. Goals include attestation-key extraction, cold-boot memory capture, and PCIe bus interception. Research has demonstrated attestation-key extraction via memory interposition. If that succeeds, remote attestation guarantees are entirely invalidated; a client cannot trust the enclave measurement they verified, because the signing infrastructure itself has been compromised.

Tier 3: Malicious co-tenant, network-adjacent. Shares physical infrastructure but holds no privileged access. Can observe timing signals, cache state, or resource contention without any credentials. This attacker is the natural subject of KV-cache timing attacks, which we will examine in detail.

Tier 4: External API attacker. No privileged position; interacts only through the inference endpoint. Two sub-profiles exist here. The unauthenticated attacker exploiting exposed endpoints is what the GreyNoise data reflects. The authenticated user mounting extraction or injection attacks through legitimate API access is arguably more consequential, because they are indistinguishable from legitimate users and operate entirely within granted permissions. Standard monitoring is not designed to catch them.

Tier 5: Supply-chain or upstream attacker. Compromises the model, training data, dependencies, or attestation infrastructure before deployment. Their goal is a persistent backdoor, poisoned outputs, or covert weight exfiltration that survives the deployment boundary entirely. They are the hardest to detect because their artifact looks like a legitimate component.

Attacker goals cluster usefully into four categories: prompt and data extraction, model IP theft, output manipulation, and availability degradation. Mapping controls to this taxonomy is more tractable than mapping them to individual attack techniques, and it forces a discipline that most security programs skip.

Application-Layer Attacks That Operate Above Any Hardware Boundary

Hardware isolation is not application security. A model server running inside a Trusted Execution Environment, executing vulnerable application logic, still exposes data through its API. The enclave boundary guarantees that the hypervisor cannot read the process memory. It says nothing about what a crafted prompt can coax out of the model. These are different problems, and conflating them is a category error with real consequences.

Prompt Injection

Prompt injection holds first place in the OWASP Top 10 for LLM Applications as of 2025, for the second consecutive year. The structural reason it persists is that LLMs process instructions and data in the same channel, with no enforced separation between them. The model has no reliable way to distinguish "interpret this as content" from "interpret this as a new instruction." An attacker who can influence the input, directly or indirectly, can exploit that ambiguity. The capability being exploited is the model's instruction-following behavior, which is also the reason anyone is deploying it.

The direct variant is conceptually simple: craft an input that overrides or extends the system prompt, redirects model behavior, or extracts information the system prompt was meant to protect. The indirect variant is subtler and more dangerous in agentic contexts. Malicious content injected into a RAG source, a retrieved document, or a tool output poisons the model's context without any direct API access. The attacker's instruction arrives through a data channel the system already trusts, which is what makes it so difficult to filter.

In agentic pipelines, successful injection can redirect tool calls, exfiltrate retrieved context, or issue commands to downstream systems. Every external integration adds surface. The model's usefulness and its susceptibility to this attack grow from the same root.

Sensitive Information Disclosure

Sensitive information disclosure rose from sixth to second place in OWASP's 2025 rankings. That movement reflects accumulating evidence that models reproduce training data fragments under targeted queries: personally identifiable information, proprietary documents, credentials. Two sub-cases warrant separation.

Training data extraction involves queries designed to cause the model to emit memorized content. System prompt extraction involves conversational manipulation that coaxes out business logic, API endpoints, or access secrets embedded in the system prompt. Both have been demonstrated against deployed systems in the wild.

Membership inference extends this further. An adversary testing whether a specific example appeared in context can detect it because the model assigns measurably higher probability to members than to non-members. Combined with jailbreaking techniques, this can escalate to direct demonstration extraction.

Both attack classes execute through the legitimate inference API. Infrastructure access is not required. Whatever the hardware isolation layer provides, it provides nothing here.

KV-Cache Attacks: How Inference Efficiency Becomes a Privacy Liability

The KV cache exists because transformer inference is expensive. Recomputing attention keys and values for every token in a long context wastes computation that has already been done, and that waste compounds at scale. Caching those intermediate values is the standard optimization, responsible for a meaningful portion of the throughput that makes serving large models economically viable. The tension is that efficiency and isolation pull in opposite directions, and the KV cache sits precisely at that intersection.

The cache stores intermediate attention computations derived from user inputs. Those tensors encode information about the prompts that generated them. While communication between user and server is encrypted in transit, the KV cache is typically transmitted and stored in plaintext, exposing it at the infrastructure layer.

Research accepted at NDSS 2026 (Luo et al., "Shadow in the Cache") demonstrated three distinct attack classes against KV-cache systems. The inversion attack reconstructs sensitive user inputs directly from cached key-value tensors. The collision attack infers input content by detecting cache collisions without requiring direct tensor access, which makes it more broadly applicable across deployment configurations. The injection attack manipulates cache state to influence other users' outputs through semantic manipulation.

A separate class of timing side-channel attacks requires no infrastructure access at all. Time-to-first-token varies measurably between cache hits and misses, a property inherent to how prefix caching works. Tools such as PromptPeek and InputSnatch, documented in the research literature, reconstruct user prompts via time-to-first-token measurements in purely black-box settings. The attacker issues crafted queries, measures response latency, and iteratively narrows down the prefix tokens a victim used in a prior request. No credentials, no infrastructure access, no deviation from the legitimate API.

This class of side channel does not exist in conventional API services. It is a direct consequence of the performance optimization that makes LLM serving tractable. The efficiency and the vulnerability are the same feature, which is what makes the mitigation problem genuinely hard.

Defenses involve real tradeoffs, and none of them are clean. Per-user cache isolation eliminates cross-user leakage but surrenders the throughput gains that motivated caching. Cache encryption protects stored tensors from infrastructure-level access but does not address timing channels. Injecting noise into time-to-first-token measurements degrades the timing signal but introduces latency variability that affects user experience. No approach eliminates all three attack vectors simultaneously without cost. Any deployment that does not acknowledge the residual risk is not reasoning clearly about what it has actually protected.

Model Extraction and IP Theft Through the Inference API

Model extraction requires only the ability to send inputs and observe outputs. No weights, no training data, no infrastructure access. The attacker queries the deployed model with carefully chosen inputs, collects input-output pairs, and trains a surrogate model that approximates the original's decision boundaries and, in some cases, its architecture. The threat is entirely contained within the legitimate interface.

A documented case from 2024 illustrates the economics clearly. Researchers extracted a fine-tuned clinical LLM via its customer-facing API; the surrogate achieved approximately ninety-four percent of the original's performance on clinical tasks at an extraction cost below one thousand dollars. Training and fine-tuning a large model can cost tens of millions of dollars. An extraction cost in the hundreds of dollars collapses the economic moat that IP protection is supposed to defend.

Fine-tuned models carry compounded risk. The base model is extractable, and the fine-tuning signal, which may encode proprietary clinical, financial, or legal data, is partially recoverable through the surrogate. The intellectual property at risk is not only the architecture but the domain adaptation that represents the most defensible competitive asset.

The extraction attacker maps cleanly onto the honest-but-curious client from the trust boundary model: follows the protocol, never exceeds API permissions, and is indistinguishable from legitimate heavy users until a surrogate model appears in the market or a competitor's product starts exhibiting suspiciously familiar behavior.

Controls exist but are meaningfully limited. Rate limiting and query monitoring can slow extraction but cannot stop a patient attacker operating across multiple accounts. Output perturbation, adding noise to logits, degrades surrogate quality but also degrades legitimate user experience and can be overcome with a larger query budget. Watermarking model outputs enables detection after the fact but does not prevent the theft. TEEs protect weights at rest and in use from infrastructure-level access and are a meaningful control against Tier 1 and Tier 2 attackers. They offer nothing against extraction through the legitimate API, because that interface is precisely what the TEE is designed to serve. That is not a criticism of TEEs; it is a description of scope.

Side-Channel Attacks on TEE Infrastructure and the Limits of Hardware Isolation

Trusted Execution Environments represent the current ceiling of hardware-enforced isolation. Intel TDX, AMD SEV-SNP, and NVIDIA's Confidential Compute implementations on Hopper and Blackwell provide memory encryption, integrity protection, and remote attestation. Against a rogue hypervisor or a compromised infrastructure operator, these are the most powerful available controls. NVIDIA's H100 Confidential Compute implementation incurs throughput penalties in the single-digit percentage range that diminish as batch and input sizes increase: real, but manageable at scale. IDC's July 2025 study of six hundred IT leaders found that three-quarters of organizations were already using or piloting Confidential Computing, suggesting the performance tradeoff is increasingly accepted in practice.

The question worth sitting with is not whether TEEs work. It is precisely what they guarantee, and where those guarantees stop.

Demonstrated Vulnerabilities

The research record on TEE vulnerabilities is more developed than enterprise security practices tend to reflect. Confidentiality leakage via instruction counts, performance counters, and deterministic ciphertext patterns has been demonstrated: all observable from outside the enclave, all exploitable without breaking the cryptographic boundary directly. Forged attestations have been demonstrated on AMD SEV-SNP. Malicious hypervisor read and write access has been demonstrated on Intel TDX trust domains.

Attestation-key extraction via memory interposition deserves particular attention because the consequence is total. If an attacker recovers the attestation key, the client's verification of the enclave measurement becomes worthless. The client performed the verification correctly; the infrastructure that signed the measurement is simply compromised. The attack does not break the protocol; it undermines the trust assumption the protocol rests on.

Cache-timing and speculative execution attacks remain active research areas across TEE implementations. The gap between laboratory demonstration and reliable exploitation in production is real, but that gap should not be mistaken for the absence of risk. It means the risk is not yet fully operationalized, not that it is not there.

What Remote Attestation Actually Guarantees

Remote attestation is often presented as the mechanism that makes confidential computing trustworthy. It deserves more careful treatment than it usually gets. Attestation proves what code is running inside the TEE at the moment of measurement. The manufacturer's signing key binds the TEE output to a code measurement, giving the client cryptographic evidence of the enclave's contents. That is meaningful and non-trivial.

It does not prove that the code is free of application-layer vulnerabilities. It does not prove that the model weights are the version claimed. It does not prove that the attestation infrastructure itself is uncompromised. Centralized attestation infrastructure, managed by the chip vendor, is a supply-chain dependency: a single point of trust that, if compromised, undermines the verification chain for every enclave the vendor has ever signed. That dependency is structural, and it does not disappear because the cryptography around it is sound.

What emerges from laying this out carefully is not an argument against TEEs. They address real threats from Tier 1 and Tier 2 attackers in ways that no software control can replicate, and dismissing them because they are imperfect would be its own category error. The argument is against treating TEE deployment as a solution to the threat model rather than a partial answer to a subset of it. The application layer remains exposed. The KV cache creates side channels that hardware isolation does not touch. Extraction through the API proceeds regardless of what protects the weights underneath. Attestation, the mechanism meant to give clients confidence, rests on infrastructure that is itself an attack surface.

A rigorous threat model does not conclude with the deployment of a strong control. It asks what that control addresses, what it explicitly does not address, and what remains. That remainder is the residual risk that an honest security program has to own, and in LLM inference, that remainder is larger than most practitioners have accounted for.