How can teams decide between CEL, Starlark, and WASM for authorization extensions?

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.

Why This Matters for Security Teams

Authorization extensions are not just a developer convenience. They become part of the security boundary when teams use them to decide who or what an agent, service, or workload can do at runtime. That means the choice between CEL, Starlark, and WASM affects auditability, blast radius, and how quickly bad policy can be corrected. The practical question is not which language is easiest, but which one best matches the control surface and review process.

NHI risk is already amplified by overprivileged, long-lived identities. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges in its Ultimate Guide to NHIs, which is why extension logic must be easier to reason about than the credentials it protects. For teams aligning to the NIST Cybersecurity Framework 2.0, this is a governance decision as much as an engineering one.

In practice, many security teams encounter policy drift only after a custom rule has already been copied into production several times, rather than through intentional control design.

How It Works in Practice

CEL, Starlark, and WASM sit on a spectrum of expressiveness and assurance. CEL is usually the best fit for declarative checks such as attribute matching, claim evaluation, and simple allow or deny logic. It is easier to inspect, easier to constrain, and usually simpler to validate in code review. Starlark adds lightweight scripting for logic that goes beyond pure expression syntax, but that flexibility also increases the need for safe execution rules, version control, and test coverage. WASM is the most packaging-oriented option of the three, and it is often used when teams need compiled policy or authorization logic with stronger deployment discipline.

A useful way to decide is to ask how much power the extension really needs:

• If the rule is a straightforward mapping from context to decision, CEL is usually enough.
• If the logic needs loops, helpers, or structured branching, Starlark may be appropriate.
• If the code must be shipped as a hardened module with clearer boundaries, WASM often fits better.

That decision should be paired with operational controls: version pinning, test fixtures, code review, runtime timeouts, and rollback procedures. For NHI-heavy environments, this matters because authorization code often touches secrets, service accounts, and machine identities that are already difficult to inventory. NHI Mgmt Group’s Ultimate Guide to NHIs also highlights how widespread exposure is when identities are not governed tightly. Current guidance suggests treating extension logic like production security code, not application glue. These controls tend to break down when teams embed policy directly into application releases because rollback speed and review rigor are both limited by the application deployment cycle.

Common Variations and Edge Cases

Tighter policy control often increases implementation overhead, requiring organisations to balance faster iteration against stronger assurance. That tradeoff becomes sharper in environments with multi-team ownership, regulated workloads, or frequent policy changes.

There is no universal standard for this yet, but current guidance suggests the following edge cases deserve special handling. If policy authors are non-developers, CEL is usually the least risky because the syntax is constrained and easier to govern. If the organisation needs reusable helper functions or custom decision trees, Starlark can work, but only if the team applies strict review and testing discipline. If the environment requires portability across runtimes or stronger isolation of authorization logic, WASM may be preferable, though it adds build, signing, and supply chain complexity.

Teams should also consider failure modes outside the policy engine itself. For example, if extension logic depends on live identity context, stale attributes can produce unsafe decisions even when the code is correct. That is why NIST Cybersecurity Framework 2.0 style governance should include change control, logging, and periodic validation of decision paths. Where extension code must evaluate secrets access for machine identities, weak review practices can turn a small rule into a privilege escalation path. The right choice is the one your team can test, constrain, and explain under audit without guessing at runtime behaviour.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How should teams decide between cloud-hosted and self-hosted authorization?
• How should teams decide between a general policy engine and a purpose-built authorization layer?
• How should teams secure non-human identities across cloud and SaaS?