One problem that I always come back to when I try to set up such restrictions if the lack of GPU access from a VM. A relatively recent standard for virtual GPUs should work on all major players, but both on Intel and Nvidia I've never gotten it to work without crashes or glitches on my hardware.
These days, Linux's containerization API seems mature enough to set usable limits. It's possible to escape containers through kernel exploits and misconfigurations (i.e. the "docker-in-docker" setups) but honestly I'm mostly trying to protect one of the million files yarn downloads for me to read my ~/.ssh directory.
I believe systemd-run should allow me to run many dev tools with proper sandboxing if I call it right, but I haven't bothered to read up on it yet. I'm also slightly annoyed at the lack of good tooling for setting up quick and dirty network namespaces. The tools I've seen seem to assume that whatever namespace I want to set up will be part of my permanent machine setup, with changes to system daemon config all over the place.
Another path to consider is switching to more hardware backed storage. I've put my SSH key in my TPM and no malware is ever going to exfiltrate the private key from there. I've thought up some theoretical solutions to the API access problem and the best I've been able to come up with has been a TPM-backed dom0 VM with the rest of the system in dom1, all other hardware forwarded through VT-d and friends, with access to the dom0 VM only through some kind of interactive protocol, possibly with some kind of network-based permission prompt before key access (i.e. click allow on your phone for the secret VM to share the product key). It would probably work, but I have no illusions about someone making something like that that's going to be usable on a normal user desktop, let alone a mobile device (with all of its power management challenges).