Skip to main content
Summary: In ZDR mode your content is plaintext at the Prem API Gateway and at the trusted partner. Prem does not keep it, and the partner does not keep it. A contract and operational controls give the guarantee. Hardware and cryptography do not give it.

​
The path of a request

Two components can read your content: the Prem API Gateway and the partner. TLS 1.3 protects the two network connections. This path does not use a Trusted Execution Environment (TEE). The confidential path is different. Your device encrypts the payload, and only a sealed enclave can decrypt it. See How It Works.

​
What Prem records

Prem filters each ZDR request body through a strict allowlist. This filter operates before Prem writes a log record. Prem can record only these fields: model, stream, stream_options, temperature, top_p, n, seed, max_tokens, max_completion_tokens, presence_penalty, and frequency_penalty The messages field is not on the allowlist. Your prompts never reach the request log. Prem does not send the response body to the logger. The gateway sends the completion to you. Then it records only the status code, the model name, and the environment. Your completions never go into the response log. The usage record holds the token counts and the price for each request. It holds no content.

​
What the trusted partner records

Nothing. Each partner operates under an agreement. The agreement tells the partner that it must not keep your content. The partner must not write your content to a log or to a cache. The partner must not use your content to train a model. No person at the partner can read your content. Prem makes sure of this with a contract and with an operational review. You cannot make sure of it yourself with a technical control. This is the most important difference from confidential inference.

​
What ZDR does not protect against

ZDR does not protect against:
  • Access to the Prem infrastructure. The Prem API Gateway processes your content in memory. Access controls and audit logs limit this exposure. Hardware does not stop it.
  • Access to the partner infrastructure. The partner processes your content in plaintext on standard compute. The zero-retention agreement limits what the partner can do. Hardware does not stop it.
  • A breach of contract. A partner can disobey the agreement. No technical control at Prem finds this condition.
  • A legal order. A valid legal order can make Prem give the data that is available at that time. The content is not available after the response. The metadata is available.
  • The behavior of a model. Prem does not have control of what a model does with the context in one inference pass.
A contract and operational controls stop retention. Mathematics does not stop it. There is no attestation evidence for a ZDR request. There is no cryptographic guarantee.

​
When this boundary is not sufficient

Use confidential inference when a plaintext boundary at the provider is not acceptable. In confidential mode your device encrypts the payload. Only a sealed enclave can decrypt it. The hardware supplies signed evidence, and this evidence lets you examine the runtime that processed your request. See Security Model and Attestation.
See ZDR compared with confidential inference for the decision matrix.

​
Your responsibilities

  • Choose the correct mode. Send sensitive content to the confidential routes, not to ZDR.
  • Protect your API key. The key authenticates each request. Prem also uses the key for billing. See API Keys.
  • Make your application secure. Your content is plaintext in your own application and on your own hosts.
  • Defend against prompt injection. Security at the model level and at the prompt level stays your responsibility.

ZDR compared

ZDR, confidential inference, and a typical inference provider.

Confidential Security Model

The threat model for the confidential path, with its limitations.

Data Retention

The retention policy for confidential inference.

Trust & Compliance

Certifications, audits, and independent verification.