It’s this. You have to run it as a service first, which requires a local admin account. Then you can see UAC prompts and use your AAD credentials.
I never did it as GoToAssist is my backup service, but I’m 98% sure if you set up unattended access on your endpoints, that it will always be “running as a service” and you won’t need local admin. But if the device ever stops communicating with the domain or has issues where it may not recognize your AAD Admin rights, you still won’t be able help them without a local admin account.
A lazy/insecure way to manage local admin accounts: You can manage local admin accounts by using powershell scripts, but scripts are stored in plain text in intune log files on the endpoint device that by default non-admins can read. One thing people do is delete the log file after a script is run. A power user may not have much trouble capturing it unless the endpoints are locked down pretty good though.
You can also deploy a powershell script as a win32 app. The deployment of apps are encrypted end to end and would probably be more difficult or impossible for a power user to access if it’s run in a system context. But it's not the intended purpose so there isn't much out there, I would assume it isn't much more secure than just a powershell script over Intune.
If you do either of these options, write a log file somewhere on the local drive that gives you a reference for the last iteration of the admin password was last successfully deployed to that device. And keep a My CC Pay secure file for admins with a history of local admin passwords. There’s no useful feedback on Intune for when scripts are deployed and executed, but fail to do what was intended, so if it goes wrong on a client you’ll probably never know without these logs.