Privacy and data handling

What happens to your text when it passes through Jnvoy, what we keep, who else sees it, and where redaction can fall short.

Last updated 5 November 2026

The short version

Jnvoy replaces sensitive values in your prompts with placeholder tokens before the prompt reaches a language model, then puts the real values back into the reply.

Question
Answer
Status
Is original text saved?
Not in the database, the audit log, the cache or the logs. It exists in memory while a request is processed.
Not stored
Who can read the original text on its way to Jnvoy?
On the hosted service, Cloudflare, which Render uses at the edge of its network, can read traffic in transit. Self-hosting removes this.
Cloudflare
What reaches the model provider?
The redacted text only, sent to the provider you choose.
Redacted
Does anyone else see redacted text?
Only the model provider you choose. The optional second check, a separate model that re-reads redacted text, is off on the hosted service.
Provider only
Is detection guaranteed to be complete?
No. It is strong, and it is measured, but a value can be missed.
Not guaranteed

How a request flows

Your application sends its prompt to Jnvoy. Jnvoy finds sensitive values and swaps each one for a token such as [PERSON_1]. Only the tokenised prompt moves on. When the reply comes back, Jnvoy swaps the tokens for the original values before the reply reaches you.

Your application

Sends the prompt to Jnvoy over HTTPS.

Email Priya Raman at priya@acme.co

Jnvoy

Finds sensitive values and replaces them. Holds the originals in memory for this request only.

Email [PERSON_1] at [EMAIL_ADDRESS_1]

Second check (optional)

Off on the hosted service. A self-hosted deployment can switch it on and run it on its own model.

Email [PERSON_1] at [EMAIL_ADDRESS_1]

Model provider

Receives the redacted prompt and writes a reply that uses the tokens.

Email [PERSON_1] at [EMAIL_ADDRESS_1]
The original text reaches Jnvoy, because Jnvoy has to read it to redact it. On the hosted service it passes through Cloudflare on the way in. It does not travel past Jnvoy.

What is stored

Jnvoy keeps a record of each request so you can audit it. The record describes the request. It does not contain it.

Where
What it holds
Original text
Audit log (database)
Request ID, time, provider, model, response time, whether the cache answered, a short hash of the API key, and counts of what was found by type, for example one person and one phone number. If reply scanning is on, it also holds counts of what was found in the model's reply, by type.
Never
Response cache (memory)
The model's reply with tokens still in place, filed under a hash and separated by API key. Cleared whenever the service restarts.
Never
Request memory
The original values, so they can be restored into the reply. Discarded when the request ends.
Briefly
Files you send
A PDF, Word or text file is read in memory by a separate, restricted process that has no access to keys or the database and cannot write files. Only its text is used. The file and its text are discarded when the request ends.
Briefly
Tool calls
Tool results and the arguments of earlier tool calls are redacted like any other text before the model sees them, and the model's tool calls come back with your values restored. Tool definitions (names, descriptions and parameter schemas) are sent as you wrote them, so keep personal data out of them. Nothing from a tool conversation is cached or stored.
Briefly
Customer account (database)
Company name, contact email, plan, your settings, the number of calls made each month, and a SHA-256 hash of your API key. The key itself is shown once when it is created and is never stored. If you get a key on the get a key page, the email you type is stored here. It is not checked, so someone could type an address that is not theirs; if that happens to you, email us and we will delete the account. It is not added to any mailing list.
Never
Sign-up limit (memory)
To stop one person creating many keys, the network address of each key request is held in memory for up to 24 hours, then forgotten. It is never written to disk or the database.
Never

Each customer can read only their own audit records and usage, using their own key. Operator keys can read the whole deployment, and the operator's compliance report routes need an operator key. Records are kept for the life of the deployment. If you need a different retention period, ask.

Jnvoy can also scan the model's reply for things that should not come back, such as keys, card numbers and prompt injection text. That check runs on the reply as it arrives, before real values are put back. It records counts only.

Who else sees redacted text

Jnvoy sends redacted text to other services to do its job. None of them receive the original values from Jnvoy.

  • The model provider you choose (for example Anthropic or OpenAI) receives the redacted prompt. Its own terms govern what it does with that text.
  • No separate second-check service. The optional second check is off on the hosted service, so redacted text goes only to the model provider you choose. A self-hosted deployment can run the check on a model on its own machine.
  • Cloudflare sits in front of the hosted service as part of Render's network. It does not receive redacted text from Jnvoy. It reads the original text in transit, before it reaches Jnvoy, because it ends the encrypted connection to pass each request on.
  • Render hosts the Jnvoy service and its database. Request text is processed in the service's memory, and Jnvoy does not write original text to either. The security page lists every service we use.

What redaction does not promise

Detection combines pattern rules, a trained model for names and places, and the optional second check. Together they catch most of what we test for, and they can still miss a value or hide a harmless word.

  • Misses happen. Unusual formats, names with no surrounding context, and addresses written in free text are the likeliest to slip through.
  • Over-redaction happens too. A ten digit number can be read as an NHS number, and a brand name can be read as a person.
  • About one value in six is missed. On sentence wordings the rules were never tuned on, Jnvoy hid 835 of 1,009 sensitive values (82.8%). The weakest types were addresses (45 of 90 hidden), postcodes (37 of 90) and passwords (26 of 43). Names were hidden 78% of the time. See the larger test.
  • Our test text is generated. The documents are short (about 100 characters on average and never more than 300) and were built from sentence patterns we wrote, filled with made-up values. Real text, such as long emails or pasted documents, may score lower. The sets are in the repository and you can run them yourself. Treat them as evidence, not proof.

For that reason Jnvoy's compliance report says no PII detected by Jnvoy was transmitted. It does not say none existed.

Sending text safely

  • Send text in the request body. Use POST /v1/scan. The old GET versions put your text in the web address, and web servers commonly record addresses in their logs. They have been removed and now answer with an error.
  • Your model provider key travels with each request. Send it in the x-provider-key header. It is used to make that one call, and is never stored, logged, cached or written to the audit log.
  • Keep your API key out of source code. Keys are checked in constant time, are never written to logs or responses, and can be rate limited.
  • The second check is off on the hosted service. Redacted text is not sent to a second vendor. If you self-host and switch it on, run it on a model you control if your data cannot go elsewhere.
This page describes how the software behaves today. It is not a contract or legal advice. If your organisation needs a data processing agreement, ask before you send real data.

Questions

Write to j.nagaraj2109@gmail.com with anything about data handling. The source is published, so you can also check any statement on this page against the code on GitHub.

Jnvoy is operated by JNVOY LIMITED, a private company limited by shares, registered in England and Wales under company number 17536574.