Skip to content

SYSTEM Cited by 1 source

PrivacyLib (Meta)

Definition

PrivacyLib is Meta's common privacy-enforcement library that runs in-process inside the clients of hundreds of Meta data and processing systems, at the point of data access. It is the "continuously enforce and monitor data flows" stage of Privacy Aware Infrastructure (PAI). Its core idea is to separate system integration from requirement implementation: each system integrates once, and each privacy requirement is shipped as a pluggable module reused across every integrated system. (Source: sources/2026-10-27-meta-privacylib-privacy-controls-at-the-data-access-boundary)

Scale

  • 100 client libraries (key/value stores → AI features), thousands of production services, millions of assets accessed daily.

  • Billions of checks per second, at "a small fraction of Meta's total compute capacity."

Architecture

Modules

  • Enforcing modules can block an access — canonical instance: Policy Zones enforcing purpose limitation.
  • Observing modules only record — Privacy Probes (runtime signals for data-flow discovery), Telemetry Logging, Agent Observability.
  • Results from enforcing modules are combined into one response; observers never affect it. Post-operation variants of read/write/RPC let observers run after the decision.

Common operation model

Every integration maps native access points onto five operations, and modules are written only against these:

  1. Read — fetching data.
  2. Write — storing data.
  3. RPC — calling another service.
  4. Request entry — once, when a service begins handling a request.
  5. Inline execution — wraps a computation (e.g. feature evaluation) with its own inline privacy context.

Once a system has the mapping, enabling another module takes days, versus the months a bespoke integration used to take.

Annotation artifacts

Annotations live with the data destination, not with each writer (so writers can't disagree or forget). Each system describes data in its own schema (e.g. Logger's LoggerConfig); a codegen step translates it into a PrivacyLib-compatible artifact (asset ID + purpose-policy vars). Hack artifacts are generated directly; for C++/Python, the system publishes to a central catalog from which PrivacyLib generates language-specific artifacts. An instance of concepts/policy-as-data.

Why the client, not the datastore

  • Richer context — caller identity, endpoint and purpose are still available; "frequently lost if the check is evaluated on the datastore."
  • Failure isolation — a bad change is contained to the service running that build; the shared datastore stays outside the failure boundary (concepts/blast-radius).

Keeping checks cheap

  • Requirements compiled at build time into their simplest evaluable form.
  • Per-request caches (dedupe within a request) + per-host caches (configuration and results). The earlier remote-config-fetch design was "thousands of times slower than the in-process path."
  • Telemetry: module status, sampled latency, errors. Per-host Bloom filters downsample high-volume repeated patterns at a fixed rate; fine-grained sampling rates adapt to traffic — dedupe common events, keep rare ones visible.

Coverage: client check + signed token + RPC backstop

Integration happens at two levels: typed client libraries (full context) and lower network boundaries for remaining RPC paths. A successful client check attaches a cryptographically signed token; ServiceRouter validates it for supported RPC traffic. Tokenless requests get a coarser payload-only check that applies the strictest interpretation — false positives over gaps (fail-closed, layered per concepts/defense-in-depth). Paths outside Meta-managed clients and supported RPC paths need their own integration.

Rollout safety

Two change paths, each with its own safeguard:

Change Scope Pre-release safeguard Post-release control
Annotation edit (e.g. 2 lines in a LoggerConfig) one destination, possibly many writers Regenerated artifact + old artifact replayed against observed data flows during code review; changed decisions reported and reviewed with the diff Ships via each service's own deploy pipeline — impact bounded to services on that build
New module on a path every destination on the path Deploy before enabling rollingOut() runtime percentage (rollout key e.g. logger.input.write.zones) moved 0→100% watching denials / errors / latency; lowered without rebuild/redeploy; then enabled()

Per-service deployment trades propagation speed for blast-radius containment; requirement owners use explicit tracking against deadlines and emergency deploys when needed. See patterns/staged-rollout, patterns/progressive-configuration-rollout, concepts/feature-flag.

Worked example: Logger + messaging metadata

Messenger backend services write messaging metadata through Logger. Logger's Hack integration declares PrivacyLibOperation::write() with zones(ZoneDataType::LOGGER) ->withPropagation()->enabled() and telemetryLogging()->enabled() once for all destinations; C++ Logger builds a PrivacyLibBuilder and calls dispatch(). Policy Zones denies the write unless the current context is an allowed use of messaging metadata and the destination carries MESSAGING_TRAFFIC_METADATA.

AgentLib and Agent Observability

Internal AI agents' data paths are determined at runtime, and one tool call may traverse several nested services. AgentLib — a common runtime built on PrivacyLib's design principles — associates each tool call with its agent session; on supported paths downstream clients propagate that context to the PrivacyLib boundary.

  • Agent Observability module records agent session + tool-call IDs, destination, client API, integration point and errors; queryable by session. Rolled out to all integrated systems with no new integration.
  • Enforcement reuses Policy Zones unmodified: destination annotations + agent context decide; a block propagates back through the call chain to the agent. It applies "even when the agent chooses a tool that its developer did not anticipate" — "the access decision does not depend on the agent behaving as intended."

Lessons (from the 2026-10-27 post)

  • Integrate at a stable data-access boundary, define a small shared operation set, keep annotations with the data.
  • Reliability earns adoption — an early invalid config crashed processes fleet-wide; annotation changes that compiled cleanly still changed access decisions and broke products. Hence simulation + per-service rollout.
  • Coverage includes deployment — older services must redeploy to get new capabilities; inventory and tracking are part of coverage.

Seen in

Last updated · 854 distilled / 2,448 read