That problem is common to all shared-library approaches, which are found in Java, .NET, Rails and many other environments. Even in Delphi, you will be relying on a number of external libraries, such as most of the Windows .dlls, so it's not such a big step from what you have been doing so far.
Normally, when you move an applicaiton into production, you want to deploy it with a known set of libraries. With Rails, you can freeze the current rails version you are using for development (rake rails:freeze:gems), which copies all rails libraries into the vendor folder of the application.
If a change to a library breaks compatibility, there is usually a very good reason for the change (e.g. a security fix). A comprehensive suite of automated tests helps detect these kinds of breakages.
In practice, I have very very rarely seen this happen. Libraries are almost always more stable (in terms of versions) than your application and will generally have a longer shelf-life as well.
You definitely don't want to think about "sealing" ruby libraries. By the very nature of Ruby, there is a lot of code out there that achieves amazing things by redefining or extending existing classes or methods (e.g. the Enumerable mixin or the various acts_as_* plugins for Rails).
Depending on how you deploy your app, you can either choose a hosting environment that gives you control over the installed gems or - if you are deploying a stand-alone application - you can have a look at the various packaging methods (RubyScript2Exe and friends), which package up the required libraries into a single file.
In summary, I really wouldn't lose any sleep over it. I don't think it is as big an issue as you'd expect.
Max