Corey, the tension here is that Vanta wants you to apply a control to prevent changes going into production without adequate approval. The idea is that there are risks of supply chain poisoning (by adversaries or interns, it makes no difference in effect) as well as breaking applications (loss of availability).
From an auditor perspective, audit trails are detective controls and not very compelling by themselves - you can prove who did what, but only after the damage has occurred. A preventative control - preferably technical - is better. This is where the PR check comes in. If you are pushing things to Staging automatically, then I recommend removing those repos out of scope if you are able. This would quiet Vanta down and you would just tell the auditor "we only apply this control to Production repos/environments". This is not hard for an auditor to swallow.
That leaves the issue, I believe, where Vanta is getting hung up on a person not being assigned as the reviewer. You make it sound like there is still someone who has to manually push the PR - I assume they are also not the Dev who made the changes, right? I would never recommend changing your processes to shoehorn them into an out-of-the-box SOC 2. In this case, you may need to deactivate the automated test and replace it with a Document test. That Document should be tied to the same control. For the evidence to upload to this test, the Git history showing that a manual merge was done will be sufficient for an auditor. Also add a Document test for any supporting controls such whatever mechanism would prohibit a person from getting their own changes pushed to Prod. This is a different control, but having that evidence handy when looking at this control can make the auditor ask less questions.
Bottom line - I recommend scoping out any staging assets if you are able, deactivating the automatic test in Vanta, and adding a Document test to that control using the Git history as the evidence.
.png)