For archival descriptions, there are a number of ways you can control the visibility of descriptions for public users. The primary method of doing so is via the Publication status - a record set to Draft will not be displayed (including in search/browse results) for public users. See:
You can also use the Rights module to control the visibility of digital objects - this is useful if you want to let users know that a digital object exists, but can't actually share the master image (and/or any of its derivatives) for reasons such as copyright, donor agreement, etc. See:
Finally, we have the Visible elements module, which can be used to control the public visibility of specific fields within a description - so, for example, if you don't want to display the Dates of creation, revision and deletion or the Archivist's notes field(s) in the Control area and use them for internal use instead, the Visible elements module will allow you to remove them from public display. See:
However, this module could use some enhancements to make it totally secure for including private internal information. Currently, only the Physical storage data is also removed from CSV and XML exports and generated finding aids when hidden via Visible elements (and exports and finding aids are set to generate as public users). Other fields (such as the examples I gave above) are hidden from user interface, but would still be included in a generated finding aid or an export - meaning your users may still have ways of seeing the information. It would be great to be able to do further development so that any field hidden in Visible elements is also automatically removed from exports and finding aids, but this will require sponsorship for Artefactual to be able to implement in a future release.
The other big limitation is that currently, only archival descriptions have a publication status - we do not have a Draft mode to hide records for other entity types such as authority records, terms (such as place and subject access points, etc), repository records, and functions. Essentially, this means that as soon as you create an authority record (or subject/place/genre access point, repository record, etc), they will be visible to public users in your site. This is one of the disadvantages of using a single interface for both internal staff users editing records and for public users exploring AtoM as a catalogue of holdings. As we consider changes for AtoM3 in the future, separating the front and back end (so that users can have more control over what records are made public) is something we are hoping to include.
In the meantime, adding a publication status to AtoM for other entity types such as authority records is something we would very much like to do. As you may know, AtoM's development is driven by community support, either in the form of feature sponsorship or community code contributions. You can read more about the history of the project, and how we maintain and develop AtoM here:
If your institution has access to developers, we have a number of development resources
on our wiki to help you get started, and some recommendations when submitting major pull requests
back to the public project. If, on the other hand, your institution might be interested in sponsoring development to enhance the Visible elements and/or a publication status for authority records, feel free to contact me off-list, and Artefactual can prepare some estimates for you.
For now, here are a couple possible workarounds that might help manage access:
First, you can use AtoM's permissions module to restrict some access to other entities (such as authority records). If you adjust the default permissions for the anonymous group (i.e. public, non logged in users), you can set View permissions to "Deny." This will prevent users from being able to go to the view page for an authority record. However, users will still see creator names linked to descriptions, and they will still be able to search and browse authority records - they just won't be able to click through on the results to see the full record. For more on adjusting permissions and managing user groups, see:
Additionally, it wouldn't give you control over specific fields or a permanent way to hide other entities from public users, but one thing you can consider for having more control over the visibility of other entities for public users would be to set up a separate read-only public site, with a replication script managing updates between your staff edit site and the public one. We offer this by default to our Premium+ hosting clients, and we have a bit more information on the setup and its advantages on our website, here: Essentially, it's a public-facing read-only site and a secure internal read/write site for staff, with a replication script used to periodically copy the database, digital objects, and search index from the R/W site to the public one. This allows for not only greater security (since your internal site can sit behind a firewall, etc), but aggressive caching on the public site to help improve performance. Additionally, because you control the replication script, you can essentially choose when you push updates to the public site - meaning you can work on authority records internally, and they won't become publicly discoverable until you choose to run the replication script.
We've made the replication script that we use as part of this service publicly available for all to use, in our Artefactual Labs GitHub repository:
Finally, one other possible workaround would be to maintain two separate sites - one internal site with HTTP authentication added so only staff with the proper credentials can access the site, and a second public site. Rather than using a replication script to keep the two synched (but eventually have all other entities show up in the public site when replicating), you could choose to manually manage what you want to make public by exporting it from the internal site, and then importing it into the public site. There is some extra management labor here, since you would now have 2 copies of the data (so if you needed to update a description, you'd have to do it in the edit site, delete the version in the public site, and re-import), but this would give you full control over what you expose.
I hope this helps!