Cedar 4.13

Apply these standalone rules to applications using the Cedar 4.13 SDK, CLI, or Wasm authorizer and Cedar language 4.5. Treat the policy store, schema, entity provider, request builder, and decision gate as parts of one authorization system.

Release and feature boundaries

• Track the newest security-maintained Cedar 4.x minor through a normal Cargo caret requirement and a committed, bot-updated lockfile; do the same for the Wasm package. Cedar normally ships 4.x fixes on its newest minor and backports selectively. Check Cedar's own advisory page before a rollout or rollback, and keep CLI and SDK behavior aligned. Obtain any exact artifact version from its registry or release page rather than memory; use a bot-maintained image digest for CLI containers.
• Build the Rust SDK with a toolchain meeting its declared minimum of Rust 1.89. Keep ipaddr, decimal, and datetime extension features consistent between policy validation and authorization; these are default crate features, but a build that disables defaults changes what policies can run.
• Review experimental tpe, protobufs, and partial-eval uses separately from the ordinary decision path. Do not feed a tolerant AST or a residual/unknown decision into an effect gate.

Construct the question from trusted state

• Authenticate before creating a Cedar request. Map the operation to a server-selected action UID, resolve the actual resource object, and construct the principal from the verified identity; reject client-selected principal, action, or tenant identifiers that disagree with that state.