The problem isn't exactly with root (configuration management has root-like privileges), but push vs pull.
Both rely on the confidentiality of a private key on the master (the server identity if it is a pull, client identity if it is a push), but to fool a pull you also have to subvert the dns or the routing. Using ssh certificates that expire and are tied to the master's address would be a good first step making push safer against key interception.
If someone can find a way to write to your master change management repo, you're boned. (Is it sitting on NFS? If so, you may have a problem!) If someone roots the master box that you're pushing from or that your clients are pulling from, you're boned.
Technically you don't have to use root anywhere. You can push from a master box as an unpriviledged user and specify any user on the target machine to connect as, and ssh keys (along with an agent) will take care of the rest. The target machine doesn't need to be running your config management as root, you just need to set up a config management account with rights to the users/groups that your services are running. Your service may get compromised but root wouldn't - until they run a local priv escalation 0day.
I think you're confused. Since the tools are using either SSL or SSH these protocols (when properly implemented) prevent mitm or spoofing attacks on things like dns or routing protocols. Your key does not get intercepted, ever, because you're never sending a private key. But some machine, somewhere, has to have keys or you can't log in.
The only thing you have to worry about is someone getting both the keys AND access to a server that's running an agent that you've authed with. If you're super duper paranoid ssh-agent has an option to never cache a given key's authorization so it can ask you for the password for the key every time you use it. I'm pretty sure that would be super annoying, though, so better to just run one agent once for an entire batch push/deployment and kill it once your job is done.
Both rely on the confidentiality of a private key on the master (the server identity if it is a pull, client identity if it is a push), but to fool a pull you also have to subvert the dns or the routing. Using ssh certificates that expire and are tied to the master's address would be a good first step making push safer against key interception.