Every time you send a prompt to a cloud AI, you are exporting data. Not metaphorically — literally. The patient note, the contract clause, the customer's card number, the home address buried in paragraph three: all of it leaves your machine, crosses the internet, and lands on someone else's servers to be logged, cached, and sometimes used for training. For most prompts that is fine. For the ones that carry a real person's identity or a patient's health, it is a breach waiting to be named.
PulseLABS treats that boundary as sacred. Between you and any external model sits an engine — Synapse for routing and generation, Cortex for knowledge — and inside that engine lives the PII/PHI Shield. Nothing sensitive reaches a cloud provider without passing through it first. This is what it does, and why the engine is the whole point.
Why there has to be a layer
If your app calls OpenAI directly, there is no seam to inspect. The prompt is assembled and shipped in the same breath; whatever was in it is gone. There is no moment where someone — or something — can look at the outgoing bytes and decide this part should never leave.
Synapse and Cortex exist to create that moment. They are not a thin proxy that forwards your text unchanged. They are a checkpoint. Every generation request flows through Synapse; every document you index and every fact Cortex extracts flows through the same guarded path. Because there is a single place all traffic passes, there is a single place to enforce a single rule: sensitive values are redacted before they cross the machine's edge, and restored the instant the answer comes back. You cannot bolt that guarantee onto a direct API call. You can only build it into a layer — which is exactly why the layer is there.
How the Shield works
The mechanism is deliberately simple, because simple things are auditable.
- Scan. Before a request leaves for an external provider, the Shield scans every text field — the system prompt and every message — for sensitive patterns.
- Tokenise. Each match is replaced with a deterministic placeholder:
[EMAIL_1],[NAME_2],[CREDIT_CARD_1]. The original value is stored in a per-request vault that never leaves your server. - Send the redacted text. The provider sees
[EMAIL_1], not the address. It reasons over the structure of the problem without ever holding the identity. - Restore. When the answer returns, the Shield swaps every token back to its original value before you see it. The redaction is invisible to you and invisible to the end result — only the provider ever saw the blanks.
The same vault is shared across every field of a request, so the same value always maps to the same token. If a name appears in the system prompt and again in a message, the model sees one consistent [NAME_1] in both places and can still reason that they are the same person — it just never learns who. On restore, tokens are swapped longest-first, so [EMAIL_12] is never clipped by [EMAIL_1].
It refuses to cry wolf
A redaction tool that flags everything is a tool people turn off. The Shield is built to be precise. Credit-card candidates are run through the Luhn checksum before they're touched, so a random sixteen-digit order number stays put. UK NHS numbers are validated with their mod-11 check digit; phone numbers are length-bounded; French social-security numbers and IBANs match their real structure. The goal is to redact what is genuinely identifying and leave ordinary text — including public figures in a debate, or numbers that only look sensitive — completely intact.
Two modes: standard, and medical
The Shield runs at one of two levels, chosen by policy.
Standard catches classic PII with a rigid shape: emails, phone and fax numbers, credit cards, IBANs, national ID numbers, IP and MAC addresses. It never touches free text like names or dates, so it can run over every prompt in the product — debates, chat, market analysis — without mangling ordinary writing.
Medical is HIPAA Safe Harbor de-identification. On top of everything in standard, it strips the eighteen categories of identifier that make health data re-identifiable: patient names (anchored to titles like Dr or Patient), dates, ages over 89, geographic detail down to the ZIP, medical-record and beneficiary numbers, and national health IDs across the US, UK and France. Crucially, it preserves the clinical narrative — the diagnoses, the medications, the reasoning. Safe Harbor removes who the patient is, not what is wrong with them, so the model can still give you a useful second opinion on an anonymous case. (If even the clinical terms must go, one flag strips those too.)
Safe Harbor removes who the patient is, not what is wrong with them. The model reasons over a real case and never learns whose it is.
The local escape hatch
Here is the principle that ties it together: the Shield only redacts when bytes actually leave the machine. If your workspace is pointed at a local model — Ollama on your own hardware — nothing crosses the internet, so nothing is redacted. The model receives the full, unaltered text and reasons at full fidelity. The guard is inert by design when there is no external provider to protect against.
That is the quiet argument for running AI inside your own walls. On a cloud provider, de-identification is a necessary tax you pay to stay safe. On a local model, that tax disappears — the data never left, so there was never anything to hide. The Shield makes cloud AI safe; local AI makes it unnecessary. PulseLABS lets you choose per workspace, and switch without a redeploy.
Cortex remembers safely too
Redaction isn't only about live chat. When Cortex indexes your documents, the text is embedded — turned into vectors for retrieval — and those embeddings, on a cloud provider, are computed remotely too. So the Shield runs there as well, in a variant that emits order-independent tokens: an email always becomes the same [EMAIL] whether it appears in a stored document or in your search query, so redacted text still lines up and retrieval still works. Every enricher that reads your raw content — the contextualiser, the fact extractor, the Q&A generator — is wrapped the same way: sensitive input redacted on the way out, restored in the results. Your knowledge base stays searchable without your secrets being the price of admission.
Who this is for
Anyone whose work involves someone else's confidential data and who still wants the leverage of a good model.
- Clinicians and health teams who want a second read on a case without shipping protected health information to a third party.
- Lawyers and finance handling contracts, account numbers, and personal details under a duty of confidentiality.
- Founders and operators running customer data, support transcripts, and internal documents through AI every day.
- Anyone in a regulated corner of Europe where "we sent it to an American API" is not an acceptable answer to a data-protection question.
Why you should care
The convenience of cloud AI has a hidden clause: you are trusting a third party with everything you type. Most of the time that trust is well placed. But identity and health data are not most-of-the-time data — they are the categories the law names specifically, the ones a leak can't be undone for. A redacted prompt can't be misused, subpoenaed, or trained on, because the sensitive part was never in it. And a prompt that never left your building can't leak at all.
That's the choice PulseLABS is built to give you: a hard, auditable seam between your data and the cloud, and the option to remove the cloud from the equation entirely. The engine is that seam. The Shield is what stands on it.
