At OpenSearchCon Europe 2026, Unnati Mishra and Akshat Khanna (Angel One) presented an approach to privacy engineering that moves protection to ingest time rather than relying solely on access controls after indexing. They built a custom plugin that auto-redacts PII using tokenization and dynamic data masking before data reaches the index, applied differential privacy to OpenSearch Dashboards so aggregate analytics remain useful while individual records stay protected, and open-sourced a "privacy score" audit tool to help teams assess and remediate privacy gaps in existing OpenSearch deployments.
Table of contents
The problem with indexing first and asking questions laterDifferential privacy for dashboardsA “privacy score” audit toolWhy this session is worth your timeQuestions this post answers
How can I prevent PII from ending up in my OpenSearch index instead of trying to redact it later?
Redact personally identifiable information at ingest time, before it reaches the index, rather than relying on access controls after indexing. Angel One engineers built a custom OpenSearch plugin that applies tokenization and dynamic data masking during ingest, so sensitive values are never stored in a retrievable or correlatable form in the inverted index, stored fields, or cached query results. Teams designing privacy-safe search pipelines can follow evolving OpenSearch practices on daily.dev.
How does differential privacy work when applied to search dashboards?
Differential privacy adds carefully calibrated statistical noise to query results so individual records cannot be inferred from aggregate outputs, even across many repeated queries. Applied to OpenSearch Dashboards, this lets every displayed number remain differentially private while preserving overall aggregate signal for legitimate analytics, addressing a technique more common at large tech companies than in open-source search tools. Anyone weighing analytics utility against user privacy can track approaches like this on daily.dev.
Is there an open-source tool to audit privacy risks in an existing OpenSearch deployment?
Yes, a "privacy score" audit tool was open-sourced to assess the privacy posture of existing OpenSearch deployments and identify where sensitive data may have been indexed without adequate protection. It gives teams without dedicated privacy engineers a practical starting point for remediation and applies to compliance needs like GDPR, HIPAA, and CCPA. Developers auditing search stacks for compliance gaps can follow tooling like this on daily.dev.