One thing I find interesting is that AWS has added some safeguards to the console to protect against exactly this, since it's presumably a very common issue. As of the last couple years when you make any S3 bucket open to the world you see a big warning about it.

However if you're following the "industry best practices" and using something like Terraform to manage all your resources including IAM policies, you won't ever see the warnings. If you take a step back, it's somewhat bizarre that we've decided that having infra teams manage hundreds or thousands of lines of not-very-human-readable JSON across all the IAM resources they manage is the proper way to do things. I believe there are some linters that have some semantic understanding of IAM rules that could provide the same benefits, but at least when I last looked into it they weren't very mature and didn't match all of AWS' own rules.

After experiencing some of the pains of managing a large Terraform configuration in the past, I've definitely started to wonder if we take the idea of "infrastructure as code" too literally. I think manually writing text-only configuration files for infrastructure should start to be seen as an anti-pattern as well, and we should mostly be working with better, more intuitive UIs for creating resources and then outputting the representation in some log format (which can then be read back by the same tool for reviewing/diffing, replayed in additional environments, rolled back, etc.)