--- title: "The forbidden index: Building privacy-preserving search with OpenSearch" url: https://daily.dev/posts/the-forbidden-index-building-privacy-preserving-search-with-opensearch-n6pgsrnwu source_url: https://opensearch.org/blog/the-forbidden-index-building-privacy-preserving-search-with-opensearch type: article source: "OpenSearch" published: 2026-08-23T12:21:02.636Z updated: 2026-08-23T12:42:49.640Z tags: ["data-privacy", "opensearch"] reading_time: 4 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The forbidden index: Building privacy-preserving search with OpenSearch **[OpenSearch](https://daily.dev/sources/opensearch)** · 4 min read · 0 upvotes · 0 comments ## Summary 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. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions 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._ --- Tags: [#data-privacy](https://daily.dev/tags/data-privacy), [#opensearch](https://daily.dev/tags/opensearch) [View this post on daily.dev](https://daily.dev/posts/the-forbidden-index-building-privacy-preserving-search-with-opensearch-n6pgsrnwu)