Context sources

Enrich authorization requests without changing application code

Proxy extensions intercept authorization requests to enrich them with data from identity providers, databases, and internal services — transparently, before policy evaluation.

Transparent enrichment

Applications send minimal authorization requests — proxy extensions fetch the rest from identity providers, databases, and internal services

Response transformation

Redact sensitive fields, generate audit events, or reshape responses before they reach the caller

Zero application changes

Enrichment logic is externalized from application code — data source migrations and new attributes require no application changes

How Cerbos works with Proxy Extensions

Authorization decisions are only as good as the data behind them. Proxy Extensions provides real-time context (user profiles, group memberships, or external attributes) that makes Cerbos policies richer and more accurate.

Cerbos lets you write fine-grained, context-aware authorization policies in human-readable YAML. With Proxy Extensions as a context source, those policies can evaluate attributes beyond what's in the initial request.

Because enrichment happens at the policy layer, your application code stays clean, no custom plumbing to fetch and merge identity data before making authorization calls.

Policy-as-codeHuman-readable YAML policies managed like source code Scalable PDPStateless policy decision point with sub-millisecond latency Centralized managementManage, test, and deploy policies from a single control plane

The data problem in authorization

Authorization decisions require context — user attributes, group memberships, resource metadata — that rarely arrives in the initial request. Applications typically build bespoke data-fetching logic to assemble this context before calling the policy engine. Proxy extensions, a core component of Cerbos Synapse, externalize this responsibility.

How proxy extensions work

An application sends an authorization request with minimal context — a user ID and resource reference.
Proxy extensions enrich the request by fetching principal attributes, group memberships, resource metadata, or any other data from configured sources.
The enriched request reaches the policy engine for evaluation.
Proxy extensions process the response — redacting fields, generating audit events, or triggering side effects before it is returned.

Extensions are implemented as Starlark scripts or Wasm modules and can be chained in priority order. The calling application is unaware of the enrichment — it makes a standard Cerbos API call.

Why externalize enrichment

When data-fetching logic lives in applications, multiple teams independently build the same integrations, data source changes cascade into application deployments, and authorization data flows are scattered across codebases. Proxy extensions centralize this logic alongside the policy engine, making it auditable, observable, and independent of application release cycles.

Get started

Proxy extensions are available as part of Cerbos Synapse. Talk to us to learn more about externalizing authorization data enrichment.

FAQ

What are proxy extensions?

Proxy extensions intercept authorization requests as they pass through Cerbos. They can enrich requests with additional data before policy evaluation and transform responses before they reach the caller. The calling application is unaware of the enrichment — it makes a standard Cerbos API call.

What can proxy extensions do?

Common uses include fetching principal attributes from identity providers, looking up resource metadata from databases, redacting sensitive fields from responses, generating audit logs, and rolling out data source changes without modifying applications.

How are multiple proxy extensions ordered?

Each proxy extension has a priority value. Extensions execute in priority order. Extensions can be marked as required, which terminates the chain on failure, or optional, which allows the chain to continue.