Signed request receipts

A signed request receipt is a small token Redline returns on every chat completion. It carries a hash of your prompt, the model and a timestamp, signed with the gateway key, so you can prove what was sent without the gateway storing the text.

What is in the receipt

The token looks like rlr1.<payload>.<sig>. The payload is a JSON body of version, model, prompt SHA-256 and timestamp; the signature is an HMAC-SHA256 over the payload with the gateway’s key. It comes back in the X-Redline-Receipt response header.

What it proves

Given the receipt and your original messages, you can recompute the hash and confirm they match: proof this receipt was issued for exactly those messages. A bad signature proves the receipt did not come from the gateway. Because only the hash is in the receipt, the plaintext is not, and if it is not in the receipt it is not in the database either.

Why it matters for security work

A red team whose prompts are the engagement, or a T&S team handling material under legal authority, needs to show a client or counsel what left the building. The receipt is that evidence, and it says the prompt was hashed, not stored. Check one on the privacy page.

What it is not The receipt proves what Redline bound to and did not keep. It does not prove the upstream model host did not process the tokens; inference has to read them. It is a statement about Redline’s storage, verifiable from outside.

Related

Zero prompt retentionRedline stores the model, token counts and cost, never the prompt or completion, and returns a signed receipt so you can verify it. LLM gatewayAn LLM gateway is one API in front of many model providers, adding keys, billing, spend limits and logging without changing your code. Red-teaming LLMsRed-teaming an LLM means attacking your own model on purpose: jailbreaks, prompt injection and abuse generation, to find failures before an attacker does.

All concepts · Integration guides · Browse models