You can't eliminate your risk 100% and still have a functional usable interface, but you can drastically limit your risk.  If you put sanity checks into the daemon that runs on the box that does the polling, you can limit the size of any single transaction, you can limit the total amount of BTC that are transferred out over any time range, you can require authorization for certain transactions, and as I said earlier you can immediately shut down bitcoind, and the polling daemon as well as delete the wallet.dat in the event of anything that is identified as a theft attempt.  Without access to the code in this daemon, a hacker can't know what limits exist or what triggers will result in the system administrators being alerted to his efforts.  If the hacker unknowingly attempts a few really large transfers he will be stopped in his tracks.  If a hacker is more patient, he might be able to size his transactions to match the typical transaction of the service and keep the total number of transactions in line with typical traffic.  This might allow the hacker to get away with a few coins, but it will slow them way down limiting your exposure and allowing you time to identify the breach and respond.  I suspect that most users of most services would be willing to wait on human authorization and manual transfer of any large transaction if it means keeping their money safe in the first place.