I'm no expert on security matters and am not familiar with what the current best practices are in such a matter, so there are probably better solutions than the one I'm about to explain.  Regardless, as a system architect, it only took me a few seconds to come up with one possible solution to your question:

While nothing should be allowed to connect in to the wallet box, processes on the wallet box can still reach out to other boxes.

A separate daemon can be written to run on the wallet box and reach out regularly (every second?) to a database held on some other box.  Entries in this database can indicate actions that should be taken on the hot wallet (procedure numbers to indicate which function to run, additional columns or tables to hold parameters).  The daemon can be written to validate the database entries against a set of sanity checks (size, frequency, destination, etc). It can then trigger an alert (pager, txt msg, phone call) to system administrators and refuse to process the request from the database when any transaction, or set of transactions, exceeds any sanity check.  System administrators can then determine if the attempted interaction with the hot wallet is legitimate and handle the situation as needed. If the private keys for the hot wallet are known to be kept offline in cold storage, the daemon can even shut down bitcoind and delete the local copy of wallet.dat when it detects any obvious sign of intrusion.