TLDR: At OpenSearchCon Europe 2026, Unnati Mishra and Akshat Khanna (Angel One) argued that privacy in search must be handled during the ingest phase rather than retroactively through access controls. To solve the issue of sensitive data leaking into indices, they built a custom plugin that auto-redacts PII at index time using tokenization and dynamic data masking. They also introduced an open-source “privacy score” audit tool alongside dashboards utilizing differential privacy, proving that organizations can successfully protect individual user identities without sacrificing aggregate analytical utility. |
Based on the OpenSearchCon Europe 2026 talk by Unnati Mishra, Independent & Akshat Khanna, Angel One | Watch the full session →
Most compliance conversations around search start and end with access control: who is allowed to query what. That is necessary, but it misses a harder problem. The data that should never be searchable has often already been indexed. The PII that should have been stripped was ingested intact. The “anonymized” dataset that feeds your analytics dashboards is more identifiable than anyone wants to admit.
At OpenSearchCon Europe 2026, Unnati Mishra and Akshat Khanna from Angel One, confronted this head-on with a talk that started with a provocation: “Warning: this talk may ruin your faith in anonymized data… but we’ll fix it.” What followed was one of the more practically grounded sessions on privacy engineering in the OpenSearch space—a walk through how they turned OpenSearch into what they called a privacy-aware analytics engine, with open-source tooling to back it up.
The problem with indexing first and asking questions later
The standard approach to building a search and analytics stack looks something like this: ingest the data, index it, then figure out access controls and compliance after the fact. That ordering creates a structural problem. If sensitive data has been indexed, it is in the inverted index, the stored fields, and potentially in cached query results. Redacting it retroactively is painful at best and incomplete at worst.
Mishra and Khanna’s approach flips this. Rather than treating privacy as a layer on top of the search stack, they built it into the ingest layer, before data reaches the index. Their custom plugin auto-redacts PII at index time using tokenization and dynamic data masking, so that sensitive values are never stored in a form that can be retrieved or correlated.
Differential privacy for dashboards
The more technically ambitious part of the talk was the application of differential privacy to OpenSearch Dashboards. Differential privacy is a mathematical framework that adds carefully calibrated noise to query results, making it statistically difficult to infer individual records from aggregate outputs even when an attacker can issue many queries. It is a technique used by major technology companies for internal analytics, but it is not commonly applied to open-source search infrastructure.
Mishra and Khanna showed what this looks like in practice: dashboards where every number is differentially private, where the aggregate signal is preserved for legitimate analytical purposes but the individual signal is protected. The demo challenged what most attendees had assumed was a hard tradeoff between analytical utility and privacy protection.
A “privacy score” audit tool
The session also included the announcement of an open-source “privacy score” audit tool—a way to assess the privacy posture of an existing OpenSearch deployment and identify where sensitive data may have been indexed without adequate protection. For organizations that have built up a search stack over time without privacy engineering baked in from the start, this kind of audit tool is a practical entry point for remediation.
The decision to open-source this tooling reflects a broader argument the speakers made throughout: privacy engineering in search infrastructure should not be the exclusive domain of organizations with dedicated data privacy teams. The tools should be accessible to any team that cares about GDPR, HIPAA, CCPA, or simply about being honest with their users.
Why this session is worth your time
The title is deliberately provocative, and the session delivers on that provocation. If you work with search infrastructure that handles any user data, which is to say, most production search systems, the framing here is useful even if you never implement differential privacy. The core argument is simple: treating privacy as a retroactive concern rather than an ingest-time constraint means you are always one data audit away from an uncomfortable discovery.
Mishra and Khanna built a concrete, working alternative and shared the code. That is a more useful contribution than a compliance checklist.
