Cerbos Synapse extension skill streamlines policy pipeline integrations

At a glance

What this is: Cerbos Synapse is a skill for scaffolding authorization pipeline extensions, with the key finding that most effort sits in choosing and wiring the right extension type rather than writing the logic itself.

Why it matters: It matters because identity and authorization teams need predictable control over how policy engines enrich principals, map requests, and enforce decisions across applications, gateways, workloads, and AI agents.

👉 Read Cerbos's article on the Synapse extension skill for authorization pipelines

Context

Cerbos Synapse targets the operational friction around externalized authorization, where teams can define policy logic but still struggle with extension plumbing, runtime selection, and integration wiring. For IAM and authorization programmes, that friction matters because control is only useful if the pipeline can be extended safely and repeatably.

The broader governance question is how to preserve decision integrity when authorization is no longer a fixed code path but a configurable pipeline with multiple extension modes. That affects NHI controls, workload identity flows, and any application that depends on contextual enrichment before an access decision is made.

The article is centered on developer productivity, but the underlying issue is identity governance across execution paths. Teams that rely on Cerbos, or similar policy decision patterns, need to know where request mapping ends and policy enforcement begins, because that boundary defines both security assurance and failure modes.

Key questions

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. That means tracking which extension types are allowed, who can change request mapping or attribute enrichment, and how each runtime is tested before deployment. The goal is predictable enforcement, not just functional correctness.

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. If any extension in that chain misfires, the system can either over-authorize or fail closed in ways that are hard to diagnose. Governance must cover the whole path.

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. In practice that means silent authorization gaps, broken enrichment, and inconsistent decisions across environments. Configuration and artifact loading are security controls, not deployment trivia.

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.

Technical breakdown

How authorization pipeline extensions change the enforcement path

Cerbos Synapse describes a pipeline where extension logic sits before, around, or alongside a policy decision point. A call mapper translates inbound HTTP or Envoy traffic into a Cerbos check, a data source retrieves attributes for enrichment, a proxy extension rewrites requests and responses, a route extension exposes a custom endpoint, and an Envoy extension converts ext_authz traffic into decisions. The technical value is that policy is no longer the only control surface. The extension layer becomes part of the authorization system, which means runtime choice, config wiring, and load order are now security-relevant.

Practical implication: Treat extension selection and request mapping as part of the authorization control plane, not just developer convenience.

CEL, Starlark, and WASM create different assurance models

The article makes clear that each extension type can be implemented in CEL, Starlark, or compiled WASM, with different operational trade-offs. CEL is declarative and low-friction, Starlark removes a build step, and WASM introduces a compiled artifact that must be built and mounted correctly. That matters because the assurance story changes with the runtime. A miswired compiled extension can fail differently from a declarative one, and debugging often depends on understanding whether the issue is language semantics, build output, or config loading.

Practical implication: Standardise how teams validate each runtime so extension behaviour is testable before it reaches production.

Why config wiring and local testability are part of security

Synapse is presented as solving the hard part around setup, config.yaml wiring, local PDP execution, and debugging when an extension does not fire. The skill scaffolds sample policies, docker-compose files, and test suites, then runs the extension against a local instance. That is important because authorization failures often look like logic errors when they are really deployment issues. In an externalized authorization model, observability, test harnesses, and decision logs are part of the control surface, not optional extras.

Practical implication: Require decision logs, test suites, and repeatable local execution before a new extension pattern is accepted.

NHI Mgmt Group analysis

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.

Policy engines now need lifecycle governance for extension logic, not just for policies. When a team can add call mappers, data sources, proxy handlers, and route extensions in several runtimes, the governance question expands from who can edit policy to who can introduce executable behaviour into the decision path. That is a classic NHI-style control problem applied to a policy control plane. The implication is that authorization programmes need inventory, review, and change control for extension artefacts as well as policy files.

Runtime diversity increases the chance of silent authorization failure. CEL, Starlark, and WASM do not just offer choice, they introduce different loading, compilation, and debugging failure modes. A system that appears configured can still never fire because the wrong artifact was mounted or the wrong callback mode was selected. For security leaders, the lesson is that authorization assurance depends on operational determinism, not just expressive policy.

Named concept: extension-path governance gap. The article points to a recurring failure mode where teams know what they want the decision engine to do but do not know which extension path, runtime, and wiring sequence will produce it reliably. That gap sits between policy design and runtime enforcement, and it becomes a governance issue whenever application teams can add executable logic to the authorization pipeline. Practitioners should classify that boundary as part of authorization governance, not implementation detail.

AI agents and service identities raise the stakes for contextual authorization. The article's own framing makes clear that the pipeline increasingly serves workloads, AI agents, and other non-human identities that need contextual checks before action. That means authorization is no longer just about human users and static roles. The governance model has to support machine and agent decision contexts without losing traceability, which is where externalized authorization becomes strategically important.

From our research:

• 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.
• For teams extending authorization into AI and machine contexts, the operational next step is to align pipeline controls with OWASP NHI Top 10 guidance before extension sprawl becomes governance debt.

What this signals

Extension-path governance gap: Once authorization systems allow multiple extension types and runtimes, the security problem shifts from policy correctness to execution-path control. Teams need to know which request transformations, attribute sources, and callback modes are authorised, because those choices shape the final decision more than the policy text does.

The growth of AI agents and non-human identities makes this issue more urgent because externalized authorization increasingly governs machine actors as well as people. That is why programmes should pair pipeline inventory with explicit control mapping to NIST AI Risk Management Framework where agent behaviour is part of the workload.

The practical signal is whether your team can explain, in one audit trail, how a request became a decision from intake through enrichment to enforcement. If that answer requires tribal knowledge, the programme has already drifted beyond reliable governance.

For practitioners

• Inventory every extension point in the authorization path Document where requests can be mapped, enriched, rewritten, or routed before a Cerbos decision is made. Treat each extension type as a governed control surface with ownership, review, and rollback criteria.
• 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. Require local PDP execution and decision-log review for each pattern.
• Separate policy changes from pipeline changes Keep policy authorship distinct from changes that alter request shape, attribute source, or callback mode. That split reduces the risk that an authorization change is misclassified as a harmless integration tweak.
• Govern extension artefacts with the same discipline as NHI controls Track extension code, compiled artifacts, and config wiring as security-relevant assets. Apply review, versioning, and offboarding steps when teams retire an extension or change the data source behind it.

Key takeaways

• Cerbos Synapse shifts attention from policy authoring to the harder problem of governing authorization extensions, runtimes, and request wiring.
• Compiled, scripted, and declarative extension modes create different failure patterns, so assurance has to be designed per runtime rather than assumed.
• Authorization programmes should treat extension artefacts, local testing, and decision logging as core governance controls for both human and non-human access paths.

Key terms

• Externalized Authorization: A model where authorization decisions are separated from application code and handled by a dedicated policy engine. The application asks for a decision, while policy and context are evaluated elsewhere, improving consistency but adding governance requirements around the full decision path.
• Policy Decision Point: The component that evaluates policy and context to return an allow or deny decision. In modern architectures it is only one part of the control path, because request mapping, enrichment, and runtime loading can all affect what the decision point actually sees.
• Authorization Extension: Executable or declarative logic that modifies, enriches, routes, or translates requests before or around an authorization decision. It expands flexibility, but it also increases the number of places where misconfiguration or silent failure can weaken enforcement.
• Non-Human Identity: A digital identity used by software, workloads, bots, tokens, or AI systems rather than a person. In authorization programmes, NHIs often depend on contextual decisions and pipeline controls, which makes their governance inseparable from the systems that enforce access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: Cerbos Synapse extension skill for authorization pipelines. Read the original.