Skip to main content
Summary: Prem API combines client-side encryption with confidential-computing hardware and attestation evidence. The strength of any claim depends on the verified evidence, an approved measurement/TCB policy, and the route that processed the request. The current limitations are documented below and on Attestation.

​
The Problem With Trust

Each AI API provider tells you that your data is safe. But traditional security relies on trust:
  • Trust that employees do not access server memory
  • Trust that the infrastructure provider does not inspect VMs
  • Trust that the privacy policy matches the actual implementation
  • Trust that a breach did not already occur
Prem API combines hardware isolation with attestation evidence. A complete decision still requires manufacturer trust, approved measurements and TCB policy, route assurance, and deployment-specific controls.

​
Trusted Execution Environments: The Foundation

A Trusted Execution Environment (TEE) is designed to isolate a workload and its memory from the host operating system and hypervisor. The exact confidentiality and integrity guarantees depend on the hardware architecture, firmware, configuration, and known vulnerability state.

Protected memory

Confidential-computing hardware protects designated workload memory according to the selected CPU or GPU architecture and configuration.

Host isolation

A TEE is designed to restrict the host operating system and hypervisor from reading or modifying protected workload memory.

Measured state

Hardware evidence carries architecture-defined measurements. A verifier must compare them with an approved reference before treating a change as a policy failure.

Provable Integrity

The TEE can produce hardware-signed evidence that includes measurements and security claims. A verifier must compare those values with an approved policy before concluding that the expected workload is running.

​
An Analogy

As a mental model, think of a sealed request processed inside a restricted chamber and returned in a new sealed envelope. The model explains the intended data boundary. It does not replace the hardware threat model, attestation policy, or software review.

​
CPU Confidential Computing

Prem API enclaves run on Confidential Virtual Machines (CVMs) with:
  • AMD SEV-SNP: Protects guest memory with hardware-managed keys and supplies an attestation report for policy evaluation.
  • Intel TDX: Creates an Intel trust domain with protected memory and a quote for policy evaluation.
Reticle implements separate evidence-verification paths for SEV-SNP and TDX. Their evidence formats, trusted computing bases, and security properties are not interchangeable.

​
GPU Confidential Computing

GPU-backed inference introduces a second protected component. Reticle processes NVIDIA overall and detached GPU tokens, their signatures, digest links, and nonce claims. The current public result does not expose per-GPU verdicts or prove scheduler binding, and the selected per-GPU check semantics need code-owner review. Confidential-computing support also depends on the deployed GPU SKU, firmware, driver stack, and mode. “Hopper” and “Blackwell” are architecture-family labels, not attestation results. The CPU-to-GPU path and every plaintext-processing component must be included in the deployment threat model. GPU evidence does not automatically prove the complete application path.

​
The Infrastructure Locations

Prem API deployments can use Prem-owned hardware and rented provider capacity. Confirm the exact location, operator, hardware, and policy for the route that your workload uses. TEE evidence can reduce trust in the physical and cloud operator in both owned and rented environments. It does not make their complete operational risk identical. Physical controls, administrator access, firmware supply chain, geography, and incident response remain separate audit inputs.
  • Owned infrastructure: Prem controls more of the physical and operational stack. Attestation evidence does not replace physical-security and change-management review.
  • Rented infrastructure: The provider controls the physical host. Confidential-computing controls are designed to restrict host access, while attestation evidence lets a client inspect hardware claims and freshness.
For compliance teams: Manufacturer evidence is one audit input. Current CPU Reticle verification authenticates evidence and freshness but does not yet compare measurements with an approved release reference. Geography and infrastructure ownership remain independent controls.
Legal scope: Confidential computing can reduce the plaintext held by infrastructure operators, but it does not eliminate legal obligations, metadata disclosure, endpoint access, or jurisdictional risk. Obtain jurisdiction-specific legal advice for regulated deployments.

​
Confidential processing boundary

The intended boundary includes every service that decrypts or processes protected content. The Prem API Gateway handles encrypted payloads plus API-key, model, size, timing, routing, and billing metadata. A local Confidential Proxy is a separate plaintext component on the client side. The current public response does not expose a complete route-assurance profile. Verify the selected model path and deployment policy before transferring confidential-compute claims to a specific model.

​
Attestation evidence and policy

Attestation supplies evidence for selected hardware and workload claims. The client still needs an explicit acceptance policy: The attestation report tells you:
  1. Measurements and claims: The report carries hardware-defined measurements and security-relevant fields.
  2. Evidence authenticity: The verifier validates the applicable manufacturer certificate or key chain.
  3. Freshness: The report contains the verifier’s nonce.
  4. Policy decision: A separate policy must decide whether measurements, TCB, debug, and confidential-mode claims are acceptable.
Reticle can compile to WebAssembly for supported JavaScript environments. A browser integration can therefore run the verifier locally, but it must still use trusted collateral, approved references, and an explicit failure policy.
For non-technical readers: Attestation is comparable to a signed hardware inspection record. The signature authenticates the source of the evidence. Your policy still decides whether the reported configuration is acceptable.
See Attestation for the full technical detail: CPU reports, GPU EAT tokens, certificate chains, and verification code examples.

​
Layers of Defense

Prem API uses several controls for different risks. These controls are not interchangeable, and one control does not guarantee that another remains effective after a failure:

​
Common Questions

The intended network-gateway exposure is encrypted content plus operational metadata. A compromise can still affect availability, routing, replay attempts, metadata, and software supply chain. The local Confidential Proxy is a plaintext component and must be secured separately.
Distinguish the Prem API Gateway from the local Confidential Proxy. The gateway is intended to handle ciphertext and operational metadata. The local proxy handles plaintext, the API key, and the KEK on your machine; compromise of that local process can expose content and credentials.
The observed payload is encrypted by TLS and the client payload-encryption layer. Security still depends on correct endpoint authentication, key handling, implementation, and the assumptions of the hybrid key exchange.
Prem API uses a hybrid exchange that combines ML-KEM768 and X25519. The design reduces reliance on X25519 alone for the harvest-now, decrypt-later threat model. It does not support an absolute claim about future cryptographic security.
TEE isolation is intended to restrict host access, while deployment access controls and change management reduce operator risk. The current CPU verifier does not yet compare measurements with an approved release reference, so operational controls and audit evidence remain necessary.
Hardware evidence contains measurements that can change when measured components change. Detection requires a verifier to compare those values with an approved reference. That expected-measurement check remains TODO in the reviewed SEV-SNP and TDX client paths.
Reticle is implemented in Rust and can compile to WebAssembly. Rust prevents many memory-safety bugs in safe code, while unsafe code, dependencies, logic errors, policy errors, and runtime vulnerabilities still require review and testing.
Confidential-computing hardware is designed to reduce trust in the host operator. Manufacturer evidence, approved measurements, firmware policy, physical controls, and incident response must all be evaluated; infrastructure ownership does not make those risks identical.

​
Shared Responsibility Model

Prem operates the managed infrastructure and protected-runtime controls. Customers remain responsible for their applications, local proxy hosts, keys, tool integrations, and workload policy.

​
The responsibilities of Prem

  • Prem operates the confidential-computing and attestation infrastructure
  • Prem maintains the documented transport, payload-encryption, and protected-processing controls
  • Prem maintains the documented model serving and protected-runtime controls
  • Prem manages the physical infrastructure security and the platform availability

​
Your responsibilities

  • Key management: Generate, store, and rotate your encryption keys, for example the Key Encryption Key (KEK). Do not lose your master key. If you lose it, Prem cannot recover your data.
  • Application security: Secure the endpoints and devices where the Prem API SDK runs. The SDK decrypts data on your local hardware.
  • Prompt and model level security: Defend against prompt injections and jailbreaks in your specific AI workflows.

​
Limitations

No security system is absolute. The limitations above define the current assurance boundary and the checks that remain necessary.
Prem API does not protect against:
  • Hardware-level side-channel attacks: Researchers found theoretical and practical side-channel vulnerabilities in TEE hardware. The manufacturers patch these vulnerabilities. The attestation reports include the firmware versions, so you can check the patch levels and we can enforce minimum requirements. Side-channel attacks could be possible in theory. But Prem API selects deployment locations that meet strict security criteria and can apply counter mechanisms to detect invalid states. This is an industry-wide challenge, not a challenge unique to Prem API.
  • A compromised hardware manufacturer: If the root signing keys of AMD, Intel, or NVIDIA are compromised, the attestation guarantees become weaker. This is the shared root of trust for the full confidential computing industry.
  • Model behavior: Prem API protects the privacy of your data during processing. Prem API does not control what the AI model itself does with context during a single inference pass. For example, model memorization is a model-level concern, not an infrastructure concern.
  • Metadata: The Prem gateway handles time, payload size, API key, model, routing, billing, and rate-limit metadata. Payload confidentiality depends on the client encryption path and the selected processing route.
See the Encryption reference for the full cryptographic specification. Continue to Attestation for the attestation detail: reports, tokens, and verification code.