How I built an OpenAI-compatible prompt encryption proxy in 300 lines of Python

Xjz · Builder — Fri, 17 Jul 2026 07:56:39 +0000

I sell GPT prompts. Small business, $20-50 per prompt, mostly to people who use ChatBox or Cursor. Last month, one of my buyers screenshotted my prompt text and posted it in a Discord server. Within 24 hours, three other people were reselling it on Telegram. I felt sick.

The obvious fix — "just don't ship the prompt text" — sounded dumb until I realized that's exactly what every SaaS does. ChatGPT doesn't ship OpenAI's system prompt. Midjourney doesn't ship its prompt. They ship access.

So I built a tiny proxy. ~300 lines of Python, FastAPI, and httpx. OpenAI-compatible. Streaming. Bearer key auth. The prompt lives on my server, the buyer gets an API URL + key, they point their client at it, my server injects the system prompt, forwards to the AI provider, returns the response. The buyer never sees the prompt text.

This post walks through the architecture, the interesting bits, and a few mistakes I made along the way. The full Lite version is open-source on GitHub. The Pro version with encrypted storage + multi-tenant + admin panel is self-host paid — but everything in this article is in the open-source Lite version.

The problem in one diagram

[Buyer's ChatBox]                     [My server]                    [DeepSeek API]
       |                                   |                                |
       |  POST /v1/chat/completions        |                                |
       |  Authorization: Bearer sk-...     |                                |
       |  {model, messages: [{user,...}]}  |                                |
       | --------------------------------> |                                |
       |                                   | 1. verify bearer key           |
       |                                   | 2. load prompt from config     |
       |                                   | 3. prepend as system message   |
       |                                   | 4. forward to upstream         |
       |                                   | ------------------------------>|
       |                                   |                                |
       |                                   |  <--- response (stream ok) ----|
       |                                   |                                |
       |  <--- stream chunks --------------|                                |
       |                                   |                                |

The buyer's request is identical to what they'd send to OpenAI. The only difference is the URL and the API key.

The interesting bits

1. Streaming without buffering

The buyer is waiting for tokens. If you buffer the entire upstream response before returning, you've killed the UX.

async def _stream_upstream(url, headers, payload):
    timeout = httpx.Timeout(connect=10.0, read=120.0, write=10.0, pool=10.0)
    async with httpx.AsyncClient(timeout=timeout) as client:
        async with client.stream("POST", url, headers=headers, json=payload) as resp:
            if resp.is_error:
                body = await resp.aread()
                err = json.dumps({"error": {"code": resp.status_code, "message": body.decode("utf-8", "replace")}})
                yield f"data: {err}\n\n"
                yield "data: [DONE]\n\n"
                return
            async for line in resp.aiter_lines():
                if not line:
                    continue
                if line.startswith("data:"):
                    yield line + "\n\n"
                else:
                    yield f"data: {line}\n\n"
    yield "data: [DONE]\n\n"

FastAPI's StreamingResponse will iterate this async generator and flush each chunk to the client immediately. No buffering. The buyer sees the first token as soon as the upstream emits it.

Mistake I made first: I returned response.aiter_raw() directly without re-emitting the data: prefix. ChatBox silently ate the stream because it expected SSE format. Always re-emit in SSE format.

2. System prompt injection (with merge)

The buyer may have configured their own system prompt in ChatBox. You don't want to overwrite it — you want to prepend yours.

def _inject_system_prompt(messages):
    config = load_prompts()
    system_text = (config.get("system_prompt") or "").strip()
    if not system_text:
        return messages

    if messages and messages[0].get("role") == "system":
        merged = {
            "role": "system",
            "content": system_text + "\n\n" + messages[0].get("content", ""),
        }
        return [merged, *messages[1:]]

    return [{"role": "system", "content": system_text}, *messages]

Mistake I made first: I appended my system message at the end of the message list. The model treated it as a user instruction and the buyer's prompt leaked through. Always prepend, always merge if there's already a system message.

3. API key auth with constant-time comparison

import secrets
from fastapi import Header, HTTPException, status

async def verify_client_key(authorization: str | None = Header(default=None)) -> str:
    if not authorization or not authorization.lower().startswith("bearer "):
        raise HTTPException(status_code=401, detail="Missing or invalid Authorization header")
    token = authorization[7:].strip()
    for configured in settings.client_keys:
        if secrets.compare_digest(token, configured):
            return token
    raise HTTPException(status_code=401, detail="Invalid API key")

secrets.compare_digest is constant-time. token == configured is not — it short-circuits on the first different byte, which leaks key length and prefix info via timing. For 32-character API keys this is a minor risk, but it's free to do correctly.

4. Forcing the upstream model (optional, but useful)

Some buyers will configure gpt-4 in their client even though your upstream is DeepSeek. You can either reject the request or silently override:

def _override_model(model):
    forced = (load_prompts().get("force_model") or "").strip()
    return forced or model

I force the model. Buyers don't care which model runs, they care about the result. Forcing also means you can swap upstream providers without telling buyers.

What the Lite version doesn't do (and why I built the Pro version)

After shipping the Lite version, I realized I needed more to actually run a prompt-selling business:

Plaintext prompt storage is a problem. Anyone with shell access to the server can cat prompts.yaml. The Pro version uses AES-256-GCM encryption in SQLite.
Single API key list doesn't scale. If I have 30 buyers, I can't tell who's using what, I can't revoke one without rotating everyone, I can't set expiry. The Pro version has a clients table with per-client keys + expiry + active flag.
No usage analytics. I can't tell which prompts are popular, which clients are heavy users, which requests are failing. The Pro version has a usage_logs table.
One AI backend is limiting. Some prompts work better with Claude, some with DeepSeek, some with GPT-4. The Pro version has an adapter layer that routes per-prompt.
No admin UI. Editing YAML + restarting the server is fine for me, but if I want to delegate client management, I need a web panel.

These are all in the Pro version (self-host, $49 personal / $99 team / $249 agency).

The Pro version's encryption (since people always ask)

AES-256-GCM with a random nonce per encryption. The encryption key is a 64-character hex string loaded from env. Each prompt save generates a new nonce.

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import secrets

_NONCE_LENGTH = 12

def encrypt_prompt(plaintext: str, key: bytes) -> bytes:
    nonce = secrets.token_bytes(_NONCE_LENGTH)
    ciphertext = AESGCM(key).encrypt(nonce, plaintext.encode("utf-8"), None)
    return nonce + ciphertext

def decrypt_prompt(ciphertext: bytes, key: bytes) -> str:
    nonce = ciphertext[:_NONCE_LENGTH]
    encrypted = ciphertext[_NONCE_LENGTH:]
    return AESGCM(key).decrypt(nonce, encrypted, None).decode("utf-8")

Why AES-GCM and not AES-CBC? GCM gives you authentication for free — the auth tag validates that the ciphertext hasn't been tampered with. With CBC you'd need to add HMAC separately. GCM is also faster in hardware.

Why random nonce per encryption? If you reuse a nonce with the same key in GCM, you catastrophic-ally break confidentiality. secrets.token_bytes(12) gives you 96-bit nonces, which is the GCM standard.

Threat model: Encryption protects against (1) database leak, (2) backup leak, (3) someone with file system access cat-ing the SQLite file. It does NOT protect against someone with root on the running process — at that point the key is in memory and you're done. The point is raising the bar from "open the db file" to "compromise the running process".

Deploy

The Lite version is a single Dockerfile:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Build + run:

docker build -t prompt-proxy-lite .
docker run -p 8000:8000 --env-file .env -v $(pwd)/prompts.yaml:/app/prompts.yaml prompt-proxy-lite

For public internet exposure, put it behind Cloudflare Tunnel or Caddy. Don't expose FastAPI directly — it's not a TLS terminator.

What I learned

The OpenAI API spec is the de facto standard. If you implement /v1/chat/completions correctly, you get compatibility with ChatBox, Cursor, LibreChat, Open WebUI, every Python/JS SDK, for free. This is a huge leverage point — you don't need to write a client.
"Selling access" beats "selling the artifact". Recurring revenue, revocable, trackable. The artifact business (one-time prompt files) is a race to the bottom. The access business (API with usage limits) is a real product.
Streaming is non-negotiable. If your proxy doesn't stream, buyers will complain within 5 minutes. The implementation is one async generator away.
The 80/20 of prompt security is "don't ship the prompt text". Everything else (encryption, key rotation, usage tracking) is a refinement. If you ship plaintext prompts, no amount of encryption later will undo the leak.

Repo

Lite (open source, MIT): https://github.com/tlyyxjz/prompt-proxy-lite
Pro (self-host paid): https://github.com/tlyyxjz/prompt-proxy-pro

If you build something similar, I'd love to hear about it. The architecture is small enough that you can fork the Lite version and add your own twists — multi-model routing, prompt versioning, A/B testing, whatever.

If you found this useful, follow me on Twitter where I post about indie hacking + Python + AI tooling. And if you want to sell prompts but don't want to build the proxy yourself, the Pro version is $49 for personal use.

Footer note (Dev.to auto-injects author card)

Article by tlyyxjz — indie hacker, Python dev, building tools for the AI creator economy.

DEV Community: Xjz · Builder