
Redacting PII at the Wire: Before the Prompt Ever Leaves Your Boundary
The safest place to remove personal data from an AI prompt is before it crosses your boundary. Redaction at the wire masks PII inbound and outbound as a runtime step, so the model gets the context it needs without the identifiers it doesn't.
- Anton MaciusField CTO
In this article
Most PII controls for AI happen too late — after data has already reached a model, or in a policy document that describes what should happen. Redaction at the wire does it at the only moment that fully protects you: as the prompt leaves your boundary, the personal identifiers are masked, so the model receives the meaning without the person.
What "at the wire" means
The wire is the boundary between your environment and the model. Redaction at the wire is a runtime step that inspects a prompt on its way out and a completion on its way back, and masks personal data in transit. It's not a setting on the model and it's not a manual review — it's an automatic transformation applied to every call, in both directions.
The reason to do it there, rather than trusting the model to 'be careful,' is simple: once data has left your boundary, no policy can call it back. The only redaction you can fully rely on is the one that happens before the data crosses.
Why not just trust the model?
A model can be instructed to avoid repeating personal data, and it will usually comply — but 'usually' is not a control, and instructions are exactly what prompt injection defeats. More fundamentally, if the identifier is in the prompt, it has already left your boundary to reach the model. Asking the model to be discreet about data it shouldn't have received is solving the problem one step too late.
You can't un-send a prompt. Redaction has to happen before the boundary, which means it has to be a deterministic runtime step, not a request to the model.
What gets redacted, and how it stays useful
The categories are the familiar ones — names, national IDs, account and card numbers, contact details, health identifiers — matched by their recognizable formats. The trick is doing it without destroying the prompt's meaning. A well-designed redaction replaces an identifier with a stable placeholder, so the model can still reason about 'the customer' and keep references consistent across the conversation without ever seeing who the customer is.
- Consistent placeholders keep the model coherent — the same person maps to the same token throughout.
- Reversible on the way back, within your boundary, so the answer can be re-populated for an authorized user without the model having seen the raw value.
- Both directions, so a completion that happens to contain an identifier is caught before it reaches someone who shouldn't see it.
Redaction and the record
Every redaction is itself an event worth recording. When the prompt stored on the audit ledger is the redacted one, you get two things at once: a complete record of the interaction, and a record that is itself safe to retain because the sensitive values were masked before it was written. Recording everything and protecting privacy stop being in tension.
How it fits data-protection obligations
Data-minimization principles — sending a system only the data it needs — are easy to state and hard to enforce by hand. Redaction at the wire enforces minimization mechanically: the model receives the context required to answer and nothing more. That's a control you can point to when a high-risk obligation asks how you govern the data your AI processes.
Frequently asked questions
Mask it before it leaves. See how the security runtime redacts personal data at the wire, in both directions, and records the redacted interaction on the audit ledger. Reach a Sphere engineer at sphereinc.com/contact.
Part of