TL;DR: Embeddable policy decision points move authorization into the application runtime, cutting network hops and simplifying deployment while creating new trade-offs around policy distribution, token enrichment, and auditability, according to Cerbos's analysis. For IAM teams, the architectural win only holds if governance, context handling, and logging keep pace with where decisions now happen.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “The rise of embeddable PDPs in modern architectures”.
Key questions
Q: When should teams move authorization checks into the application runtime?
A: Teams should move authorization checks into the application runtime when the policy decision is simple, the needed context is already available in the request, and latency matters more than centralised enforcement.
Q: Why do embeddable PDPs depend so heavily on token claims and request context?
A: Because an embedded PDP should evaluate policy without making its own network calls, it needs the subject, resource, and environment attributes up front.
Q: What breaks when policy distribution is not managed across embedded runtimes?
A: You lose consistency. Different application instances can end up enforcing different policy versions, which creates uneven access decisions, hard-to-trace outages, and weak assurance over what was actually enforced at runtime. Distributed authorization only works when policy rollout and rollback are controlled like any other production change.
Practitioner guidance
- Define which decisions belong in-process Classify authorization checks by latency sensitivity, context availability, and audit requirements before moving them into an embedded PDP.
- Enrich tokens with decision context Include only the claims the runtime needs for allow and deny decisions, and avoid forcing backend lookups for every check.
- Design policy distribution as a control plane Track policy versions, rollout state, and rollback paths for every runtime that loads embedded authorization logic.
Bottom line: Embeddable PDPs move authorization decisions into the application process, which can eliminate network latency but also changes where governance and evidence must be maintained.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Embeddable PDPs shift authorization closer to application runtime
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Embeddable PDPs shift authorization closer to application runtime
Embeddable authorization changes the control plane, not just the deployment model. When the PDP lives inside the application runtime, the enforcement point moves closer to the request path and farther from the central service model many IAM teams still assume. That makes latency disappear as a design constraint, but it also means policy consistency and observability must be engineered across every runtime that hosts the library. Practitioners should treat this as a governance redesign, not a simple implementation swap.
A question worth separating out:
Q: How should security teams balance speed and auditability in embeddable authorization?
A: They should keep the decision path fast while moving evidence collection out of the request path. That means local evaluation for allow and deny, but durable logging, version tracking, and review workflows outside the embedded process so performance gains do not erase governance evidence.
👉 Read our full editorial: Embeddable PDPs shift authorization closer to application runtime