Notifications
Clear all
Topic starter
11/06/2026 11:41 pm
TL;DR: JSON Schema validation for principal and resource attributes catches typos, mismatched formats, and unexpected fields before they break authorization decisions, reduce auditability, or create subtle access errors, according to Cerbos. The deeper lesson is that policy engines need explicit data contracts, not trust in whatever payload arrives.
NHIMG editorial — based on content published by Cerbos: schema validation for authorization inputs
Questions worth separating out
Q: How should teams prevent authorization failures caused by bad input shapes?
A: Teams should define schemas for every principal and resource attribute that affects policy evaluation, then enforce those schemas before authorization decisions are made.
Q: When should validation move from warn mode to reject mode?
A: Move to reject mode after the application payloads are stable enough that malformed requests represent defects, not expected discovery.
Q: What do security teams get wrong about authorization schemas?
A: They often treat schemas as documentation only, when they are really part of the control model.
Practitioner guidance
- Define schemas for decision-bearing attributes Create schemas for principal and resource attributes that directly influence policy outcomes, and keep them in the same policy store so reviewers can inspect the contract alongside the rule set.
- Roll out validation in warn mode first Use warn mode to collect shape mismatches from live traffic, then fix the application payloads before switching to reject mode for enforcement.
- Standardise attribute names across services Eliminate casing and naming drift by publishing a shared attribute contract for every microservice that calls the authorization layer.
What's in the full article
Cerbos's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how to structure principal and resource schemas in policy storage
- Guidance on when to use warn mode versus reject mode during rollout and testing
- Practical use of ignoreWhen for lifecycle actions such as CREATE and DELETE
- Implementation patterns for composing shared attribute definitions with $ref
👉 Read Cerbos's guide to schema validation for authorization inputs →
Authorization schemas in Cerbos: why contract validation matters?
Explore further
12/06/2026 8:29 am
Authorization schemas are a governance control, not just a developer convenience. The article shows that schema validation turns implicit assumptions about authorization inputs into explicit contracts. That is the difference between a policy engine that merely executes logic and one that can be trusted to evaluate the right data. For identity programmes, the implication is that access governance starts at the payload boundary, not at the policy statement.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: How do I handle lifecycle operations that do not fit strict validation?
A: Use action-specific exceptions for cases where the resource is still transitioning, such as CREATE or DELETE. The important part is to scope the exception tightly and document why it exists. That preserves strict validation for steady-state access while avoiding false failures during object lifecycle changes.
👉 Read our full editorial: Cerbos schemas expose the contract gap in authorization data
