Tips & Tricks
Practical guidance for running Aegis agents in Hermes, OpenClaw, and similar runtimes.
Working with Hermes & OpenClaw
Practical tips for running an Aegis agent inside a conversational agent runtime like Hermes or OpenClaw. These runtimes give the agent a terminal, a .env, and a chat channel — which is everything you need to hand it credentials safely and load the Aegis skill.
Your agent only ever needs its low-privilege bot signer key plus RPC and (optionally) an Aegis API key — never your owner wallet key. The hard part is getting those secrets to the agent without pasting them into a chat log. The pattern below solves that with age, a small modern encryption tool.
Giving Your Aegis Env Vars to Your Agent Securely
Encrypt secrets to the agent's public key so the ciphertext is safe to paste into chat. Only the agent can decrypt it, and its private key never leaves its machine.
How it works
The agent generates an age keypair and shares only its public key (the age1… string). You encrypt each secret to that public key and paste the armored blob into chat. The agent decrypts it locally with its private key, appends it to .env, and reloads. The plaintext secret never travels over chat, and the private key never leaves the agent's box.
Agent side — one-time setup
Give this to your agent: "Set up age encryption so I can receive encrypted secrets over chat." It runs everything through its terminal tool — no special runtime config required.
1. Install age
terminal# macOS brew install age # Debian / Ubuntu sudo apt install age # or download a release: https://github.com/FiloSottile/age/releases age --version # verify2. Generate a keypair
terminalage-keygen -o ~/.config/age/identity.txt # Prints the PUBLIC key to stdout, e.g.: # created: 2026-07-15T10:00:00Z # public key: age1ql3z7hjy54pw3hyv...The identity file is written with
600permissions. It holds the private key — keep it on the agent's machine only.3. Share the public key
The agent posts its
age1…line into chat. That is the only thing it should ever share. Whoever is sending secrets encrypts to it.
Sender side — encrypt to the agent's public key
The -a (ASCII armor) flag is what makes the ciphertext paste-safe — without it you get binary garbage that a chat client will mangle.
# Encrypt a single secret to the agent's public key
echo "AEGIS_SIGNER_PRIVATE_KEY=0xabc123..." | age -r age1ql3z7hjy54pw3hyv... -a
# Or encrypt a whole .env file
age -r age1ql3z7hjy54pw3hyv... -a -o secrets.age .env
# Paste the armored output (or the contents of secrets.age) into chat.Agent side — decrypt, inject, reload
The agent decrypts the blob with its identity file, appends the value to its env, and reloads the running session. This is the loop you repeat every time you need to add a secret.
# Decrypt an armored blob saved to a file
age -d -i ~/.config/age/identity.txt < encrypted_file
# Decrypt straight into the agent's .env, then reload
age -d -i ~/.config/age/identity.txt < encrypted_file >> ~/.hermes/.env
# then /reload to load the new env vars into the running sessionIf your chat client strips trailing characters on long pastes (some do), base64-wrap the armored blob first and unwrap on the way in:
echo "<base64 blob>" | base64 -d | age -d -i ~/.config/age/identity.txt >> ~/.hermes/.envKey points
- The agent just needs age installed + a keypair generated — it does everything through its terminal tool, no special runtime config required.
- Only the public key (
age1…) ever goes over chat. The private key (identity.txt) stays local. -a(armor) is what makes the ciphertext paste-safe — without it you get binary garbage.- Decrypt → append to .env → reload is the loop to inject a new secret into the running agent.
- Base64-wrapping is optional but helps if your chat client mangles the armored format — some strip trailing characters on long pastes.