Isolate model and telemetry credentials from sandboxed agents

[eshulman2]

Problem

Forge correctly keeps Jira and GitHub mutations in its trusted host integration layer, but implementation containers still receive reusable model credentials and, when enabled, observability credentials through environment variables or mounted Google application credentials.

A compromised agent can read and exfiltrate any bearer credential visible in its environment, filesystem, process arguments, or outbound traffic. Shortening token lifetime helps but is not equivalent to credential isolation.

Scope

This issue covers credentials required inside code-execution sandboxes:

• direct Anthropic
• Google GenAI
• Vertex AI Gemini and Anthropic
• Langfuse/OTel credentials when container-side emission is enabled

It does not move Jira or GitHub writes into the sandbox. Those remain in Forge's trusted integration layer.

Proposed phased solution

Phase 1: inventory and compatibility policy

• enumerate credentials exposed by each model/telemetry backend
• record only the credential delivery mode in redacted execution evidence
• define a credential_free|required|compatibility deployment policy

Phase 2: model mediation

• evaluate OpenShell providers and a Forge-compatible inference gateway
• keep real provider/cloud credentials outside the agent process
• enforce allowed connection, model, project/location, execution identity, and token/cost limits
• bind access to one sandbox execution and revoke it on completion/cancellation

Phase 3: telemetry

• prefer host-side trace emission from structured execution results
• otherwise proxy telemetry so secret keys do not enter the sandbox

Acceptance criteria

• A threat-model document lists every model/telemetry credential visible to each sandbox backend.
• Credential-free mode exposes no reusable credential values through environment, filesystem, process arguments, logs, or outputs.
• Every supported model backend has a tested mediated path or fails clearly in credential-free mode.
• Access is limited to the configured model connection and one execution.
• Completion, timeout, and cancellation revoke execution access.
• Jira and GitHub mutations remain outside the sandbox.
• Tests actively attempt credential discovery and exfiltration from inside the sandbox.
• Compatibility mode is explicit, documented as lower assurance, and never silently selected.

Related work

• Make sandbox runner pluggable with different execution drivers #30 / PR Make sandbox runner pluggable with Kubernetes driver support #243: pluggable execution drivers
• Spike OpenShell integration and select the correct Forge boundary #262: OpenShell integration spike
• Define sandbox driver capabilities and execution requirements #265: driver capability contract

Estimate

AI-assisted: estimate after #262. A single-backend proof of concept is likely several days; complete backend coverage remains a multi-week effort.

[cgwalters]

Well, we're also moving in the direction of https://github.com/NVIDIA/OpenShell/

[eshulman2]

Ack thanks for the info @cgwalters, does it also work on K8s? we are planning on moving our non-dev container runtime to be K8s/OCP