Security model

A hiloop sandbox runs untrusted, agent-driven code, so security claims here distinguish controls enforced outside the workload from features that have not shipped. Requests the deployment cannot enforce exactly are rejected at admission, never weakened into an apparently successful sandbox. Capabilities still landing are listed in what’s live today; nothing below depends on them.

Current guarantees

Control	Behavior today	Where it is enforced
Workload isolation	Every sandbox pod runs under gVisor (`runsc`), a user-space kernel between the workload and the host. A cluster admission policy refuses any sandbox that does not request gVisor or that requests host namespaces or host-path mounts; the namespace additionally enforces the Kubernetes `baseline` pod security standard.	Kubernetes API server and node runtime, outside the workload.
Edge authentication	Every API request is authenticated at the edge and stamped with the resolved organization, user, and scope; backend services accept only edge-stamped identity. Because those services cannot tell a stamped header from a forged one, an in-cluster network policy fences them so the edge cannot be bypassed by dialing a Service directly. That fence is unconditional on every deployment shape: a self-managed install must name the ingress allowed to reach the services and will not render until it does. Its strength is the CNI’s — see network policy enforcement.	Edge gateway and cluster network policy.
Organization scoping	All product records (sandboxes, snapshots, volumes, secrets, runs, telemetry) are organization-scoped. A sandbox-scoped credential is additionally lineage-confined: it can read its own sandbox and snapshot lineage and act only on itself, and cannot create, update, or delete sandboxes or touch siblings.	Control-plane authorization on every route.
No workload-visible platform credentials	The customer workload container receives no Kubernetes token, capture proof, Hiloop credential, or cloud credential. A projected, short-lived Pod-bound token is mounted only in the trusted capture sidecar; the cloud metadata endpoint is unreachable.	Pod rendering and namespace network policy.
Network access	Deployments with the complete closed-policy bundle let each sandbox select public internet, proof-bound model gateway only, or no external egress. Every profile retains DNS and the dedicated proof-authenticated capture path; other sandboxes, general cluster services, private ranges, and metadata remain denied. Before activation, non-public updates fail closed. See network access.	Sandbox profile labels, namespace NetworkPolicy, and proof authentication.
Secret storage	Registered secrets are write-only to callers and envelope-encrypted at rest; no API returns a value.	Control-plane storage.
Secret use by sandboxes	A deployment with the complete proof-bound release path may admit an exact granted binding and inject the current bearer credential in external Envoy. Without that boundary, create is refused. Copying a raw credential into the workload is not a supported fallback because workload code can read it.	Fail-closed admission plus live-Pod proof, exact grant/binding checks, mTLS, and external header injection.
Platform-managed model credentials	No supported sandbox model path exists today. The approved target keeps provider keys outside the workload: Envoy owns the data plane while a Hiloop control service validates workload proof, policy, and budget and selects the authorized credential. Direct provider access is not a supported fallback.	Target/GAP; the existing Rust body proxy is operator-only. See model gateway.
Telemetry redaction	Capture proxies scrub a narrow set of recognized credential patterns from captured HTTP bodies and allowlisted environment values by default. Managed sandbox capture also scrubs its telemetry copy of supervised stdio, argv, and local attributes. A local `hiloop run` may explicitly disable its generic scan; managed sandbox capture cannot. Exact supported OAuth token exchanges remain metadata-only either way. No header value other than `Content-Type` and `Content-Encoding` is captured. Direct OTLP and bulk ingest remain unsanitized. See redaction.	Capture processes only; defense in depth, not permission to put secrets in telemetry.

Network isolation

Creation starts at public; after the deployment activates the complete closed-policy bundle, the update API selects public, gateway_only, or none. Before activation, non-public updates return unsupported_capability. Enabled updates return only after the policy controller selects the exact live Pod. DNS and the proof-authenticated capture path remain available in every profile; all unlisted destinations are denied. Destination-level domain or CIDR lists are not part of the current API.

Network policy enforcement

Two different controls in this page rest on the same cluster property: the sandbox network floor above, and the fence that keeps in-cluster callers from reaching backend services directly and asserting an identity the edge never stamped. Both are Kubernetes NetworkPolicy, and NetworkPolicy only binds where the cluster’s CNI enforces it. A CNI without enforcement accepts every one of these objects and honours none of them, so both controls read as present and do nothing. Hosted deployments run with enforcement enabled. A self-managed install proves it rather than assuming it: a pre-install gate fences a target with a real NetworkPolicy, dials a port that policy denies, and refuses to install if the port keeps answering while the admitted port does. A policy still converging is given time to land, so only a denied port that answers throughout fails the install. A gate that cannot establish its own baseline connection, or that loses it mid-check, reports the run as inconclusive and still refuses — an unverified fence is not a passing one. See Kubernetes requirements.

Fail-closed admission

The create path refuses what it cannot enforce, with unsupported_capability naming the gap: secret bindings when proof-bound release is not configured, volume mounts today, plus the durable storage class on a deployment that has no storage class configured to back it. Activity capture has no create-time switch; the platform attaches its trusted capture process when that runtime path is available. This is the standing posture: an unavailable requested control is an explicit error, not a downgraded sandbox. Lifecycle transitions are held to their own contract rather than a capability gate. A stop is accepted from a sandbox that is ready, running or already stopped, and a start from one that is stopped or already running; anything else is refused by state rather than queued. A start that races an in-flight stop waits for the stop to finish, so a declared seal is never abandoned half-done.

Verify it yourself

From outside the workload, with an organization credential:

On a deployment without secret release, submit a create with --secret <name> and confirm it is refused with unsupported_capability before any sandbox exists.
Submit a --volume mount and confirm the same refusal shape.
Confirm no API route ever returns a stored secret value.

Self-managed operators can additionally inspect the workload namespace: the runsc admission policy, the baseline pod-security label, the deny-floor NetworkPolicy, the workload container’s absence of token mounts, and the capture sidecar’s dedicated projected proof are visible objects. See the threat model for what these controls do and do not cover.

​Current guarantees

​Network isolation

​Network policy enforcement

​Fail-closed admission

​Verify it yourself

Current guarantees

Network isolation

Network policy enforcement

Fail-closed admission

Verify it yourself