BV-PRGA: inside the privacy gateway

Every prompt that leaves for an external model is a data export. Most of the time, it exports more than the task needs: the client's name when a client was enough, the full IBAN when the model only had to draft a reminder, an API key pasted by accident. BV-PRGA is the gate placed before that exit — as a browser extension for people, as a self-hosted gateway for teams — and it guarantees a property that is simple to state: the sensitive stays in your system; only what the task needs travels out.

The round trip, formalized

The heart of BV-PRGA is a reversible masking whose key never leaves. On the way out, the request $x$ is transformed into a pair

$$m(x) \;=\; (\tilde{x},\; \kappa)$$

where $\tilde{x}$ is the protected version that travels to the provider and $\kappa$ is the correspondence map — which token substitutes which value — that stays in your environment. Each detected value is replaced by a stable marker of the form [BV:PERSON:a1b2c3], [BV:IBAN:2e5d8c]: consistent within the request (the model can reason about "the same person") and opaque outside it. On the way back, the provider's response $\tilde{r}$ is reconstructed locally:

$$r \;=\; \kappa^{-1}(\tilde{r})$$

The key property is where each piece lives: the external provider only sees $\tilde{x}$ and produces $\tilde{r}$; the pair $(\kappa, r)$ never leaves your infrastructure at any point in the cycle. Reversibility is local by construction, not by promise.

Secrets: block, don't pseudonymize

Not everything sensitive admits the same treatment. A pseudonymized name or IBAN still lets the task be solved; an API key has no business in a prompt in any form — neither in the clear nor masked, because a reversible marker of a secret is still a secret with one step of indirection. That is why the policy distinguishes two verbs:

• Pseudonymize what the task needs to reference: people, identifiers, accounts, emails.
• Block what should never travel: credentials, keys, session tokens. The request stops with an explicit decision — DENY — and the gate's meter records it: what was pseudonymized, what was blocked, and why the request didn't leave.

Fail-closed: the gate fails shut

Detection is a sequence-labeling problem, and no detector is perfect. The honest design question is not "how often is it right?" but "what happens when it doubts?". In BV-PRGA the answer is structural: in doubt, the gate closes. If the analysis of a request cannot complete with confidence — the classifier doesn't converge, the gateway doesn't respond, the format exceeds what is expected — the default is not to send. Formally, the policy is a lattice where DENY dominates: no component failure can silently degrade toward "send in the clear".

That bias has a price (sometimes it over-blocks) and it is a price we choose gladly: the cost of a false positive is a retry; the cost of a false negative is a data export that can no longer be undone.

What this gate is not

Honesty is part of the specification. BV-PRGA reduces exposure and compliance surface — less personal data traveling to third parties, fewer copies outside your perimeter — but it is not a substitute for your data-protection legal framework: legal bases, processor agreements and impact assessments remain yours. The gate gives you a verifiable technical fact to rest that framework on: the sensitive did not leave.

Where this is today

BV-PRGA is productized as an independent product at privacy.bivelio.com, in two forms: a free browser extension (Chrome, Edge and Brave) protecting people in ChatGPT and Claude before text leaves the device, and a self-hosted gateway for developers and teams, published on PyPI, applying the same policy in front of any AI API — OpenAI, Anthropic, DeepSeek and many others. Inside BiVelio it is the Protect layer: the same gate, in front of every interaction with a model.