It depends on what level of granular access controls you need.
The Rights module can use PREMIS Rights statements to restrict access to the digital object master and any of its derivatives (thumbnail in search/browse results; reference display copy on the description view page), but it is designed to only work for non-authenticated users - that is, users who are not logged into AtoM. If all the users you are referring to are public (i.e. not logged in) users, then this solution could work very well - though it also does not allow per-account exceptions.
You could create a new user group for people who need to log in, and restrict all but the View permissions (so they can't edit or delete content, etc.) but there are several other permissions that this affects. For example, publication status works the same way - so anyone who can log into the application will be able to view draft records. You can use the permissions module
to Deny permission to view drafts, but they will still be visible in search and browse results, in the treeview of hierarchical descriptions, etc - your logged in users just won't be able to click on them for further information.
If you are using the Visible elements
module, this also operates in the same way: once a user is logged in, they will be able to see any fields that were hidden from public users using this module.
I'm still not 100% clear on your use case, so let me know if this answers your question, and if not, perhaps provide a bit more detail on what the current access arrangement looks like, and what your desired use case / outcome would be? Thanks!