Skip to main content
When building production applications with Tinfoil, you typically need to keep your TINFOIL_API_KEY on your backend — exposing it to client browsers would let anyone use your API quota. At the same time, you want prompts and completions encrypted end-to-end to the attested enclave, not just to your server. A proxy server running on your backend solves this. It sits between your client and the Tinfoil enclave, adding your API key, authenticating users, tracking usage, or applying rate limiting — while the Encrypted HTTP Body Protocol (EHBP) ensures request and response bodies stay encrypted end-to-end. EHBP encrypts at the application layer using HPKE, completely separate from TLS, so your proxy can read and modify HTTP headers without ever seeing the plaintext data. Every Tinfoil SDK also automatically verifies that the HPKE key comes from an attested secure enclave.

Client Setup

The credential passed to the client is a token for your proxy, not your backend’s TINFOIL_API_KEY. Your proxy should authenticate the token, remove it, and add TINFOIL_API_KEY before forwarding the request.
JavaScript, Python, Go, and Swift route both inference and attestation requests through your proxy when you set its URL as both the API base URL and attestation bundle URL. The SDK still verifies the attestation bundle client-side regardless of where it was fetched from. When the SDK sends requests through a proxy (i.e., baseURL differs from the enclave URL), it includes the enclave URL in the X-Tinfoil-Enclave-Url header. Your proxy should use this header to determine where to forward requests, ensuring the encrypted payload reaches the same enclave that the client verified.
baseURL or base_url must point at your proxy, not a Tinfoil enclave. Include /v1/ for JavaScript, Python, and Go. Swift and Rust append API paths themselves.

Proxy Server Setup

Your proxy’s job is to preserve the EHBP protocol headers that coordinate encryption between client and enclave, add your authentication credentials, and forward the encrypted payload. No special cryptographic libraries are needed — the proxy never participates in encryption or decryption. While we provide an example implementation in Go below, the proxy pattern works with any language that can handle HTTP requests. The example repository provides a complete reference implementation with a Go proxy and a TypeScript client.

Required Endpoints

Your proxy needs to implement these routes: The example below forwards every /v1/ path so chat completions, responses, embeddings, audio, and other supported APIs use the same encrypted route.

Required Headers to Preserve

The EHBP protocol uses specific headers to coordinate encryption keys between the client and enclave. Your proxy must forward these headers unchanged in both directions. For requests, you need to preserve Ehbp-Encapsulated-Key (the HPKE encapsulated key, hex-encoded, 64 characters). For responses, you need to preserve Ehbp-Response-Nonce (the 32-byte nonce used in response key derivation, hex-encoded, 64 characters). Understanding the body framing format isn’t necessary for proxy implementation, but it helps explain why these headers are critical—they contain the cryptographic material needed for key derivation and decryption.

CORS Configuration

If your proxy will be called from browser-based applications, you’ll need to configure CORS headers to allow the browser to send and read the encryption headers. The key requirement is exposing the EHBP headers in both directions:

Implementation Example

Usage Metrics for Billing

Since EHBP encrypts request and response bodies, your proxy cannot read token counts from the JSON. Tinfoil provides usage metrics via HTTP headers so you can track usage and bill your users. To enable this, add the X-Tinfoil-Request-Usage-Metrics: true header when forwarding requests to the enclave. Tinfoil returns token counts in the X-Tinfoil-Usage-Metrics response header for non-streaming requests, or as an HTTP trailer after the body completes for streaming requests. The format is:
For example:
See the example repository for a complete implementation.

Custom Headers

Beyond the required EHBP headers, you can use custom HTTP headers to build your own application-level protocols between the client and proxy. Since EHBP only encrypts bodies, headers remain visible to the proxy — which means you can authenticate users, track requests, implement rate limiting, or pass feature flags without any of that metadata reaching the enclave.

Request Headers

The JavaScript SDK’s lower-level SecureClient lets you send arbitrary headers and inspect the raw response:
Your proxy can then read and strip these headers for logging, routing decisions, or authentication checks before forwarding the encrypted request to the enclave:
Just remember to add any custom headers you use to your CORS Access-Control-Allow-Headers configuration so browsers can send them.

Response Headers

Your proxy can add custom headers to responses that the client can read. This is useful for communicating rate limit information, cost tracking, or request IDs for debugging:
The client can then access these headers:
As with request headers, you’ll need to expose custom response headers in your CORS Access-Control-Expose-Headers configuration for browsers to access them.

Security Considerations

While EHBP encrypts the request and response bodies, the HTTP headers remain visible throughout the proxy chain. This design is intentional—it’s what allows proxies to route and manage requests—but it has important security implications.
Never expose your TINFOIL_API_KEY to client applications. The entire purpose of the proxy architecture is to keep this key on your backend.
  • Use HTTPS in production. While request and response bodies are encrypted at the application layer, HTTP headers (including custom headers like user IDs) are only protected by transport-layer encryption.
  • Allowlist enclave destinations. Treat X-Tinfoil-Enclave-Url as untrusted input and only forward to approved HTTPS Tinfoil enclave origins. This prevents clients from using your proxy to reach arbitrary hosts.
  • Validate and sanitize custom headers from clients. Treat them as untrusted input — check formats, guard against injection attacks, and authenticate before trusting client-provided values.
  • Always preserve and forward the EHBP headers (Ehbp-Encapsulated-Key for requests, Ehbp-Response-Nonce for responses). Dropping or modifying them will cause decryption to fail.

How It Works

The data flow shows how encryption is maintained throughout the request lifecycle:
This diagram shows the proxied attestation flow used by JavaScript, Python, Go, and Swift. Rust performs attestation directly against the enclave before routing encrypted inference requests through your proxy.

Next Steps

For a complete working example, check out the encrypted-request-proxy-example repository. It includes a Go proxy implementation with streaming support, a TypeScript browser client demonstrating the SecureClient, and custom header handling examples.

Example Repository

Go proxy server with TypeScript browser client

Encrypted HTTP Body Protocol

Deep dive into the EHBP specification