Threat model - hiloop

Read the security model first. The table below describes what is deployed today, not a future design, and names the residual risk of each row.

Threats and coverage

Threat	Current control	Residual risk
Untrusted sandbox code attacks the host kernel.	Every sandbox pod runs under gVisor, and cluster admission refuses non-gVisor sandboxes, host namespaces, and host-path mounts. The `baseline` pod security standard applies as defense in depth.	gVisor narrows, but does not eliminate, kernel attack surface; keeping nodes and gVisor patched is the operator’s responsibility.
A sandbox reaches internal infrastructure or another organization’s workload.	The namespace network floor denies other pods, all cluster services except the dedicated capture listener, and private address ranges. The workload has no proof for that listener, so its application layer rejects the workload.	The floor is namespace-wide, not per-sandbox, and depends on the CNI enforcing NetworkPolicy; verify enforcement on self-managed clusters.
A sandbox harvests platform or cloud credentials.	The workload container receives no service-account token, capture proof, Hiloop credential, or cloud credential; the cloud metadata endpoint is unreachable. The trusted capture sidecar alone receives a short-lived Pod-bound proof. A configured secret path releases only to external Envoy after live binding/grant checks; otherwise bindings fail admission.	The authorized origin receives the credential and may reflect it. A credential injected, baked into an image, or placed in a command would be readable by workload code; those paths are not supported secret delivery.
A sandbox exfiltrates data to an arbitrary public endpoint.	None beyond the floor: the public internet is reachable by design.	Destination-level egress filtering is not shipped. Do not put data you cannot afford to lose in front of untrusted code, and treat sandboxes as internet-connected.
An in-cluster workload forges identity headers to backend services.	Identity is stamped at the edge after authentication, and a network policy restricts backend ingress to the edge data plane and the authorizer. The fence is unconditional on every deployment shape; a self-managed install must name its own ingress as a peer and will not render until it does.	This control is a NetworkPolicy, so its strength is the CNI’s enforcement, exactly like the sandbox floor above — a pre-install gate proves that behaviourally before the install proceeds. Cluster-administrator access bypasses in-cluster controls; it is governed by the deployment operator.
One organization reads another organization’s records.	Every route is organization-scoped from the edge-stamped identity; sandbox-scoped credentials are further confined to their own lineage.	Database-administrator access is outside this boundary and governed by the deployment operator.
A platform-managed model-provider key leaks into a sandbox.	No supported sandbox model path exists today. The approved target keeps keys outside the guest and authorizes each request from live-workload proof; the existing Rust proxy is operator-only.	Direct provider access is not a supported fallback. Until the target ships, clean sandbox model access remains unavailable.
Someone outside your organization opens a shell in a sandbox.	Every `hiloop sandbox ssh` connect is authorized by the API against the organization that owns the sandbox, and answers a caller from another organization exactly as it answers a request for a sandbox that does not exist. The sandbox’s SSH server accepts only the single key pair the control plane minted for it, and the client half of that pair is never placed in the sandbox. Root login and password authentication are disabled.	An organization-scoped API credential is a shell credential: scope and rotate keys accordingly.
A runaway create loop exhausts the platform.	Per-organization quotas at create admission plus a transactional fleet-wide ceiling in the cluster.	Quotas bound counts, not the cost of what runs inside admitted sandboxes.
A credential appears in captured telemetry.	Capture proxies scrub recognized patterns from HTTP bodies and allowlisted environment values by default; managed sandbox capture also scrubs supervised stdio, argv, and local attributes. Exact supported OAuth token exchanges omit their bodies and query values regardless of generic scanning. No request or response header value other than `Content-Type` and `Content-Encoding` is captured.	Pattern matching is a backstop: a novel token format slips through, and a local `hiloop run --no-redact` explicitly disables the generic scan. Local-run stdio, OTLP span attributes, and ordinary request query strings are not scrubbed. See redaction.
A credential appears in telemetry sent directly to the OTLP or bulk ingest endpoints.	None. These producers do not pass through the capture proxy, and there is no server-side scrubbing stage at ingest or export.	Everything you send is stored as sent, and forwarded to any export sink you configure. Scrub in your own instrumentation before export.

Known limitations

Stated plainly so they cannot be assumed away:

An SSH session lands inside the workload container and therefore shares its filesystem, processes, and network exposure.
Destination-level egress filtering does not exist; the public internet is reachable from every sandbox.
A deployment without the complete managed secret-release path refuses binding requests. Do not bypass that refusal with a raw provider API key or platform-managed credential in the workload. Compatible provider-subscription login state may be tool-owned, but it authorizes model traffic only through the proof-bound gateway and never direct provider egress.
NetworkPolicy strength equals the installed CNI’s enforcement, and that covers both the sandbox floor and the backend-service identity fence. A pre-install gate proves enforcement behaviourally and refuses to install without it, but nothing re-proves it afterwards: swapping the CNI on a running cluster can retire both controls silently.
Snapshot content is whatever the sandbox wrote: snapshotting does not sanitize secrets or artifacts your workload placed on disk.

Verification gates

Run these from outside the workload, and expect both positive and negative results:

A create naming a volume mount fails admission with unsupported_capability; a secret binding does the same whenever proof-bound release is not configured.
A create naming durable storage either succeeds, or is refused with unsupported_capability on a deployment whose cluster names no backing storage class — never downgraded silently to node-bound storage.
A stop suspends the workload and a start brings it back. A transition outside the contract — a stop from a sandbox that is still materializing, or a start racing an in-flight stop — is refused by state rather than accepted-and-ignored.
No API response ever contains a stored secret value.
On a self-managed cluster: sandbox pods carry runtimeClassName: runsc; the workload container has no token mount; only the capture sidecar has its dedicated projected proof; and both the namespace deny-floor NetworkPolicy and the backend-service ingress fence are present and enforced by the CNI. Check enforcement rather than presence: dial a backend Service’s ClusterIP from an unrelated pod and confirm it does not answer.

See network requirements for deployment connectivity.

​Threats and coverage

​Known limitations

​Verification gates

Threats and coverage

Known limitations

Verification gates