Todd A. Jacobs gave a good example of how to handle this within a Scrum context, but this isn't entirely a question about Scrum. The broader question is if you can trust the vendor or not, no matter if they are using Scrum or something else.
Trust + time + inspection
I'll formulate my answer by using an analogy.
Let's say you go visit some third world country as a tourist. You land at the airport and you need to go to your hotel. You exit the airport and you see a bunch of taxis waiting in front of the airport. You get into one and they will drive you to the hotel at the right price and using the correct route, right? Well... no. If you do that you will probably be ripped off. You will pay more for the ride, you will probably go on the longest and slowest route, the taxi driver might not even start the meter but tell you the price once you reach the hotel (assuming they don't take you to the nearest forest and rob you of all your money).
So, getting into the taxi, first starts with trust. Do you trust getting into the car with that driver? If you are naive you will probably get into the car. If you know how those people operate you will not. But you still need a taxi to get you to the hotel. You need a taxi you can trust more than those guys sitting in front of the airport waiting to "catch a big fish". You might, for example, arrange for transportation with a trusted company before arriving at the airport, or there might be some self-service terminals in the airport that you can order a taxi with (and they give you the car identifier in which to get in), there might be a list of trusted companies that are listed at the airport and you can call their dispatcher and ask for a taxi, etc.
Getting back to the software vendor, this implies finding a trusted vendor to begin with. So you must perform some due diligence and select a vendor with reputation, experience, recommendations, etc, not just pick a vendor from the street.
But even if I get into a more trusted taxi or find a more trusted software vendor, in the context of this question, I can still get screwed on the way to town. Here is where time and inspection come in. You start on your drive and you are careful at what is happening. Did the driver start the meter? Is the price the same as the one written on the door of the taxi or the one you agreed upon when ordering the taxi? Is the car going in the general direction it should be going? You give it some time and you look at what's happening. If you want to stare at the scenery instead, then that's your problem.
Going back to the software vendor now, you start the project and monitor what's going on. How is the communication with the vendor? How is their progress? Are they delivering what they said when they said? What's the quality of the product that they are delivering? Do they ask for questions? Are they transparent with their work? You need to be involved. You can't step out of the picture and stare at the scenery instead. More so with Scrum, where the client must be involved in the project, not like in something like Waterfall where you can throw some requirements over the fence, disappear, then come back at the end and complain that they built the wrong thing. You have to be involved, monitor what's going on, and collaborate with the vendor. Here is a counter example: what if the Scrum team isn't lazy, but very fast? Is that automatically better? It's not, because they could be producing garbage code very fast. So you have to inspect the deliveries and progress and see if it matches your expectations. Is the product evolving how you want it? Is it where it's supposed to be? Is it doing what you need and of the proper quality? If it isn't, then you decide what to do (i.e. inspect and adapt).
Going back to the taxi ride, if you notice after a while that something isn't right, you decide what to do. Keep going or tell the driver to stop and get out. If you are in town, you might decide to get out of the car. If you are in the middle of a corn field then you might decide to continue even if you know you will pay more money than supposed to. The same with the software vendor: if you see something not right, you decide what to do. Continue, change something, stop the project entirely, increase collaboration, reprioritize stuff, etc. But in order to do this, you need to understand what's going on inside the project, you need some expertise in managing software projects to recognize when you are not where you want to be. Otherwise you just have to trust that the vendor isn't ripping you off, or in the case of the taxi analogy, trust that the driver will do an honest job and get you to the hotel on the right route and at the right price.
