> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hiloop.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Secrets in sandboxes

> How secret bindings are admitted and released without entering the guest.

The secret store and secret *use* inside sandboxes are separate capabilities. Values are write-only
and envelope-encrypted. A configured proof-bound release path can use one at its exact public HTTPS
destination without placing plaintext inside the sandbox Pod.

## Admission is fail-closed

`CreateSandboxRequest` accepts pre-registered secret bindings by name (`--secret <name>` on the
CLI). The API admits the binding only when the deployment configures the complete mutual-TLS
release boundary. Otherwise the create is refused with `unsupported_capability`, before a sandbox
is launched. The hosted service enables this boundary for one exact public HTTPS hostname per
bearer secret. Localhost, private destinations, IP literals, and IPv6 destinations are refused.

Admission requires a live bearer secret, an exact use grant for the executing
principal, and a unique public HTTPS destination. The immutable binding records the secret and
destination; a later request rechecks the live sandbox incarnation, source Pod, principal, grant,
revocation, and current secret version. The API commits a content-free decision before releasing
the value to trusted Envoy, which overwrites `Authorization` outside the sandbox Pod.

The same applies to volume mounts (`--volume`): the deployment must be able to enforce the named
transport exactly, and the request is refused until that transport ships. See
[what's live today](/sandboxes/overview#whats-live-today).

## Safe use

* Keep credentials in the write-only secret store (`hiloop secret set` / `rotate` / `revoke`);
  values are envelope-encrypted and never returned. See
  [managing secrets](/guides/managing-secrets).
* Do **not** paste a credential into a sandbox image, command, environment, or metadata as a
  workaround: nothing scrubs it there, and snapshots would capture it.
* Platform-managed model-provider access is unavailable to sandboxes today. The approved
  [model gateway](/deployment/model-gateway) target keeps the credential outside the guest; the
  existing Rust body proxy is operator-only and is not a sandbox fallback.
* Local `hiloop run` has no managed secret-delivery path. Supplying a credential directly to a
  local process is an explicit exposure to that process, its environment, and local inspection
  surfaces; it does not become a Hiloop secret binding.
* Treat the authorized origin as part of the trust boundary: it receives the bearer token and may
  reflect it. Bind only a narrowly scoped credential to a destination you trust.

## Network posture

Generic HTTPS secret bindings require the `public` network profile. Creation and profile updates
that would combine a generic secret binding with `gateway_only` or `none` are refused before the
profile changes. See [network access](/sandboxes/network-egress).