Cedar 4.12

Apply these standalone rules to Cedar SDK 4.12.0, implementing Cedar language 4.5, and to applications that load its schemas, policies, templates, entities, and authorization requests. Treat authentication, policy administration, entity providers, request construction, and enforcement as separate trust boundaries.

Version and build scope

• Keep the Cedar SDK and CLI artifacts on the newest 4.x release with their intended feature sets, because Cedar ships fixes on its newest 4.x minor and backports them to older minors only case by case. In Rust, give cedar-policy Cargo's default caret requirement, never a ~ or = requirement that holds it on one minor or one release, commit a Cargo.lock that Dependabot or Renovate keeps current so each new 4.x release arrives as a reviewed update, and build with Rust 1.89 or newer. Use a caret range and a committed lockfile for @cedar-policy/cedar-wasm too, reference any CLI container image by a digest the bot maintains, and take any exact version from crates.io, npm, or the Cedar releases page, or leave a placeholder that fails the build, rather than a version you remember.
• Read each new 4.x release's notes and rerun the policy fixtures before merging it. Keep promotion gated on validation_passed_without_warnings() or reject ValidationWarning::InvalidActionApplication explicitly: 4.13 reports a policy whose scope can never match an action's appliesTo as a warning instead of an error, so a mistyped forbid that can never apply passes validation_passed().
• Keep the validator and authorizer on compatible versions