Sensitive Data Is Easier to Control Before It Spreads

A customer signs up for a product. During onboarding, they paste more than expected into a form. Not just a company name or a support note. They paste a passport number, a bank account number, a medical insurance number, a production API key, or another value that was never supposed to enter this system.

A similar thing happens in search bars. A user searches a website for an order, a document, a patient, an account, or a support case. Instead of entering a safe identifier, they paste an email thread, a legal notice, a bank account number, or a national ID. The search returns nothing useful, but the query may still be captured by the systems around it: web server logs, application logs, product analytics, session replay tools, A/B testing platforms, search indexes, monitoring pipelines, and third-party web analytics.

From the user’s perspective, nothing unusual happened. The original event looked small. But sensitive-data leaks are propagation events.

And this is still the simple case. A single leak at least gives the team a starting point: one request, one user action, one approximate timestamp, one payload to trace. Real systems often have many leaks over time. Different users paste different sensitive values into different fields and endpoints. Some values are noticed quickly, some remain hidden for weeks. Others appear only in sampled traces, archived logs, failed jobs, old exports, or downstream tools owned by another team or another company. Across distributed systems, proving removal requires knowing where the data went.

At that point, cleanup is no longer about reconstructing one path through the system. It is about understanding a pattern of propagation across many paths, many systems, and many retention timelines.

The problem is not one copy

Many security conversations treat a sensitive-data leak as an exposure event: who saw it, where it was visible, which control failed. That view is incomplete. In production systems, data rarely stays where it first lands. Modern infrastructure is designed to move, replicate, index, cache, back up, and preserve data. That is also why sensitive data can spread quickly once it enters the wrong path.

The hard part is not deleting one copy. It is finding every copy. A single request can cross multiple components of a distributed system, each with its own retention model, indexing behavior, replication strategy, access controls, backup process, and deletion semantics. That is sensitive-data sprawl: uncontrolled propagation of sensitive data into systems that were not meant to process, retain, or govern it.

Deletion is rarely a single operation

Deletion can be layered, delayed, logical before physical, and system-specific. Deleting a database row may not remove the value from application logs. Removing a log entry may not remove it from a log archive. Removing data from the primary database may not immediately affect replicas, derived indexes, materialized views, snapshots, backups, or warehouse loads.

Even inside one storage system, deletion has stages. MVCC systems may keep old row versions until no transaction needs them. LSM-based systems may write tombstones and remove obsolete data later during compaction. B-tree systems may reuse pages over time rather than immediately overwrite prior contents. Write-ahead logs, binlogs, replicas, backups, and object storage lifecycle rules may all follow separate timelines. Large deletion jobs can require significant compute and I/O, and may affect system stability if they are not planned carefully.

This does not mean deletion is impossible. It means deletion is a lifecycle and cost problem.

Post-ingestion cleanup starts with uncertainty

Once sensitive data has propagated, cleanup becomes an investigation. Which services received the value? Which logs captured the payload? Which traces included it as an attribute? Which queues carried it? Did any failed consumer send it to a dead-letter topic? Was it cached? Was it indexed? Did it reach analytics? Was it included in a batch export? Did a third-party API store it?

Tools for discovery, classification, lineage, retention, and deletion help. They are necessary parts of a mature data protection program. But many of them operate after ingestion. They detect, map, alert, and help teams respond after sensitive data has already crossed the boundary. They do their job, but they are reactive.

Why Voidwall

The goal is not to stop using the systems described above. The goal is to avoid sending them sensitive data they should never receive. A billing service may legitimately need billing details. An identity system may need identity attributes. A healthcare workflow may need health information. But an analytics endpoint may not need raw identifiers. A logging pipeline should not become a store for access tokens. An external API should not receive fields that only make sense inside the company’s own environment.

Preventing one unexpected value from crossing a boundary is easier than proving later that it was removed from every system it reached.

That is the principle behind Voidwall. Voidwall is a preventative HTTP-edge layer for detecting, redacting, and warning about sensitive data before it propagates deeper into infrastructure. It is designed to sit in front of services and integrations, where request and response payloads cross important boundaries.

Sensitive-data leaks are propagation events. Sensitive-data sprawl is the long tail that follows. Voidwall was created to reduce that tail.