Plenty of other people have said "nothing" in response to the first question on "what prevents.." and it's true; ultimately nothing really defeats someone absolutely determined.
You also asked for strategies that can counter this; tj1000 touched on it, and I thought I'd toss a similar idea into the fray, based on work I used to do with credit card terminals.
Way back when I was a junior dev, I was handed a task that was deemed too hard to be worth solving by the pro devs (I guess it kinda shows what I was paid); we had thousands of credit card terminals that called in over an old pre-isdn link, did some auth, recorded a transaction, got an approve or decline from the server and onto the next transaction. The cute part is there was never another message followup from the terminal if the transaction was voided after we'd approved it (this was in the days of signatures, before user identity was pre-authed by a chip and pin), but there didn't need to be
These transactions were protected and confirmed by what was termed a MAC - message authentication code. Built into the hardware of the terminal was a hash key, unique per terminal, by the manufacturer. The manufacturer would share with us what the hashing key was, and when the terminal appeared presenting its unqiue ID we could look up the hash key. The message bytes the terminal formed would be hashed by the terminal, with half of the previous or initial hash being appended to the message. The other half would be used to update the hash key used for teh next message. At the server side, we'd carry out the same hashing to know if the message had been tampered with, and come to the same hash result, we'd also know to roll the hash key on with the same half residue we had, but we'd keep track of the previous hashkey too. The next time a message came in, one of two things was the case. If the previous transaction had succeeded and was to be accumulated into the daily totals, the terminal would use its new rolled hash key to hash the latest message. If the previous transaction was rolled back (user canceled, bad signature etc) the terminal would re0used the previous hash key. By hashing the message with the latest rolled key and finding no match, but hashing with the previous key and finding a match, we knew the fate of the previous transaction was fail, and we'd remove it from the daily totals.
Hash keys would occasionally go out of sync; when this happened, neither of our stored keys would produce a matching hash for the message. There's one more key to try - the initial key (the supervisor users could reset the key to initial, and some users seemed to do this upon any problem, believing it to be something like a reboot - seldom the case and caused more problems than it solved but..).
If the initial key worked out, we couldn't say for sure what happened to the previous transaction but we usually accumulated them (charged people's accounts) based on the theory that people would complain if they weren't refunded when due but not if they were refunded something they'd bought..
if the initial key didn't work out, then the terminal effectively became useless, as the key rolling sync loss means no more messages can work. We didn't have the authority to tell the terminal to reset its key itself, but we could put a message on the display imploring the user to do so
Long story short, you don't have to use the same token, if you're concerned that tokens will be captured and replayed as a stored password alternative. Others have pointed to options of making tokens expire after a time; this method is essentially token expiry after every request (similar to another mention about appending a sequential number to a token), with a known, internal way of calculating a new token on each side that has to be performed in step.
If you're interested in the boring details of the way the credit card world does it in the UK, look up APACS 70 Standard Book 2 and Book 5. These aren't freely available, alas - you have to be a member to receive a copy of new publications, but you might find the content of old versions of them floating around the web