Injecting secure api keys in openshell

[ddeaguilar]

Hi. I saw that when following the Telegram onboarding the bot token is replaced inside of the sandbox environment with openshell:resolve:env:TELEGRAM_BOT_TOKEN. This way OpenClaw won't ever see the credentials and when making egress requests that string will be replaced with the real value, known by the openshell environment.

I was wondering if I can achieve the same behavior for generic api keys/tokens?

[ericksoa]

Hi @ddeaguilar — great question! Yes, the openshell:resolve:env: pattern is a general-purpose mechanism and works for any credential, not just the ones NemoClaw onboards by default.

How it works under the hood: placeholders like openshell:resolve:env:MY_TOKEN are static strings that get baked into sandbox config. The actual secret never enters the container — OpenShell's L7 gateway proxy rewrites the placeholder with the real value at egress time.

To use it with your own API key:

1. Register a provider on the host with the generic type:

   export MY_CUSTOM_KEY="sk-actual-secret-value"
   openshell provider create \
     --name my-service \
     --type generic \
     --credential MY_CUSTOM_KEY

   This stores the credential in OpenShell's gateway credential store. The env var is read once at registration time — it doesn't need to stay exported.

2. Use the placeholder wherever you need the key inside the sandbox:

   openshell:resolve:env:MY_CUSTOM_KEY
   

   When the sandbox makes an outbound HTTP request containing this string, the gateway proxy replaces it with the actual value before forwarding.

3. Add a network policy to allow egress to your API endpoint. You can either add a custom policy YAML to the blueprint or use one of the existing presets. Without a matching network policy, the request will be blocked regardless of whether the credential resolves.

Hope that helps — let us know if you run into anything!

[ddeaguilar]

Thanks, it is working! I followed the commands for creating the provider and I could see a new provider when listing the available ones. However later it wasn't being picked up by my environment, for example the openshell term command shows the providers in a section and my new provider did not appear.

I managed to consistently make it work by first doing the nemoclaw installation and then deleting and recreating its sandbox. This way I can launch the openshell command with my custom providers.
One caveat is that I need to get the image for the sandbox NAME:TAG

$ docker images | grep sandbox-from
$ openshell sandbox create --from openshell/sandbox-from:<timestamp> --provider MY_PROVIDER_1 --provider MY_PROVIDER_N my-assistant
$ openshell inference set --provider nvidia-nim --model nvidia/nemotron-3-super-120b-a12b

As for the output of the providers section inside of $ openshell term they sometimes appear and sometimes don't, but it works regardless.

[Innova9-Barizon]

That's great information. Now, is there a way for me to ask for the credentials when doing the onboarding process? Something like: Enter the URL endpoint; user id; password, so then the credentials stays stored and being used by the services across the board?

I'm not talking about OAuth or anything, just basic auth on a simple REST call. Then we can get fancy, but for now, would be awesome having this simple steps...

Anything on that?