Restrict permissions that can be granted by project or repository admins

My team manages a large Bitbucket server instance (6000+ repositories, 1000+ users) for a large company. We find the simplistic permissions model provided to be insufficient for an enterprise application. In particular, despite warnings, admins sometimes make repositories or whole projects read by everyone via Default Permissions or by granting "stash-users" read access (or more). We already disabled public access so only authenticated users can access these, but it is still not sufficient to manage this risk through auditing or alerting. 

Restricting Default Permissions seems like it would be relatively easy, it is more difficult to restrict groups that can be given permissions. 

Also, we currently restrict the groups that are available to be chosen by admins by using a prefix in the AD group search to use appropriate types/prefixes of groups. Unfortunately, Bitbucket does not actually implement AD properly so this breaks nested group lookups because the nesting may include groups not matching this pattern. The nested group search in AD is meant to be its own search, irrespective of the groups have been synchronised into Bitbucket. 

This is my suggestion for how "world-readable" could be restricted:

• There should be a global admin option to restrict Default Permissions to Admins, though the setting should be shown in the project/repo permissions
• There should be a global admin setting for what permissions P/R Admins are allowed to grant: None, Users, Users and All Groups (current), or "groups matching a pattern/whitelist" 
  • The pattern would allow us to restrict stash-users, and also require users use groups with a proper naming scheme such as SG-Bitbucket-*
  • This also solves a problem where nested groups do not work because we have restricted the LDAP group lookup to said pattern; we could relax that lookup
  • Bitbucket Admins should still be allowed to set any group in special cases
• Users should be able to see the Admins of any project/repository (even one they can’t currently access) so they can request access from them, rather than asking us.

We will determine an internal process for how to approve world-readable access. 

Thanks!