I’ve always been fascinated by the gap between privacy as policy and privacy as implementation. At small scales, you can manually audit data flows. At Meta’s scale, with billions of data accesses per second across hundreds of heterogeneous systems, manual audits become archaeological digs into a system that changed yesterday.
PrivacyLib represents a maturation in how we think about infrastructure-level privacy. Rather than bolting privacy checks into each new system as requirements evolve, Meta inverted the problem: integrate once, add requirements as modules.
The Problem with System-by-System Integration
Before PrivacyLib, every new privacy requirement meant touching every system that handled data. Need to enforce purpose limitation? Update Logger, key-value stores, graph databases, ML pipelines, and filesystems separately. Each implementation diverges. Each one takes months to review, test, and roll out. Requirements drift out of sync as systems evolve independently.
This approach doesn’t scale past a handful of requirements or systems. It’s like adding a new type of security rule to a firewall but having to recompile every application that connects to it.
The Architecture: Separate Integration from Requirements
PrivacyLib’s insight is elegant: separate the integration problem from the requirement problem.
Instead of implementing each privacy rule in every system, Meta built a common library that runs inside the clients of data systems at the point of access. The integration happens once per system, mapping that system’s API to five common operations: read, write, RPC, and their post-operation variants. Once integrated, any new privacy module automatically works across all integrated systems without touching a single line of system code.
This is architectural leverage. A new module drops in and gains coverage across the entire fleet overnight.
When internal AI agents became a major data access path, Meta didn’t reintegrate every system. They added an Agent Observability module to PrivacyLib. Every system that was already integrated automatically started observing and safeguarding agent-related data access. That’s the payoff of integration-as-infrastructure.
Operating at Billion-Scale Checks Per Second
Running privacy checks on every data access creates brutal constraints. At Meta’s scale, a single millisecond of latency across billions of checks becomes untenable. PrivacyLib had to be ruthlessly efficient.
The team made three critical decisions:
First, evaluations run in-process, inside the client libraries. This avoids crossing process boundaries on every access, which earlier designs did and found to be thousands of times slower. The destination identity and request context are already there; no need to ship them anywhere.
Second, aggressive caching eliminates repeated checks. Per-request caches catch duplicate checks within a single operation. Per-host caches retain configuration and results across requests. The difference is measurable: a remote config fetch for every check would be catastrophically slow.
Third, telemetry stays lightweight through sampling and deduplication. PrivacyLib records each module’s status and samples latency without logging every invocation. Bloom filters downsample high-volume patterns, while fine-grained sampling adjusts as traffic changes. Recording every check in full would overwhelm the observability pipeline itself.
The result: billions of checks per second, consuming only a small fraction of Meta’s total compute.
Coverage for Paths Outside the Integration Boundary
Not every access goes through integrated client libraries. Some services issue raw RPCs directly. PrivacyLib handles this with a cryptographic token bridge: when a client-side check succeeds, PrivacyLib signs a token and attaches it to the request. The RPC layer validates the signature and trusts the earlier decision.
Requests arriving without a token get a coarser check based only on what’s visible in the network payload. This intentionally applies stricter rules, choosing false positives over gaps. Between them, two layers of evaluation cover both optimized client paths and raw RPC traffic. This is pragmatic security architecture: perfect where you can afford it, conservative where you must.
Changing Enforcement Without Breaking Live Traffic
The hardest part isn’t scaling the checks. It’s changing them safely. Modifying a privacy requirement could silence writes from dozens of services simultaneously. Mistakes compound across the entire fleet.
Meta built evidence-driven reviews. When an annotation changes in a LoggerConfig, the code-generation pipeline updates the PrivacyLib artifact. Simulations then replay observed data flows against both old and new artifacts, reporting every flow whose result changed. Reviewers see the source change, the generated code, and the simulation evidence together. If something unexpected appears, they can hold the artifact.
Once approved, the artifact deploys through each service’s normal pipeline. By the time it reaches production, two forms of visibility have already confirmed the change, and one form of control has validated it.
This isn’t just caution. It’s acknowledging that infrastructure changes at scale require more scrutiny than the code change itself suggests. The implications ripple through systems you didn’t touch.
PrivacyLib shows that privacy at scale isn’t a single technical problem. It’s an integration problem, a performance problem, an observability problem, a deployment problem, all layered together into something that just works. The question isn’t whether you can build privacy infrastructure at scale. It’s whether you’re willing to redesign how your systems integrate to make it inevitable.