Scrum is based on an empirical process control system. It assumes that not everything is known and that knowledge will emerge over time. Trying to specify every acceptance criteria in exact detail may not be possible and may take way more time than needed.
It's not possible to know all acceptance criteria in advance.
Instead, Scrum explains that the Development Team has continuous contact with the Product Owner or Customer to receive feedback. Additional Acceptance Criteria and adjustments to previously written acceptance criteria can emerge during the sprint as part of over-the shoulder-reviews, short demos, proof-of-concepts early in the sprint or even wireframes or paper prototypes. The development team can accept these additional and adjusted acceptance criteria and work them into the increment immediately, or, if the work would be major or endanger the Sprint Goal, the Product Owner can choose to put the additional work on the Product Backlog for a future sprint.
Another opportunity to inspect the Increment happens at the Sprint Review. The Customer can inspect the Increment and provide feedback in the form of new and adjusted Product Backlog Items.
The aim of Scrum isn't to deliver everything first-time-right. It's to deliver things quickly and provide opportunities for feedback. This feedback will allow everyone to further refine the product and mold it into the product that is truly needed, not the one we had described on paper.
Who is ultimately responsible?
The Product Owner remains responsible for defining the What and the Why. They remain accountable for the functional acceptance criteria and the required non-functional characteristics of the product.
The Development Team remains responsible for defining the How and the Quality. They remain accountable for the technical acceptance criteria and to turn the non-functional characteristics of the product into technical solutions that meet these characteristics.
The Scrum Master has no accountability on content, only on the process. Therefore they play no part in this. Unless the process to get the requirements and to receive feedback is broken in your organisation. If that is the case, the Scrum Master should help remedy this situation.
Dealing with the impact on estimates
This question often surfaces, but how to deal with our estimates? If we accept that we can't know everything all the time, we should also accept our estimates will be less accurate.
Interestingly, if we tend to find the same number of unknown acceptance criteria in every sprint, then their impact will become evident through a lower velocity without ever having to adjust the way we estimate.