The rise of embeddable PDPs in modern architectures

Embeddable Policy Decision Points (PDPs) are changing how teams implement authorization. By running the PDP as a library within your application’s runtime (often powered by WebAssembly), you can achieve sub-millisecond authorization checks, minimal infrastructure overhead, and a smoother developer experience.

In this post, we’ll break down insights from a conversation between Alex Olivier, CPO and Co-Founder of Cerbos, and Mike Schwartz, host of Identerati Office Hours and the CEO of Gluu, on why embeddable PDPs matter, their benefits and trade-offs, and how you can start experimenting with this approach.

So, what is an “embeddable” Policy Decision Point?

A Policy Decision Point (PDP) is the component in an authorization system that evaluates policies and returns allow/deny decisions. If you've worked with traditional authorization tools, you’ve probably dealt with PDPs that live outside your application — separate services or sidecar processes that applications communicate with, for example, via a JSON/REST API. These setups can work, but they come with network latency, deployment complexity, and scaling headaches.

An embeddable PDP, by contrast, is one that a developer can load into their application runtime and use like a library – initialized in-process and invoked via simple function calls. In other words, the PDP runs within the same process as your application code rather than as an external service. It's fast. It's self-contained. And it’s especially useful when you’re dealing with UI rendering, edge deployments, or distributed systems.

Cerbos itself supports both models: a traditional PDP server and a build that compiles your policies down to an embeddable module.

The ePDP idea might sound obvious in hindsight, but it took the convergence of new tech (namely WebAssembly) and developer expectations for this pattern to hit its stride. We’ll dive into why WASM is such a game-changer for embeddable PDPs shortly, but first, let’s explore the benefits this approach brings.

Why embeddable PDPs? Benefits at a glance

1. It’s fast - really fast

Speed is the headline benefit. Since an embedded PDP runs within your application, authorization checks become as fast as a function call – no network hops, no IPC overhead. Every external call, even a local REST API, carries millisecond-level latency costs, which can add up if a page or operation requires dozens of permission checks. In contrast, an in-process check can typically be done in nanoseconds.

Once the PDP is embedded and initialized, there’s no further network involved – it feels just like calling a native function in your code. The bottom line: Embeddable PDPs can make authorization essentially instantaneous from the app’s perspective.

2. No extra infrastructure to manage

Another major benefit is the drastic reduction in infrastructure complexity. Because the PDP is just a library, there’s no need to deploy a separate service or maintain a sidecar container for authorization decisions.

• Easier deployment: You ship your app with the PDP code included. You don’t need to provision and monitor an extra service.
• Scalability handled by the app: With an embedded approach, every instance of your app includes its own PDP. If your app scales out, the PDP scales out automatically with it.
• Less ops overhead: There’s no need to manage network configurations, service discovery, or high availability for a separate authz service. The PDP runs wherever your app runs.

3. A better developer experience

From a developer’s standpoint, working with an embeddable PDP can be far more straightforward than calling out to a service. You can use native language imports and function calls instead of constructing HTTP requests.

This local integration also makes testing and development easier. You can unit-test authorization logic without spinning up extra services. Embeddable PDPs essentially act like any other code library, which is a familiar model for developers.

4. Powered by WebAssembly

A recurring theme in the discussion was how WebAssembly (WASM) has enabled the rise of embeddable PDPs now. There are a few reasons WASM is a perfect fit for authorization engines:

• Language and environment agnostic: You can write the PDP logic in a systems language like Go or Rust, and compile it to WASM.
• Small footprint and speed: WASM binaries are generally compact.
• Secure sandboxing: WebAssembly runs in a sandboxed environment.
• Modularity and composability: The growing ecosystem around WASM modules includes emerging standards for WASM components.

It’s not all roses - Key trade-offs of embeddable PDPs

1. You’ll need to provide the data

The objection is that running an authorization decision in the browser might need to query an internal source. The insight is that a PDP should be stateless – it should not reach out to databases or external APIs during policy evaluation.

2. Token enrichment?

Tokens like JWTs carry user information to a distributed PDP. If your current IAM/SSO system doesn’t give you all the info you need in the token, you might have to call backend APIs. The response was to push for tokens to be richer, to include the necessary attributes.

3. Policy distribution and audit logging gets harder

Managing many PDP instances running out in the field presents challenges in ensuring all have the latest policy and aggregating their decision logs.

4. Hybrid architectures

Adopting embeddable PDPs doesn't mean you must abandon all centralized authorization services. Hybrid models are perfectly valid.

Use cases for embeddable PDPs

Conclusion

Embeddable PDPs represent a significant shift in how we think about authorization architecture. Instead of a monolithic, central decision service, we have the option to distribute the decision making out to the edges of our systems.

Now is a great time to experiment with embeddable PDPs. Many organizations might end up with a hybrid approach, and that’s okay – you don’t have to flip a switch on everything overnight.