In principle, Remote VM Agent is not secure one. It listens on non-encrypted port and accepts connections no matter of origin. Said that, there are a few bits and pieces taken in consideration even with the system as it is:

All that the agent writes down is in one directory, .remotevm. Also, each different main class has separate directory. Newly created VM connects back to the agent on the loopback interface (localhost/127.0.0.1) The agent points to /usr/bin/java as an executable. That can be changed only by the agent's command line parameters, not remotely. Client paths are sent to the agent and stored at the agent's side. But, before being sent from the client, they are all relativised from perspective of current, client's directory. That way client's absolute paths are going to be sent to the agent only if they differ from current starting point. That means that if the client invoked remote VM from somewhere in the home directory, home directory itself won't be passed to the agent.

Possible Future Security Features

Here are some, nice to have, features that may be implemented in the future:

Reimplement the agent to use netty and SSL with certificates. That would be real boost of security as, then, the agent will have options to accept only connections that provide public keys that are specified in ~/.ssh (or any other configured) directory. The agent to timeout after certain amount of time of inactivity. That would help overall security when developers simply forget to switcht the agent off. Also, that is going to be default option.