something tangentially i am interested in is computing following the 'two person rule' for things like sudo. Yes I am logged into server X at terinal Y, and so is my co-worker and we both sign off on running command X
Had something like this at Google. There's a service running as root (or equivalent) which receives your desired command to run, and it has to get authorization from another user for the specific command to run, then runs it. That makes sense at Google, because those are production machines and have access to LDAP and who is allowed to run a command on a machine is defined by an LDAP group and you would need two of them (or more?) and there's already existing management website this can be shoe-horned into.
Your environment is unlikely to have all of that already, so you'll need to figure out equivalents for all those. But I think you're going to need a local service running as root and it's going to need to be able to tell the difference between distinct human users, if you want secure. Just typos is way easier.
I wrote something like that about 15 years ago for a financial institution.
For what we needed, we intentionally wanted both people to be at the same terminal (it was going to be used to give shell access to a specific unix account that ran a critical system).
That mean that we could implement it as a setuid (root) binary that required both users to authenticate. It had a config file that worked like sudoers, and defined a list of commands that could be called, how many people were needed to authenticate, and which unix groups they had to belong to.
Your environment is unlikely to have all of that already, so you'll need to figure out equivalents for all those. But I think you're going to need a local service running as root and it's going to need to be able to tell the difference between distinct human users, if you want secure. Just typos is way easier.