Our shared SQL Server instance hosts databases for several client projects and every login can see every database name in the Object Explorer tree, which one client has now flagged as a confidentiality issue.
They cannot open each other's databases, permissions handle that, but can the names themselves be hidden?
They can, through a permission most people never meet: VIEW ANY DATABASE, granted to public by default, which is why everyone sees the full list. Revoke it and a login sees only master, tempdb and databases it owns.
The command is DENY VIEW ANY DATABASE TO [loginname], or to a role holding the client logins. From that login's next connection, Object Explorer and sys.databases both show the trimmed list, the names of other clients' databases vanish from every enumeration.
Now the sharp edge that decides whether this works for your setup: the visibility exception is database ownership, not database access. A login granted db_owner inside a database still cannot see it in the list unless it owns the database at the server level, meaning ALTER AUTHORIZATION ON DATABASE::[ClientDB] TO [clientlogin]. One owner per database, so this maps cleanly when each client has one primary login and gets awkward when several logins per client all need the listing.
For the awkward case the honest answer is architectural: contained users connecting with an initial catalog straight into their database never browse the server list at all, or separate instances per client end the question entirely. The DENY is a real and supported answer for the one login per client shape, just verify each client's tooling behaves when the server list goes dark, some ORMs and backup tools enumerate databases and need their connection strings pointed explicitly.
Denied on the client role and transferred ownership of each database to its primary login. The flagged client confirmed the list now shows only their own. The ORM warning was earned, one tool needed its catalog set explicitly.