Embeddable PDPs shift authorization closer to application runtime

At a glance

What this is: Embeddable policy decision points move authorization into the app runtime, making decisions faster and more self-contained.

Why it matters: That matters because IAM teams have to govern authorization decisions that now sit closer to code, tokens, and workload execution rather than a central service.

👉 Read Cerbos's analysis of embeddable PDPs and runtime authorization

Context

Embeddable policy decision points, or PDPs, change authorization from a remote service call into an in-process decision. That removes network latency, but it also shifts where identity context lives and where policy decisions are enforced.

For IAM programmes, the real issue is governance at the point of execution. When authorization moves into application code, teams have to think about token content, policy distribution, logging, and how to prove decisions after the fact.

This is especially relevant for distributed apps, edge deployments, and front-end authorization where central decision services can become a bottleneck. The design looks simpler operationally, but it asks more from identity architecture.

Key questions

Q: How should security teams implement embedded authorization without losing policy consistency?

A: They should treat embedded authorization as a distributed control plane, not a developer convenience. Standardise policy packaging, versioning, and rollout across every runtime, then verify that each instance receives the same approved bundle and the same input contract. Consistency matters as much as speed because a local decision engine only works when policy behaviour stays stable across deployments.

Q: Why do embeddable PDPs increase the importance of token design?

A: Because the PDP can only evaluate what the application gives it. If the token lacks stable identity attributes, the app has to call elsewhere for context or accept weaker decisions. Rich, carefully bounded claims let the PDP decide locally without network dependence, which preserves the performance and resilience gains the embedded model is trying to deliver.

Q: When does an embeddable PDP design fail in practice?

A: It fails when teams assume the policy engine can compensate for incomplete application context. If the app cannot supply resource facts, tenant context, or user claims at decision time, the PDP becomes either overly permissive or dependent on extra lookups that undo the original design. The control breaks at the data boundary, not the policy language.

Q: What should IAM teams do before moving authorization into application runtime?

A: They should validate which applications can supply all decision inputs locally and which cannot. Then they should define policy ownership, bundle distribution, logging, and rollback procedures before the first embedded deployment. The move works best when governance, not just code, is ready for a distributed decision model.

Technical breakdown

How an embeddable policy decision point works

A policy decision point evaluates policy against inputs such as user attributes, resource data, and requested action, then returns allow or deny. In an embeddable model, that engine runs inside the application process as a library rather than as a separate networked service. The policy logic is still the same control plane function, but the transport disappears. That changes failure modes: latency drops, but the app now owns the quality of the context it passes in. If the decision engine depends on incomplete or stale data, the result can still be correct in syntax but wrong in governance terms.

Practical implication: treat the in-process PDP as part of the application trust boundary and validate every input it depends on.

Why WebAssembly makes embedded authorisation practical

WebAssembly gives policy engines a portable execution target with near-native performance and a small runtime footprint. That matters because it lets the same authorization logic run in browsers, serverless functions, edge workers, and traditional back ends without a separate deployment model for each. The architectural benefit is portability, not autonomy: the engine is still executing predefined policy, just closer to the request path. For identity teams, the point is that authorization can now travel with the workload. That makes policy distribution and version consistency more important than infrastructure scaling alone.

Practical implication: standardise policy packaging and distribution so embedded runtimes do not drift across environments.

Token enrichment and stateless decision inputs

Embedded PDPs work best when the application supplies all the decision inputs up front. That usually means richer tokens, cached attributes, or data already available in the request flow. The design is intentionally stateless so it does not fetch external data during every decision, which keeps checks fast and predictable. But statelessness pushes complexity upstream into authentication, token issuance, and application design. If teams cannot carry the right claims into the decision point, they either over-permit to compensate or fall back to noisy runtime lookups that undermine the original performance model.

Practical implication: design your identity and token flows so the PDP can decide with local context, not live dependency chains.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime authorisation is no longer a separate infrastructure problem. It is an identity governance problem at the point of execution. Once the PDP lives inside the application, authorization quality depends on the claims, attributes, and resource facts the app can already present. That moves control from a managed service to code paths, token design, and policy packaging. The implication is that IAM teams can no longer treat authorization as a back-end utility detached from application behaviour.

Embedded PDPs expose a named governance gap: decision locality without policy consistency. The model assumes that putting the decision engine closer to the request will preserve the same policy outcome everywhere. That only holds if policy distribution, versioning, and input context remain aligned across every runtime. In practice, the failure mode is fragmented enforcement, where one application instance decides differently because its local bundle or context is not the same as another. Practitioners need to think in terms of consistency drift, not just deployment convenience.

Token enrichment becomes an authorization control plane requirement, not an optimisation. The article shows that embeddable PDPs are most effective when identity data travels with the request. That means claim design, attribute freshness, and token size are now part of the authorization architecture itself. The security discipline shifts from asking whether a policy exists to asking whether the right facts are available at decision time. The implication is that teams must govern token content as carefully as they govern policy logic.

Embedded authorization is best understood as a workload identity pattern, even when the subject is a person. The user may be human, but the control now executes in application runtime alongside workload code. That is why NHI thinking matters here: local runtime trust, policy portability, and deterministic inputs are the same issues that show up in workload identity governance. The practitioner conclusion is that modern authorization design increasingly lives at the intersection of human identity, application runtime, and non-human execution.

From our research:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• If you are mapping where runtime authorization, workload identity, and agent governance intersect, see Top 10 NHI Issues for the control themes that keep recurring.

What this signals

Embedded authorization will push more teams to treat policy distribution, token enrichment, and audit logging as one operating model rather than separate tasks. The governance challenge is less about whether the PDP is fast enough and more about whether the organisation can prove why a decision was made after the fact.

Runtime policy drift: when authorization moves into application code, small changes in policy bundles or token content can create inconsistent decisions across environments. That means identity teams need stronger release discipline, clearer ownership, and better evidence capture across app, policy, and logging layers.

For practitioners

• Map every local decision input Inventory which claims, resource attributes, and request fields the embedded PDP needs, then verify each one is available before the policy runs. If a check depends on live lookups, move that data supply earlier in the request flow instead of letting the PDP reach out at decision time.
• Govern policy distribution like code deployment Track policy bundles, runtime versions, and rollout paths so embedded instances do not drift. A local authorization engine is only reliable if every environment receives the same validated policy and the same change control process.
• Enrich tokens with decision-grade attributes Carry roles, tenancy, and other stable attributes in tokens where they are needed for local authorization. Keep the claim set intentionally small, but make sure it is sufficient for the decisions the app must make without backend callbacks.
• Separate policy evaluation from data fetching Keep the PDP deterministic by feeding it context rather than letting it query other systems during the decision. That preserves latency, reduces hidden dependencies, and makes the authorization path easier to test and audit.

Key takeaways

• Embeddable PDPs reduce latency by moving authorization decisions into the application runtime, but that shifts governance responsibility into code, tokens, and policy distribution.
• The architectural trade-off is consistency, not just performance: local decision points only work when every runtime receives the same context and the same approved policy.
• IAM teams should govern embedded authorization as a distributed control plane, with explicit ownership for inputs, bundles, logs, and rollback.

Key terms

• Policy Decision Point: A policy decision point is the component that evaluates rules and returns allow or deny outcomes for a requested action. In embedded form, it runs inside the application process, so its correctness depends on the inputs the application supplies and the consistency of the policy bundle it loads.
• Embeddable Authorization: Embeddable authorization is an access control pattern where policy evaluation happens inside the application runtime instead of a separate service. It reduces network overhead, but it also moves governance concerns into code deployment, token design, logging, and runtime consistency across environments.
• Token Enrichment: Token enrichment is the practice of adding useful identity and context claims to a token so downstream systems can make faster, local decisions. It is only effective when the added data is stable enough for authorization and limited enough to avoid stale or bloated tokens.

Deepen your knowledge

Embedded authorization, token enrichment, and policy distribution are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance into application runtime, it is worth exploring.

This post draws on content published by Cerbos: Embeddable Policy Decision Points and runtime authorization. Read the original.