Notifications
Clear all
Topic starter
22/06/2026 9:56 am
TL;DR: A skill-based way to scaffold extension logic for authorization pipelines now covers call mapping, data lookups, proxy rewriting, custom endpoints, and Envoy integration across CEL, Starlark, and WASM, according to Cerbos. The main governance issue is not code generation but whether teams can reliably control, test, and load the right extension path for each authorization use case.
NHIMG editorial — based on content published by Cerbos: Cerbos Synapse extension skill for authorization pipelines
Questions worth separating out
Q: How should security teams govern authorization extensions in policy pipelines?
A: Security teams should govern authorization extensions as part of the control plane, not as incidental application code.
Q: Why do authorization pipelines create extra risk for non-human identities?
A: Authorization pipelines create extra risk for non-human identities because these subjects often depend on contextual checks, attribute lookups, and request transformation before a decision is made.
Q: What breaks when extension logic is added without configuration discipline?
A: When extension logic is added without configuration discipline, teams can end up with code that exists but never executes, or executes against the wrong inputs.
Practitioner guidance
- Inventory every extension point in the authorization path Document where requests can be mapped, enriched, rewritten, or routed before a Cerbos decision is made.
- Standardise runtime validation for CEL, Starlark, and WASM Create separate test and approval patterns for declarative, interpreted, and compiled extensions so loading and execution failures are caught before deployment.
- Separate policy changes from pipeline changes Keep policy authorship distinct from changes that alter request shape, attribute source, or callback mode.
What's in the full article
Cerbos's full article covers the operational detail this post intentionally leaves for the source:
- The exact skill install flow for different agent runtimes and plugin environments.
- The full extension matrix showing which extension type fits each authorization pattern.
- The generated file set, including config.yaml, sample policies, and docker-compose scaffolding.
- The troubleshooting flow for extensions that load but never fire, including decision-log use.
👉 Read Cerbos's article on the Synapse extension skill for authorization pipelines →
Cerbos Synapse extensions: what it means for authorization teams?
Explore further
22/06/2026 10:37 am
Externalized authorization is only as strong as the extension boundary. Cerbos Synapse shows that the fragile part of policy enforcement is often not the policy language itself but the plumbing around request mapping, attribute enrichment, and runtime loading. Once authorization becomes extensible, the boundary between policy and execution becomes a governance surface in its own right. Practitioners should treat extension selection as a control decision, not a developer preference.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How can teams decide between CEL, Starlark, and WASM for authorization extensions?
A: Teams should choose based on assurance needs, not developer preference. CEL suits simple declarative mapping, Starlark works when you want lightweight scripting, and WASM fits compiled logic that needs stronger packaging discipline. The decision should reflect how much control, testability, and deployment consistency the use case requires.
👉 Read our full editorial: Cerbos Synapse extension skill streamlines policy pipeline integrations
