Skip to content

Security: nestm-dev/capsuleos

Security

SECURITY.md

Security policy

Supported versions

@nestm/capsuleos is prerelease software. Security fixes are provided on the latest published alpha only.

Reporting a vulnerability

Please report vulnerabilities privately through GitHub Security Advisories for nestm-dev/capsuleos. Do not open a public issue for a suspected vulnerability.

Include affected versions, a minimal reproduction, impact, and any suggested mitigation.

Security boundaries

This package does not discover credentials, read provider credentials from environment variables, or own provider SDK clients. Applications must construct providers with explicit credentials and remain responsible for credential rotation, egress policy, image provenance, sandbox resource limits, and the sensitivity of inputs and outputs.

The root module only creates a Capsule facade when given a provider map. It never closes providers. A prebuilt Capsule is also external-owned and is never closed by Nest.

Harness boundary

@nestm/capsuleos/ai-sdk-harness exposes the upstream CapsuleOS Harness adapter without changing its lifecycle. Its default auto policy prefers a loopback-only process tunnel when a provider advertises process.stdin; otherwise it requires stable provider ingress. Daytona, Docker, Apple Container, AWS Lambda MicroVMs, and the Firecracker/libkrun previews can use that tunnel. Vercel uses native ingress. A provider with neither capability fails preflight before a binding is reserved or a sandbox is allocated.

The process tunnel transports base64-line-framed bridge bytes over the provider's process channel. Base64 is encoding, not encryption: the local controller and provider process channel remain trust boundaries. The listener is restricted to loopback, and its listener and helpers are closed before the sandbox is stopped or destroyed. Provider ingress must still be treated as public unless the selected provider proves authentication. Explicit expiring Daytona provider ingress is experimental and must be enabled separately; normal automatic selection uses its process tunnel.

Signed endpoint URLs and bridge credentials must not be persisted, logged, traced, or placed in queue payloads. Binding stores contain only resource metadata. The application owns the binding store and lease manager, including closing an application-created SQLite backend. Bootstrap callbacks and external tool callbacks must be retry-safe.

Harness registration performs no allocation. Session cleanup, bridge endpoint revocation, stop versus destroy decisions, and continuation-state persistence remain responsibilities of the upstream Harness adapter and the application runner.

There aren't any published security advisories