Something that has been explained here on Connect and in KB articles and such like (and is also readily observable with tools like Process Explorer) is that the both the management server's service - ngserver.exe - and the management client service - ngctw32.exe - do not run as *any* logged-in user.
Rather, they run, as most services do, in the special service context under a built-in account known as LocalSystem (aka .\System) which has a particular special user right not available to any other account called SE_TCB_NAME that is required to use some of the low-level APIs that the service applications need to call. All the processes spawned by the management client also run in this special account context, which gives them the maximum amount of power (even more than an Administrator account) to affect the local system.
[ Note that when running under Windows PE in a pre-boot environment, there is no user account database and so all processes run in Windows PE also use the special LocalSystem account environment. ]
The special role played by the domain-level account is also documented: it exists *solely* to create (or move from one AD container to another) machine accounts on a domain which is targeted by a "join to domain" task step, and is not used for any other purpose at all - the account is never logged in, and is simply used for remote authentication in RPC connections, and is never transmitted or used to clients.
The management server process does temporarily take on other identities for special purposes during the execution of a task to work around peculiarities of Windows security that customers are frequently aware of, such as rights to network shares. When a task is initiated, the management server retains a copy of the identity of the user that launched the task and will temporarily impersonate that user to access resources such as files and images that are often stored in places which would otherwise be inaccessible. Again, however, that identity is never transmitted to, or used by, clients.
So, elevation as a concept does not apply to commands launched through the console; commands are always launched with the maximum privilege it is possible for a process to have. However, there are some small trade-offs for this: one is that processes running as LocalSystem do not have any user's identity on the network (if they are members of a domain, there is some tricky special-casing inside Windows that makes access by such process authenticate as the machine itself, since in Active Directory environments machines themselves have user accounts which can be added to ACLs).
The other minor tradeoff is that per-user parts of the normal process environment, such as registry keys under HKEY_CURRENT_USER do not refer to any user's data; some aspects of Windows configuration such as that of printer settings is always stored per-user, and so scripts which alter such settings simply need to be aware that Windows is in fact a multi-user operating system. Since they are run under the LocalSystem account, scripts launched by the management agent have the ability to enumerate and modify all the user profiles present on a client machine, and so scripts which alter settings that are strictly per-user need to make use of that capability.