Testing resilience by actually causing the failure
Chaos engineering deliberately injects real infrastructure failures — killing a service outright, adding artificial latency, cutting network access to a dependency — into a running system, to observe whether it actually behaves the way its design intends, rather than trusting that it does because the design document says so. Applied to an authorization system specifically, this means genuinely killing the policy service in a controlled way and confirming the fail-closed behavior everyone assumes is configured actually triggers as expected, rather than taking it on faith.
This surfaces a category of gap that design review alone reliably misses: a fail-closed path that was correctly specified in the design but never actually exercised in practice, where some later change quietly broke it without anyone noticing, because nothing had ever forced that specific path to actually run.
A distinct discipline from fuzzing or red-teaming
Chaos engineering isn't about probing for exploitable logic flaws through crafted malicious input, and it isn't about a human creatively searching for an attack path — it's specifically about verifying resilience to the mundane, unglamorous, and inevitable infrastructure failures that eventually happen to every system regardless of how carefully its logic was designed: a crashed process, a network partition, a resource that runs out. All three disciplines matter, and none substitutes for the others.