You're correct that the information sheet is not as clear as it should be on this point - I apologize for any confusion, and am glad you're asking.
AtoM can be used by multiple institutions at once, and does support some basic multi-repository functionality. However, it is not truly multi-tenanted in the way you are implying, in that there is no isolation from one institution's users and records to another.
AtoM's multi-institution functionality was originally designed with access in mind, for union catalogs or regional portal sites. The thinking at the time was that each institution would have its own archival management system - AtoM or otherwise - and be contributing exports of records to a separate portal, typically managed by one administrator, to facilitate end-user regional access.
In reality, this is not how many institutions want to use AtoM, and in practice many regional portal sites are being used as the primary archival management system for dozens of institutions. However, doing so requires some trust among partners, and some compromises.
First, there are several modules that cannot be separated by institution - meaning if they are used, then all users will be able to see all records of this type from any contributing institution, and there is no easy per-repository facet or filter available. Examples include accession records, donor records, rightsholders, physical storage, and taxonomy terms (such as subject, place, and genre access points, etc).
Additionally, there are some known issues and limitations to the existing permissions module that will make it difficult or impossible to apply many customized permissions in an attempt to limit access to records per user to records associated with a specific repository. There's a lot that could be said here, but much of it has been said before. The short version is: AtoM's permissions module was first added over a decade ago (when the application's primary use case was small to medium archives, with simpler permissions needs), and unfortunately, while AtoM's user base has grown exponentially and the ways in which the community attempts to use it have multiplied, the permissions module has not received any significant overhaul. Consequently, there are many known performance and scalability issues, as well as a number of bugs that are difficult to change without performing a full rewrite. We'd like to do this, but it's a major piece of work - meaning that for Artefactual to take it on, we'd need community support, either in the form of community code contributions or development sponsorship. So far no one has been willing to fund the level of work necessary to truly address these issues.
For a longer response on some of the known issues with the permissions module, see some of our previous responses on this topic in the forum, such as:
If your users are not overly concerned about hiding draft records or accessions etc from each other, and if you can use local policies and agreements to manage conduct rather than relying on complex permissions to enforce separation, then AtoM can be used by multiple different institutions at the same time.
If you are looking for a fully isolated solution, AtoM in its current form cannot provide that - either you will need to find a compromise for sharing a single installation that all participants can agree to, or else look to install separate AtoM instances.