---
title: Private Filter Service
framework: Private Cloud Compute Security Guide
role: article
role_heading: Article
path: private-cloud-compute/privatefilterservice
---

# Private Filter Service

PCC answers keyed Bloom filter membership queries from other components without the queries leaving the trust boundary.

## Overview

Overview The Private Filter Service (PFS) hosts keyed Bloom filters and answers membership queries from other PCC components. PCC’s Recitation prevention system uses PFS to look up output fingerprints against filters of protected-content fingerprints. Lookup queries do not leave the PCC High-security inference. The PCC Agent issues queries to PFS nodes following the Transitive Trust process. Trust boundary and routing PCC replicates each filter across nodes to satisfy its Non-Targetability requirements. Before sending a request’s lookups, the agent-side router confirms that a quorum of valid replicas is available and then routes the lookups to a replica selected per request, so no party outside the consumer node chooses which replica serves a request. A filter small enough to fit on every consumer node is instead served in-process, on the node the request already reached. Lookups carry only the filter identifier and the fingerprints to look up; responses are per-fingerprint hit-or-miss results. Service architecture PFS is composed of three CloudBoard daemons: A controller that hosts filter shards on PFS nodes and answers lookup queries. The controller holds a shard in memory when its size falls below the node’s configured threshold, and serves a larger one from local storage. A client router that runs alongside each consumer (PCC Agent), discovers PFS instances, and routes lookups to the appropriate shard, or serves them in-process for a filter small enough to sit on every node. A downloader that fetches large filters’ fragment data at first node startup and validates it against the descriptor’s hashes before the controller serves it. Filter format Each filter is keyed: a lookup computes HMAC(key, fingerprint) and derives from that MAC the positions to probe in the filter’s data. PCC shards large filters into fragment files partitioned deterministically by fingerprint; small filters fit in a single file. Each filter carries a descriptor containing the HMAC key, an identifier for the fingerprinting scheme that produced the filter’s entries (so a consumer’s lookups match only a filter built with the same scheme), and a SHA-256 hash of each fragment file for integrity verification. Asset delivery Filter descriptors and small filters ship inline in a Foundation model and adapter cryptexes delivered through PCC’s standard asset delivery infrastructure. This approach puts them under the node’s attestation alongside the model assets they apply to. Large filters have fragment data too substantial to fit in a cryptex; only their descriptor ships there, and the downloader fetches fragment files from a CDN at first node startup, validating each fragment against the SHA-256 hash in the descriptor before serving it. Because the descriptor is attested, fragment integrity is anchored in the node’s attestation chain even though the fragment bytes themselves are not.