Question: is it safe that openclaw sandbox process env contains real credentials when openshell:resolve:env:* is used?

[nloke]

Question

We noticed that when deploying an AgentHarness with the openclaw backend, the real API key and Slack tokens are visible in the openclaw process environment (PID's /proc/\<pid\>/environ), even though openclaw.json uses openshell:resolve:env:* placeholders.

What we observed

openclaw.json correctly uses placeholders:

"apiKey": "openshell:resolve:env:OPENAI_API_KEY"
"botToken": "xoxb-OPENSHELL-RESOLVE-ENV-SLACK_BOT_TOKEN_PLATFORM"

But the sandbox process env has the real values:

OPENAI_API_KEY=sk-...        (real key)
SLACK_BOT_TOKEN_PLATFORM=xoxb-...   (real token)
SLACK_APP_TOKEN_PLATFORM=xapp-...   (real token)

Where this comes from

Tracing the code, BuildBootstrapJSON (in openclaw/bootstrap.go) resolves the real credentials from k8s secrets and returns them in an env map. OnAgentHarnessReady (in openclaw.go) then passes that env map directly to ExecSandbox when running both the config install and openclaw gateway run:

// openclaw.go L105, L120
code, stderr, err = b.ExecSandbox(..., installCmd, jsonBytes, env, 120)
code, stderr, err = b.ExecSandbox(..., gatewayCmd, nil, env, 90)

This means the process that openclaw runs in has the real credentials in its environment, accessible to any tool the LLM spawns (e.g. process.env in Node.js, shell commands, etc.).

The design question

Our understanding of the openshell:resolve:env:* security model is:

1. openclaw.json stores placeholders — real credentials never written to disk
2. The OpenShell proxy intercepts outbound requests from the sandbox
3. Proxy looks up the real credential from the attached sandbox provider in OpenShell's store
4. Proxy replaces the placeholder header with the real key before forwarding

If that model is correct, the sandbox process should never need the real credentials in its env — the proxy handles resolution exclusively from the provider store.

Is it intentional that ExecSandbox injects the real credentials into process env as well? Is there a threat model where this is considered safe, or is this a gap where the real credentials should be kept out of process env entirely and resolved only via the proxy?

Context

• kagent commit: 940c478
• Related: AgentHarness with openclaw backend fails all LLM calls — inference provider never attached to sandbox #1965 (inference provider not attached at sandbox creation)
• We are using openclaw v2026.5.4 with an OpenAI-compatible LiteLLM gateway

[nloke]

Additional findings

After digging deeper into the pod we can see the process and permission breakdown more clearly:

PID 1   root     openshell-sandbox   (proxy, listening on 10.200.0.1:3128)
PID 47  sandbox  openclaw            (agent/LLM process, UID 998)

/proc environ permissions:

-r-------- root    root    /proc/1/environ
-r-------- sandbox sandbox /proc/47/environ

PID 1 (openshell-sandbox, root) has no real credentials in its env — only OPENSHELL_SSH_HANDSHAKE_SECRET and OPENSHELL_K8S_SA_TOKEN_FILE. It presumably fetches credentials from the OpenShell provider store at resolution time.

PID 47 (openclaw, sandbox UID 998) has the real credentials in its env — OPENAI_API_KEY, SLACK_BOT_TOKEN_PLATFORM, SLACK_APP_TOKEN_PLATFORM all present in plaintext, injected via ExecSandbox in OnAgentHarnessReady.

Since /proc/47/environ is owned by the sandbox user, the openclaw process can read its own env freely — accessible to any tool the LLM spawns.

What we think the correct design should be

• Real credentials live only in the OpenShell provider store, accessible only to PID 1 (root)
• ExecSandbox passes no real credentials in the env map to the sandbox process
• openshell:resolve:env:* placeholders in openclaw.json are resolved exclusively by the root proxy at request time — never materialised in the sandbox user's env

This would mean the sandbox user (UID 998) only ever sees unresolved placeholders, and the actual credential substitution happens inside the root-owned proxy process — which is what the openshell:resolve:env:* naming implies.

Is this the intended direction, or is there a reason the real credentials need to be in the sandbox process env?

[nloke]

Caveat — may be a false alarm from our local patch

Worth noting that our findings above may be partially caused by our own fix in draft PR #1964 rather than a genuine upstream gap.

To get LLM calls working at all (see #1965), we added upsertInferenceProviderForHarness which calls UpsertInferenceProvider and attaches the inference provider (with {OPENAI_API_KEY: <real_key>}) to the sandbox via CreateSandboxRequest.spec.providers.

If OpenShell automatically injects attached provider credentials as env vars into the sandbox process (which is consistent with how the Slack provider attachment works), then OPENAI_API_KEY appearing in the sandbox process env could be a direct side-effect of our patch — not pre-existing upstream behaviour.

We have not verified whether OPENAI_API_KEY was already present in process env before our patch was applied. So the env exposure we observed could be:

1. Caused by our patch — OpenShell injects attached provider credentials into sandbox env, and we're the ones attaching the inference provider with the real key
2. Pre-existing — OnAgentHarnessReady passes the real key via ExecSandbox env independently of our change

Either way the design question stands, but we wanted to flag this so you can evaluate against a clean unpatched deployment rather than taking our observations at face value.

[nloke]

Update — clarifying the source of the env exposure

After tracing the code more carefully, we want to correct and clarify our earlier comment.

OPENAI_API_KEY in process env is pre-existing upstream code — not caused by our patch.

The injection happens in OnAgentHarnessReady (upstream openclaw.go):

1. BuildBootstrapJSON resolves the real API key from the k8s secret and puts it into an env map (bootstrap.go line 30-31):

env := map[string]string{
    apiKeyEnv: apiKey,  // real key materialised here — upstream code
}

2. That env map is passed directly to ExecSandbox when spawning openclaw gateway run, injecting the real key into the sandbox process env.

The code that does this is entirely upstream — our patch does not touch BuildBootstrapJSON or ExecSandbox.

What our patch (PR #1964) actually does is call UpsertInferenceProvider to register credentials in the OpenShell provider store via gRPC so the proxy will authorise outbound LLM calls. Nothing more.

Why the env injection was invisible before our patch: without an inference provider attached, the OpenShell proxy blocks outbound LLM calls entirely (Connection error) — so the real key was always in process env on upstream 940c478, it just never resulted in a successful LLM call. Our patch fixed the proxy authorisation, which made the pre-existing env exposure observable for the first time.

The question remains valid: is it intentional that the real LLM API key is materialised into the sandbox process env by ExecSandbox, given that the openshell:resolve:env:* placeholder pattern implies credential resolution should stay within the proxy/provider-store layer?