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

A developer built an OpenAI-compatible prompt encryption proxy in 300 lines of Python using FastAPI and httpx. The proxy allows prompt sellers to host their prompts on a server, providing buyers with an API URL and key that injects the system prompt without exposing the text. The open-source Lite version is available on GitHub, while a Pro version offers encrypted storage and multi-tenant support.

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 https://github.com/tlyyxjz/prompt-proxy-lite . The Pro version with encrypted storage + multi-tenant + admin panel is self-host paid https://github.com/tlyyxjz/prompt-proxy-pro — but everything in this article is in the open-source Lite version. 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 buyer is waiting for tokens. If you buffer the entire upstream response before returning, you've killed the UX. python 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. The buyer may have configured their own system prompt in ChatBox. You don't want to overwrite it — you want to prepend yours. python 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. python 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. Some buyers will configure gpt-4 in their client even though your upstream is DeepSeek. You can either reject the request or silently override: python 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. After shipping the Lite version, I realized I needed more to actually run a prompt-selling business: cat prompts.yaml . The Pro version uses AES-256-GCM encryption in SQLite. clients table with per-client keys + expiry + active flag. usage logs table.These are all in the Pro version https://github.com/tlyyxjz/prompt-proxy-pro self-host, $49 personal / $99 team / $249 agency . 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. python 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". 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. /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.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 https://twitter.com/ 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. Article by tlyyxjz — indie hacker, Python dev, building tools for the AI creator economy.