Summary
Align both Cedar policy engine bindings to the same underlying Rust core version (4.8.2) for true cross-engine parity. Currently there is a pre-existing 2-minor-version gap.
Current state (verified from source Cargo.toml files)
| Package |
Current pin |
Cedar Rust core |
Source |
| cedarpy |
4.8.0 |
4.8.2 |
k9securityio/cedar-py v4.8.0 Cargo.toml |
| @cedar-policy/cedar-wasm |
4.10.0 |
4.10.0 |
cedar-policy/cedar v4.10.0 cedar-wasm/Cargo.toml |
Gap: Python agent evaluates Cedar policies on Rust 4.8.2; TypeScript Lambda handlers evaluate on Rust 4.10.0. The contracts/cedar-parity/ golden fixtures validate that for our specific policies/inputs the results agree — but this is "tested-compatible," not "guaranteed identical."
Target state
| Package |
Target pin |
Cedar Rust core |
| cedarpy |
4.8.3 |
4.8.2 |
| @cedar-policy/cedar-wasm |
4.8.2 |
4.8.2 |
Both bindings on Cedar Rust 4.8.2 = true engine parity.
Why 4.8.2 (not 4.10.0 or 4.11.0)?
No cedarpy version wraps Cedar Rust 4.9+. The latest cedarpy (4.8.3, published 2026-05-14) still pins cedar-policy = "4.8.2" in its Cargo.toml. Until k9securityio publishes a cedarpy that wraps a newer Rust core, we must anchor to 4.8.2.
Deliverables
Acceptance criteria
- Both bindings resolve to Cedar Rust 4.8.2
- All parity fixtures pass on both sides
mise //cdk:test passes
agent/tests/test_cedar_parity.py passes
- Dependabot will not propose independent cedar bumps going forward
- Comment in pyproject.toml accurately reflects the parity relationship
Risk assessment
- Downgrading cedar-wasm from 4.10.0 to 4.8.2 — this is a 2-minor-version downgrade. Cedar's policy language is backward-compatible; our policies don't use 4.9/4.10 features. The WASM API surface for
isAuthorized is unchanged between these versions.
- If parity fixtures fail after the change — this would indicate the current 4.10.0 engine was producing different results than 4.8.2 for our test vectors, meaning the gap was silently divergent. This would be a finding, not a failure — fix the root cause (policy incompatibility) rather than reverting.
Future: upgrading to Cedar 4.10+
When k9securityio publishes a cedarpy version wrapping Rust 4.10.x:
- Bump cedarpy to that version
- Bump cedar-wasm to 4.10.x (matching Rust core)
- Refresh parity fixtures
- Single coordinated commit
This is tracked as a monitoring responsibility in #104 (scheduled Action for coupling detection).
References
Summary
Align both Cedar policy engine bindings to the same underlying Rust core version (4.8.2) for true cross-engine parity. Currently there is a pre-existing 2-minor-version gap.
Current state (verified from source Cargo.toml files)
k9securityio/cedar-py v4.8.0 Cargo.tomlcedar-policy/cedar v4.10.0 cedar-wasm/Cargo.tomlGap: Python agent evaluates Cedar policies on Rust 4.8.2; TypeScript Lambda handlers evaluate on Rust 4.10.0. The
contracts/cedar-parity/golden fixtures validate that for our specific policies/inputs the results agree — but this is "tested-compatible," not "guaranteed identical."Target state
Both bindings on Cedar Rust 4.8.2 = true engine parity.
Why 4.8.2 (not 4.10.0 or 4.11.0)?
No cedarpy version wraps Cedar Rust 4.9+. The latest cedarpy (4.8.3, published 2026-05-14) still pins
cedar-policy = "4.8.2"in its Cargo.toml. Until k9securityio publishes a cedarpy that wraps a newer Rust core, we must anchor to 4.8.2.Deliverables
cedarpyfrom4.8.0to4.8.3inagent/pyproject.toml@cedar-policy/cedar-wasmfrom4.10.0to4.8.2incdk/package.json@cedar-policy/cedar-wasmfrom4.10.0to4.8.2incdk/layers/cedar-wasm/package.jsonagent/pyproject.tomlto accurately say:parity with @cedar-policy/cedar-wasm@4.8.2 (both Cedar Rust 4.8.2)_cedar_parity_pinfield incdk/package.jsonto reference the correct versionsuv lock(agent) +yarn install(root)agent/tests/test_cedar_parity.py+cdk/test/handlers/shared/cedar-parity.test.ts.github/dependabot.yml:Acceptance criteria
mise //cdk:testpassesagent/tests/test_cedar_parity.pypassesRisk assessment
isAuthorizedis unchanged between these versions.Future: upgrading to Cedar 4.10+
When k9securityio publishes a cedarpy version wrapping Rust 4.10.x:
This is tracked as a monitoring responsibility in #104 (scheduled Action for coupling detection).
References
contracts/cedar-parity/README.md— parity test documentationdocs/design/CEDAR_HITL_GATES.md§15.6 — decision refactor(agent): decompose entrypoint.py into modular src/ package wi… #23 (parity requirement)