Keep credentials out of sandbox commands and logs

Start from a minimal credential set

A sandbox task should receive only the credentials required for its approved work. Lupin's hosted Boat adapter creates user sandboxes with noEnv true, then supplies explicit ownership metadata. That avoids inheriting the operator's broader environment by default. It does not prevent your application from introducing secrets later through uploaded files, package configuration or command strings. List the external services the task actually needs and choose narrow, short-lived credentials where the service supports them. Do not copy the API service's provider keys or an entire developer environment into the guest for convenience.

Keep control-plane credentials in the caller

The Lupin API key authenticates container creation, commands, files and lifecycle requests. It generally belongs in the trusted caller making those requests, not inside the workload being controlled. A key with container permissions can manage resources according to its scope, while the guest process needs only its own application authority. A bootstrap key cannot allocate paid compute or upgrade its own permissions. Human verification and billing readiness remain prerequisites outside the sandbox. Separating these roles makes it easier to rotate a workload credential without handing the guest broader workspace control.

Avoid command-string and output leakage

Commands and their history can preserve the text you submit. Passing a password directly in a command can therefore expose it even if the program never prints the password. Verbose HTTP clients and package managers can also echo authorization information or private registry URLs. Prefer approved secret-injection mechanisms available to your actual environment, and verify their scope instead of assuming every provider feature is exposed through Lupin. Do not run broad environment dumps as routine diagnosis. Keep stdout, stderr and retained excerpts limited to the evidence needed to understand the task's success or failure.

const access = await lupin.containers.shell(containerId);
// Deliver access.shell_url only to the authorized operator.
// Do not log the access object.

Protect desktop-shell URLs like bearer tokens

The shell action returns a temporary credential-bearing desktop URL for a running container. It is minted on demand rather than included in ordinary listings. Deliver it privately to the authorized operator and keep it out of analytics, shared transcripts and support screenshots. Start or resume the resource before requesting it; a stopped container receives container_not_running. Closing a local view is not a substitute for stopping the sandbox. An operator with desktop access may see files and processes that the task created, so the handoff audience should match the sensitivity of the workload's data.

Minimize retention after completion

Export the necessary artifact and a sanitized verification record, then remove task-specific credentials according to the relevant service's policy and stop idle runtime. Avoid claiming that stopping deletes every file or revokes every external credential: the current API exposes stop and resume, not a general deletion or secret-revocation contract. Likewise, public port exposure needs application authentication independent of the control API. When reporting completion, describe the work and verified cleanup state without copying tokens or shell links. The secure deliverable is the result plus a clear account of where sensitive authority was introduced and how its use ended.

Sources & verification

Reviewed against the current Lupin route, provider adapter and shared input contracts, plus the linked official references. Examples were not run against live services.

• docs.boat.dev · environments · secrets ↗Checked 2026-11-05
• docs.boat.dev · environments · access ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.