[sandbox] Support custom credential injection rules in proxy-config.json

[mogul]

Enhancement description

Docker Sandboxes provides excellent proxy-managed authentication for built-in AI providers (OpenAI, Anthropic, Google, etc.). The proxy intercepts requests and injects credentials from host environment variables, keeping API keys out of the sandbox filesystem. This is a great security model.

The problem: Many organizations use AI services that aren't in the built-in provider list:

• Self-hosted or on-premises AI services
• Enterprise AI gateways with custom domains
• Government or regulated industry AI endpoints (FedRAMP-authorized services, etc.)
• Regional or alternative AI providers

Currently, these users must either:

1. Store API keys in files within the sandbox workspace — defeating the security benefit of proxy-managed auth
2. Run a separate forwarding proxy on the host — adds complexity
3. Wait for Docker to add their specific provider — doesn't scale

Request: Allow users to configure custom credential injection rules in proxy-config.json, enabling the same secure proxy-managed authentication for any API endpoint.

Sample UX

Add a credentials section to the existing ~/.sandboxd/proxy-config.json:

{
  "policy": {
    "default": "allow"
  },
  "network": {
    "allowedDomains": ["..."]
  },
  "credentials": [
    {
      "domain": "ai.example.com",
      "envVar": "EXAMPLE_AI_API_KEY",
      "header": "Authorization",
      "format": "Bearer ${value}"
    },
    {
      "domain": "*.internal.company.com",
      "envVar": "INTERNAL_API_KEY",
      "header": "x-api-key",
      "format": "${value}"
    }
  ]
}

Field	Description	Example
domain	Domain pattern (same syntax as allowedDomains)	api.example.com, *.ai.company.com
envVar	Host environment variable containing the credential	MY_API_KEY
header	HTTP header name to inject	Authorization, x-api-key
format	Header value format (${value} replaced with env var)	Bearer ${value}

Behavior:

• Rules evaluated in order; first matching domain wins
• If envVar is not set on the host, the rule is skipped
• Domain matching uses the same pattern syntax as existing allowedDomains

Diagram

┌─────────────────────────────────────────────────────────────────────────┐
│ HOST                                                                    │
│                                                                         │
│  ~/.sandboxd/proxy-config.json         Environment Variables            │
│  ┌─────────────────────────────┐       ┌─────────────────────────────┐  │
│  │ "credentials": [            │       │ EXAMPLE_AI_API_KEY=sk-xxx   │  │
│  │   { "domain": "ai.ex.com",  │       │ INTERNAL_API_KEY=key-yyy    │  │
│  │     "envVar": "EXAMPLE_..." │       └─────────────────────────────┘  │
│  │   }                         │                    │                   │
│  │ ]                           │                    │                   │
│  └─────────────────────────────┘                    │                   │
│               │                                     │                   │
│               ▼                                     ▼                   │
│  ┌──────────────────────────────────────────────────────────────────┐   │
│  │                     SANDBOX PROXY                                │   │
│  │  1. Match request domain against credentials[].domain            │   │
│  │  2. Look up envVar on host                                       │   │
│  │  3. Inject header with formatted value                           │   │
│  └──────────────────────────────────────────────────────────────────┘   │
│                                    │                                    │
└────────────────────────────────────│────────────────────────────────────┘
                                     │
                    ┌────────────────▼────────────────┐
                    │          SANDBOX VM             │
                    │                                 │
                    │  Request to ai.example.com      │
                    │  (no credentials in sandbox)    │
                    │                                 │
                    └─────────────────────────────────┘

Use cases: Enterprise AI gateways, government/regulated AI endpoints, self-hosted models (vLLM, Ollama, TGI), regional providers, dev/test environments.

Security: Credentials remain on host, never in sandbox. Same trust model as built-in providers.

[BaltsevichDanil]

+1 for this. Ran into this exact issue trying to use DeepSeek (api.deepseek.com) in a shell sandbox — DEEPSEEK_API_KEY is set on the host but the proxy doesn't inject it, so the key has to be stored inside the VM which defeats the whole security model.
The proposed credentials config would solve this perfectly. Would be great to see DeepSeek added to the built-in list as well, since it's becoming quite popular.

[mogul]

A similar issue has now been filed against sbx over here.

Since I didn't see any movement here I started looking around to see if anyone else has done work on this. Jentic's self-hosted version seems like it bears investigation as an option, repository here. Added investigation of that option to my infinite to-do list.

[mogul]

There another issue about this with more traction.