Linux

Others have written about how windows does it, but here's some more details.

A window which runs with higher privileges (even just elevated to admin but still with your same account) cannot be read by normal privileges. You can see this when you use a custom screenshot program with some privileged system utility, but it's key combo does not work when the higher privileged window is active (in the foreground, selected). The screenshot program could not access UI elements in the privileged window, and can't send messages to it, but it can still see it rendered and capture it.

There's also a feature called "secure desktop". This is a bit like opening a new desktop with it's separate "window namespace". It's distinct so much that it doesn't have the taskbar and start menu, and by default it would be blackness, but you don't notice it because the system takes a screenshot before opening it and sets that as background.
Admin utils rarely use this feature, as I know this is only used for the User Account Control window that appears when a program is asking for elevated permissions. This is where you type your password, or just accept or deny the elevation request.
The Keepass password manager can also make use of this feature for the unlock prompt, but it can't use it that effectively, because the new secure desktop can be found in some way by other programs if it was not created with elevated privileges. It writes about this in it's documentation.
Even though Linux nowadays has a password prompt dialog, it does not have anything similar to this secure desktop thing as I know.

Other than that, on windows (maybe linux too?) processes of the same user and privilege level can read each other's memory. Without elevation. It's quite complicated but it's always there.
And like with gdb and strace on linux, there are ways on windows too to analyze or modify at runtime how a process works.