As an Incident Responder, you always want to be very careful on what assumptions you make when you're on a system. In that sense, your questions are quite pertinent.
However, you also exercise your judgment (in some cases, wrongly perhaps) on how much care is required in a particular instance. There are limits on what you can do with public-cloud-hosted systems. You try and work with those limits (such as not being able to boot from a CD); and find workarounds where possible. e.g., if you don't need live forensics, you could create your own "trusted boot image with trusted tools", boot from that image, attach the disks in question and investigate. This is pretty much the same principle as carrying you own boot disks (CDs or USB drives). I do this by default only when I'm working on highly sensitive servers - where the adversaries are likely to be highly skilled.
In all other cases I take the more efficient / pragmatic route - as @john-deters suggests.
Live Forensics are a bit more slippery. No easy how-tos there. You could mount a disk with your own tools (actually, in many cases you do) but that carries its own risks.
Finally, if you're going to install remote IR tools (like GRR for instance), you can only take precautions while installing the tools. As an added precaution, you should create a file-integrity alert (you need remote logging for this) to make sure the GRR package is not altered any way. If that isn't triggered, you are probably (yes probably, not certainly!) on solid ground when logging in for IR remotely.