Sphere wins 2026 Global Recognition Award
Sphere Partners
Redacting PII at the Wire

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.

3 min read
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.

In plain terms

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

Done well, no. Replacing identifiers with consistent placeholders preserves the structure the model needs to reason — it still tracks 'the customer' and 'the account' across a conversation — while removing the specific values it doesn't need. The answer can be re-populated with the real values inside your boundary for an authorized user.
It's related but narrower and more operational. Redaction at the wire is a per-call, in-transit control that masks identifiers before a prompt leaves your boundary. It complements broader data-governance and anonymization practices rather than replacing them.
Redaction runs in both directions. A completion that contains a personal identifier — whether it was retrieved, inferred, or echoed — is inspected on the way back, so it can be caught before reaching a user who shouldn't see it.
Inside your own boundary, as part of the security runtime, before the prompt crosses to the model. That placement is the whole point: it's the only position from which redaction fully protects the data.

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.

We'd love to hear from you!

Please provide your contact details, and our team will get back to you promptly.