Purpose of SAU in Multi-Master System

I don't understand the use case of the SAU in a Multi-Master system using the M33.

If the system uses an IDAU to define the secure memory map, enabling the SAU will override almost all IDAU settings with respect to the M33 because all memory is Secure unless configured otherwise in the SAU_RLAR.

Much of the literature discusses using a simple IDAU that uses bit 28 to define secure and non-secure memory space. This works out perfect for an 8 region SAU. Enable 1 region as NonSecureCallable,  7 regions as NonSecure, and the reset of memory is Secure.  For 4 region SAU, you are limited to 1 NSC and 3 NS regions.

If a system has another master however,  the only security attribution it can do is via what the literature calls a Lite-IDAU.  If the M33 enables the SAU, potentially an IDAU NonSecure Region can be marked as Secure with respect to the M33 but NonSecure to the other Master.  If the M33 stores any secure data in that section, the other Master can read that section with NonSecure transactions.

Many of the hardware bus level gates and requirements offered in the "System Design with ARM v8M" document don't make sense to me if everyone is playing by the same rules described in the IDAU.  

If the SAU is enabled in the M33 however, I can see why many of the gates their requirements need to be put in place.  They need to be there to protect against M33s view of the Secure Memory Map vs the other masters view of the secure memory map.

I feel like I am missing something with respect to the SAU in a multi-master system.  

Any feedback from the community is appreciated.