If your server B has fuse and sshfs installed and both servers are permanent (fix ip, 24/7) your best choice is to user-mount the other server's directory and copy files over that channel.
On serverB:
$ mkdir $HOME/serverA
$ sshfs [email protected]:restricteddirectory serverA
from now, your scripts on serverB can copy files into $HOME/serverA. This is reasonably secure solution. Since the channel is set up manually, no password, no unprotected key-files can be stolen. Furthermore the possible attacker will be unable to escape from restricteddirectory on ServerA. All goals are reached. The backside is that you have to remount the directory every time (either) server reboots. In enterprise environment this might be a minor problem, and you can set up a script/cron to check the connection and send you a mail if the other side is unavailable (so you can log in and fix the problem).
If the server has dynamic IP or offline often this approach won't work. Using automated scripts for accessing serverA will require you to store your password or unprotected priv-key on serverA, therefore there is no way to prevent successful attacker of serverB to reach serverA with your privilege level. (However this absolutely doesn't mean that (s)he can "hack Server A". You are unprivileged user. But your account will be compromised for sure).
In fact, you might try to fiddle about screen and ssh-agent to avoid storing credentials, but you will face one of the problem before, if serverB reboots you have to login and fix things.
The only truly secure solution which comes into my mind in this case to use some intermediate storage. Set up an account at a third place (serverC), restrict access to serverA and serverB's IP address and you can proxy all data easily. At serverA your pull scripts will get the data. Because you never access serverA from serverB, your account cannot be hacked even if serverB silently compromised at root level.
