Systems like scrum are conventions that people have agreed upon in order to create a reasonable confidence in their (near) future expectations. A sprint effectively provides reasonable guarantee/confidence in what you can expect to see at the end of the sprint.
That being said, plans can always change. We can never exclude that the customer has a valid concern that warrants messing with the planned sprint. For example, your developers might need to urgently be called away on another mission that could not have been foreseen but still outranks the current development goal.
Technically, scrum does not prescribe this happening. It assumes that a sprint is set in stone and does not change. But reality can be very different. And that's perfectly okay, but it comes at the cost of acknowledging that this effects the planned sprint and therefore the (near) future expectations can no longer be reasonably guaranteed.
Personally, I leave this up to the person with the highest authority in this discussion. The sprint can be messed with if necessary, but not without accepting that the guarantees made during the sprint planning are effectively null and void.
One small exception: I would allow for minor things such as changing a color, if you haven't even started on that ticket in your sprint yet, or if the fix takes less time than explaining why you're not going to do it (in a figurative sense). There's no point bickering over really harmless things if their impact is negligible.
That being said, your situation might be different. For example, the person who is relying on your planned sprint might not be the same person who is now calling for the sprint to be messed with. That is a very different beast to tackle, because it first requires you to refer the latter person to the former.
Without approval, I would not let the sprint be messed with by outsiders. With approval, you can refer back to the earlier point that it must inherently mean that the sprint goals are null and void.
This is my take on how to approach development in general. I'm mentioning it because it helps explain the points I'm making in the next section.
A contract is not the way to go here, in my opinion. It is needlessly formal, and it is going to foster a defensive attitude. You cannot treat a sprint the same way that you would treat a fixed price contract (where you do indeed take this exact approach: sign for the requested work and never deviate from it).
What you're trying to do here is to waterfall your individual sprints, which is not only going against the original goal of doing scrum, it can also bite you in the ass when you fail to deliver a goal for whatever reason. A PO who is forced to sign a contract pretty much against their will, even if they agree to it in the first place, is likely to ask for damages upon non-delivery of the entire contract. Do you really want to roll those bones?
However, there may be contractual considerations between your company and the client company that supersede this. For example, if the client company is liable to pull the entire contract plug if you fail to either meet a sprint goal or fail to jump to their whims, that's a situation that's doomed to fail.
If, for whatever reason, your company is not in the position to enforce a reasonable limit on this behavior, then you might need to strongly enforce a communication format between your company and the client - but I would argue that at this stage the relationship has deteriorated into one of no trust and systems such as scrum or agile simply do not work in such an atmosphere. You'd almost inherently have to fall into a waterfall approach where every iteration is rigorously defined and agreed upon, to an almost legal degree, before you start working on it.
Overall, I would urge you to foster a cooperative spirit with your PO, explaining to them the consequences of messing with the sprint; and if they insist on doing so, that they must inherently consent to nullifying the current sprint goals (i.e. they will receive a subset, but not the full set, of goals that were set out).
If they don't agree to that, then you shouldn't agree to do anything that wasn't planned in the sprint.
If both options fail, and your company is not able to simply step away from this client and look for an actually scrum-friendly client, your last resort seems to be to end the scrum approach and opt for a waterfall approach instead.