[DGX Spark][Security] managed llama.cpp bridge exposes port 8081 on host loopback without API key enforcement

[hulynn]

Description

The managed llama.cpp private bridge process exposes the llama.cpp inference endpoint on host loopback (127.0.0.1:8081) without enforcing the API key configured in the container. Any local process on the host can query the model catalog and potentially invoke inference without authentication.

The nemoclaw-llama-cpp container has /run/secrets/llama-cpp-api-key mounted and llama-server is started with --api-key-file. However, the node bridge process (docker-llama-cpp-private-bridge-process.js) that proxies 127.0.0.1:8081 to the container does not enforce the key at the loopback level. The managed inference route through the OpenShell gateway at inference.local uses proper authentication; only the direct loopback port bypasses auth.

Platform scope: Reproduced on DGX Spark only; other platforms not tested (managed llama.cpp only supported on DGX Spark).
Regression: Unknown — managed llama.cpp is new in v0.0.110.
OpenShell issue: No.

Environment

Device:        DGX Spark (GB10, aarch64)
OS:            Ubuntu 24.04.4 LTS
Architecture:  aarch64
Node.js:       v22.23.1
npm:           10.9.8
Docker:        29.2.1
OpenShell CLI: 0.0.101
NemoClaw:      v0.0.110
OpenClaw:      v2026.7.1

Steps to Reproduce

1. Install NemoClaw with managed llama.cpp Muse Glimmer 30B (interactive menu, recommended option)
2. Confirm sandbox is Ready: nemoclaw {sandbox} status
3. From the host (SSH session, outside sandbox), make an unauthenticated HTTP request to the loopback endpoint:

curl -s http://127.0.0.1:8081/v1/models

4. Observe HTTP 200 with full model catalog (expected: HTTP 401)
5. Repeat with a known-invalid credential in the Authorization header:

curl -s -H "Authorization: Bearer <invalid>" http://127.0.0.1:8081/v1/models

6. Observe HTTP 200 with full model catalog (expected: HTTP 401)

Expected Result

HTTP 401 for unauthenticated or invalid-credential requests to 127.0.0.1:8081. The API key configured in the container should be enforced at the bridge layer.

Actual Result

Both requests return HTTP 200 with the full model catalog.

Technical detail: /run/secrets/llama-cpp-api-key is mounted in nemoclaw-llama-cpp container and llama-server starts with --api-key-file (key configured correctly inside container). The docker-llama-cpp-private-bridge-process.js node process proxies 127.0.0.1:8081 → container internal network but does not forward or enforce API key authentication. Any host-local process can bypass auth via direct loopback access.

Logs

$ curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8081/v1/models
200

$ curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Bearer <invalid>" http://127.0.0.1:8081/v1/models
200

[prekshivyas]

Post-merge DGX Spark verification

Validated the merged fix from the official repository's current main at 7689b4a3831e4abc7a992c54d84c48ee60368dac. PR #9670's merge commit, 289d5a5a007c33c0b8530e0f892cc7501357608b, is an ancestor of that revision.

Environment

• NVIDIA GB10, ARM64/aarch64
• NVIDIA driver 580.159.03
• Docker 29.2.1
• OpenShell 0.0.101
• OpenClaw v2026.7.1
• Preflight: 20 vCPU, 121.7 GiB container resources, 124610 MB NVIDIA GPU memory, 16383 MB swap
• Managed provider/model: llama-cpp-local / muse-glimmer

Current-main automated checks

npm run build:cli
PASS

npx vitest run src/lib/onboard/runtime-provider/docker-llama-cpp-private-bridge.test.ts src/lib/onboard/runtime-provider/docker-llama-cpp-managed-lifecycle.test.ts
PASS: 2 files, 74 tests

npm run typecheck:cli
PASS

npm run checks:repository
PASS

The focused lifecycle suite includes replacement of a legacy pre-authentication bridge during resume.

Live managed bridge checks

Against http://127.0.0.1:8081 on the Spark host:

Request	Result
GET /v1/models, no Authorization	401
GET /v1/models, invalid bearer	401
GET /v1/models, duplicate Authorization headers	401
exact unauthenticated GET /health	200
unauthenticated GET /health?details=1	401
unauthenticated POST /health	401
GET /v1/models, valid managed bearer	200
authenticated host chat completion	200, generated output returned

The credential was read only from the managed read-only secret mount and was never printed or logged. The bridge process used --auth-mode api-key-fd3; no credential appeared in its argv or environment.

Supported sandbox route

From a Ready OpenShell sandbox (e2e-9584-main-spark):

GET  https://inference.local/v1/models           -> 200, one model
POST https://inference.local/v1/chat/completions -> 200, non-empty generated completion

nemoclaw ... status reported inference healthy, route reachable, managed llama.cpp running/ready, and provider/model llama-cpp-local / muse-glimmer. /app/llama-server was also observed as an active GPU compute process.

Lifecycle recovery

Current-main status detected and replaced a stale OpenShell Docker gateway TLS path. A stale locally registered sandbox that was already absent from OpenShell was removed with the supported destroy flow while preserving the gateway; onboarding then reused the pinned llama.cpp image, established the authenticated bridge, and reached Ready state. The image digest was sha256:6b0bf4974521b2c16a498c7dd0715f4eb077725f1483e0ee0f617679005b1e1f.

No remaining product blocker was observed in this post-merge verification.