When you mention the <audience> attribute, are you talking about an EAD 2002 XML import?
If so, then the short answer is: AtoM is not currently configured to do anything with these attributes; they are ignored on import.
The explanation, which might hopefully answer some of your other questions:
The basic ability to hide an archival description from public view is handled by the publication status module. You'll find instructions on changing it on a per-descriptive hierarchy basis here:
This is in fact the answer to your second question - to be able to hide some but not all descriptions from public users, I would recommend using the publication status setting.
There's also a global publication status setting, that determines if new records are by default set to Draft (i.e. hidden from non-logged in users) or Published (i.e. visible to public users). See:
If you need to update the publication status for a bunch of records at once, you can't currently do this via the user interface, but there is a command-line task that might help:
AtoM also does have various other ways of controlling the visibility of elements, including:
Some notes on these modules and their limitations:
The Visible elements are a global setting - they can't currently be configured to control the display of individual fields in each description or descriptive hierarchy. This is one of the main reasons that @audience is ignored on EAD imports - it can be set differently on different fields in the same XML file, and even differently on the same field at different levels in a hierarchical description. AtoM currently has no way of implementing restrictions with this level of granularity. This would require significant development for us to implement, including an overhaul of the existing Permissions module to make it more scalable and performant.
Additionally, when fields are hidden in Visible elements, they are hidden from public users only - it cannot currently be configured on a per-user or per-group basis. Meaning: anyone who has the ability to log in can see them.
Finally, when fields are hidden, they are hidden in the public user interface - but currently they are NOT removed from the EAD / DC / MODS / CSV exports, or the finding aids if you've generated one (since it is generated from the EAD XML). The one exception to this is Physical storage information: if you've hidden this via Visible elements, and you've set your Finding aid generation settings to "Generate as public user," then the storage information is excluded from exports and finding aids. We'd love to add similar support for all fields in the Visible elements module, but it will require development - meaning we need community support to be able to implement it.
The Rights module's ability to restrict access to master digital objects and/or their derivatives operates somewhat similarly: the restriction is only enforced for public / unauthenticated users. Meaning you cannot restrict them on a per user/group basis, and anyone who can log in can see your restricted images.
Finally, we come to the permissions module. The first gotcha is that using this module to restrict view access to certain record types for public users (for example, changing the View permissions for authority records in the anonymous group settings to Deny in an attempt to restrict access to authority records) will prevent public users from accessing view pages (i.e. the full authority record), but it will NOT restrict them from searching and browsing authorities, seeing creator names linked to descriptions as creators or name access points, etc.
In contrast, the publication status module on archival descriptions is more comprehensive: if you set a record to Draft, it is also excluded from search and browse results. We would LOVE to add a publication status setting to more entities such as authority records, but again - this will require community support for us to be able to develop and add it to a future public release.
The permissions module also has a number of known performance/scalability issues, so I don't really recommend adding a ton of very granular permissions. I've discussed this in greater depth in the forum previously: