Each file should have default security tables to enhance security administration and auditing. Developers should be able to use calculations, relationships, layouts, and scripts to audit and administer accounts and privilege sets. (Although there should be protected default layouts for this purpose, developer designed layouts using security tables should be possible, at least in FileMaker Pro Advanced.)
Of course these default tables and layouts would have different rules than most tables and layouts, for example, always requiring a full-access account to edit.
Administering and auditing security in a large organization for a complex system is one of the more tedious and yet most important aspects of maintaining the system. FileMaker security lends itself well to administering individual privilege sets, but most audits and changes require me to look or edit across several privilege sets.
A specific example is when I create new objects (tables, fields, layouts, scripts, etc.). I then have to go through all the privilege sets one by one, even if I'm going to give them all the same access.
Another useful purpose for this product idea is to allow developers to design security layouts to organize security the way they want to see it, without being limited to the interface deemed by FMI as best received by the greatest number of developers (which would probably not even be a majority of developers), conceivably appeasing every disenfranchised developer with interface preferences.
Of course this idea requires a level protection against the developer for default layouts, functionality, and security.
This idea is one part of a larger suggestion to tabulate all schema and objects into FileMaker tables and layouts to make those objects as easily and thoroughly findable, sortable, relatable, calculable, manipulable, and scriptable as any data in a database, making any system potentially as self-referential as possible for advanced developers.