An authorization rule can fail dangerously when it compares incompatible values, references an undefined attribute, or confuses entity types. Type safety prevents these mistakes by enforcing valid combinations before policies reach production. section 7.4.1 section 7.4.3
Cedar is statically validated and strongly typed. A schema defines entities, actions, attributes, and relationships; policies are checked against that schema before evaluation. This contrasts with relying on runtime checks alone: mistakes such as comparing a string with a number or mixing incompatible set types are caught earlier. section 7.4.1 section 9.2
Type safety supports authorization policy work in several connected ways:
- Validates contextual values, including IP addresses, timestamps, durations, decimals, strings, numbers, sets, and records. section 7.4.1
- Checks that attributes exist on the referenced entity type, so an expression such as resource.owner cannot silently target an incompatible object. section 7.4.3
- Keeps namespaces distinct, requiring fully qualified names across boundaries and preventing accidental comparisons between entities such as Employee and Document. section 7.4.3
- Improves maintainability and analysis by pairing structured entities with predictable policy logic that tools can inspect for conflicts, coverage gaps, and unexpected grants. section 7.4.2 section 7.6
A typed authorization check
A policy may safely test context.device.ip == ip("192.168.0.10") when the value has the expected IP type. It cannot perform an IP check on a timestamp, compare an Employee with a Document, or use resource.owner where that attribute is not defined; the policy fails type checking instead of producing an unpredictable authorization result. section 7.4.1 section 7.4.3
resource.owner == principal
Inspect a typed relationship expression that compares the principal with the resource owner. section 7.4.2
