Overall, In order to have these button happen without a sign in, you would need to include 2 types of authentication, that are build into the button.
Door 1:
You would need a Ticket AND a Token.
The ticket can have an expiration date/time of 12 hours, unless you want to set a shorter or longer window for the button to work in the email. Keep in mind that if you make it longer, anybody with that token and ticket (that is in the URL) can do basically anything with your app. So its not really secure, if somebody wanted to be malicious.
Door 2:
Have an "Open to the Internet" app, that allows people to edit records on the 'Accept/Decline' table in question. You would then only need to provide an app token in the button, and have a bit more security to your data. But, again, anybody that gets that url can basically get access to your app and home pages. So again, its not a very secure option.
Door 3:
Use a portal Add-on, where the person has a specific username & password (these would not count as QB users, and you could have 500 without paying). Then they would have access to the records they need to approve, and you can control what they see/do more without compromising your app security.
Door 4: (which would take a power user to pull off successfully),
Is build a separate app (that is open to the internet), with a sync table of all the data from your real table in the main app, then the button that goes out, will send them to that one table app, that has the approve/decline button. You could even just sync the key data that they need. Then make a few webhooks to (1) trigger the email and (2) update the main app when the button is accepted or decline. This give you a layer of protection, but again, requires quite a bit of set up.
Which door do you like?
