What security boundaries exist in Windows?

Microsoft recently shared its Security Servicing Criteria that explicitly defines security boundaries of Windows and its applications:

• Network boundary: An unauthorized network endpoint cannot access or tamper with the code and data on a customer’s device.
• Kernel boundary: A non-administrative user mode process cannot access or tamper with kernel code and data. Administrator-to-kernel is not a security boundary.
• Process boundary: An unauthorized user mode process cannot access or tamper with the code and data of another process.
• AppContainer sandbox boundary: An AppContainer-based sandbox process cannot access or tamper with code and data outside of the sandbox based on the container capabilities
• User boundary: A user cannot access or tamper with the code and data of another user without being authorized.
• Session boundary: A user logon session cannot access or tamper with another user logon session without being authorized.
• Web browser boundary: An unauthorized website cannot violate the same-origin policy, nor can it access or tamper with the native code and data of the Microsoft Edge web browser sandbox.
• Virtual machine boundary: An unauthorized Hyper-V guest virtual machine cannot access or tamper with the code and data of another guest virtual machine; this includes Hyper-V Isolated Containers.
• Virtual Secure Mode boundary: Data and code within a VSM trustlet or enclave cannot be accessed or tampered with by code executing outside of the VSM trustlet or enclave.

User boundary says "without being authorized": by running runas, you give the authorization (by providing sufficient credentials), so the boundary is not violated.

Modern windows systems use UAC (User Account Control.) This works with a token based system. So for example you have a windows account, and that account has local admin.

When you login you will be issued a token that allows to execute programmes with your low level user privileges, thus limiting you to the least possible privilege.

If an executable requires elevated administrative privileges to run, when you lunch it, it will prompt you as the user to explicitly okay it.

When you do this windows will check if you have administrative privileges, which you will as you are a member of the local admin group and it will issue a token allowing that instance of the executable to run with higher level privileges.

This keeps the policy of most restrictive privilege in place, as your user account will still be running with its low level privileges, but the instance of the executable will have the higher level privilege, thus creating a security boundary.

The run as feature works in much the same way, except it will check what privileges the account that is being used to 'run as' has, instead of the account you are logged in as.

So if you are logged in as your normal user account that does not have local admin, but you do know the local administrator credentials, you can run an executable that requires elevated privileges with the run as features, use the local admin creds and again the token will be issued allowing that instance of the executable to run with the required level of privilege.

So rather than undermining the security boundary, it is in fact enabling the security boundary.

You can read more detail here.