Hmm. If you can not trust the local machine, then you are in trouble. It really does not matter how you secure the data - at some point you are holding an unsecured token which enables access to that secured data. What happens if someone gains access to your agent?

So - for me the actual question is not on how to secure the token, but on how to prevent mis-use if the token gets stolen. Maybe it's advisable to implement an intermediate client/server and handle the information exchange via there - limit the visible/modifyable data to the absolute required minimum and don't expose anything else. That still doesn't solve much if the actual transferred data is 'dangerous' (e.g. password hashes), but it's a first step to prevent data leakage.

Split up your tools into a client component and a server component? The (local) client just provides the interface to query/modify some data, the server checks the requests for validity / sanity and does the actual interaction with your database / LDAP. It also may apply restrictions on who is able to see what data. Users may even need to authenticate against the client with the server checking the credentials. Please do not distribute the usernames/password with each client. (And yes, someone has done this. Honeywell / Saia-Burgess got some embarassing press coverage for performing user/password authentication in a local Java-Applet for their heating plants.)