Zero-Knowledge by Architecture, Not by Policy

Most LLM proxies offer a “disable content logging” toggle. That means content logging exists, is probably the default, and someone has to remember to turn it off. One misconfigured environment variable and you’re storing prompts in a database you might not even control.

Our approach is different

VoidLLM doesn’t have a content logging feature to disable. The proxy reads exactly one field from the request body - model - to route the request. Then it streams bytes between client and upstream. No parsing, no storage, no logging of content. Ever.

This isn’t configurable. There’s no ENABLE_CONTENT_LOGGING=true flag because there’s no content logging code to enable. The privacy guarantee is enforced by the absence of code, not by the presence of a setting.

What happens inside the proxy

Here’s what VoidLLM actually touches when a request flows through:

graph TD
  A[Incoming Request] --> B{Read model field}
  B --> C[Resolve in registry]
  C --> D[Build upstream request]
  D --> E[Stream to provider]
  E --> F[Stream response back]
  F --> G[Done]

  B -.->|extract| M1[model name]
  D -.->|set| M2[auth header]
  F -.->|read| M3[token counts]

  M1 --> U[Usage Event]
  M3 --> U
  U -.->|async, non-blocking| DB[(Usage DB)]

  style A fill:#1a1a24,stroke:#333,color:#e2e8f0
  style G fill:#1a1a24,stroke:#333,color:#e2e8f0
  style B fill:#8b5cf6,stroke:#6366f1,color:#fff
  style U fill:#8b5cf6,stroke:#6366f1,color:#fff
  style DB fill:#12121a,stroke:#8b5cf6,color:#e2e8f0

Notice what’s missing from that diagram: there’s no branch where content gets written anywhere. The request body flows through as an opaque byte stream. The proxy doesn’t deserialize the messages array, doesn’t inspect the system prompt, doesn’t buffer the completion text.

What we track vs. what we don’t

graph LR
  subgraph TRACKED["Stored (metadata only)"]
      K[Key ID]
      O[Org + Team]
      MN[Model name]
      T[Token counts]
      CO[Cost estimate]
      D[Duration + TTFT]
  end

  subgraph NEVER["Never stored (content)"]
      P[Prompt content]
      R[Response content]
      S[System prompt]
      F[Function calls]
      I[Images / files]
  end

  style TRACKED fill:#1a1a24,stroke:#22c55e,color:#e2e8f0
  style NEVER fill:#1a1a24,stroke:#ef4444,color:#e2e8f0
  style K fill:#12121a,stroke:#333,color:#e2e8f0
  style O fill:#12121a,stroke:#333,color:#e2e8f0
  style MN fill:#12121a,stroke:#333,color:#e2e8f0
  style T fill:#12121a,stroke:#333,color:#e2e8f0
  style CO fill:#12121a,stroke:#333,color:#e2e8f0
  style D fill:#12121a,stroke:#333,color:#e2e8f0
  style P fill:#12121a,stroke:#333,color:#e2e8f0
  style R fill:#12121a,stroke:#333,color:#e2e8f0
  style S fill:#12121a,stroke:#333,color:#e2e8f0
  style F fill:#12121a,stroke:#333,color:#e2e8f0
  style I fill:#12121a,stroke:#333,color:#e2e8f0

Enough for billing, rate limiting, and debugging - nothing that reveals what was asked or answered.

Why this matters for GDPR

Under GDPR, you must know exactly what personal data you process, where it’s stored, and how to delete it. If your LLM proxy logs prompts - even “temporarily” - those prompts might contain personal data and you need a legal basis to process them.

VoidLLM sidesteps this entirely. Content passes through process memory while streaming between your application and the upstream provider - but it’s never written to disk, database, or log. Once the response is delivered, the buffer is gone. There’s nothing to protect, nothing to delete on request, nothing to include in a data breach notification.