> ## 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.

# Trust boundaries

> How deployment models change data location and operational ownership.

hiloop can run as hosted SaaS, hybrid, BYOC, or on-prem / air-gapped deployments. The product model
is the same: requests are authorized at the edge, backend services use the stamped identity, runtime
resources execute workloads, and telemetry is stored under organization scope.

The boundary changes based on who operates the infrastructure and where data is stored.

## Boundary summary

| Data or control surface      | Hosted SaaS                                    | Hybrid                                         | BYOC                                           | On-prem / air-gapped                                                   |
| ---------------------------- | ---------------------------------------------- | ---------------------------------------------- | ---------------------------------------------- | ---------------------------------------------------------------------- |
| Control-plane API            | hiloop-operated                                | hiloop-operated                                | hiloop-operated                                | customer cluster                                                       |
| Sandbox compute              | hiloop-operated                                | hiloop-operated                                | customer cloud account                         | customer cluster                                                       |
| Event and workspace payloads | hiloop storage                                 | customer bucket                                | customer cloud account                         | customer storage                                                       |
| Control-plane metadata       | hiloop database                                | hiloop database                                | hiloop database                                | customer database                                                      |
| Platform telemetry           | operational telemetry, allowlisted fields only | operational telemetry, allowlisted fields only | operational telemetry, allowlisted fields only | local, plus health-metrics support telemetry (disableable for air-gap) |
| Identity provider            | hosted or configured SSO                       | hosted or configured SSO                       | customer or configured SSO                     | customer-controlled                                                    |

Platform telemetry is hiloop's own service telemetry, separate from the run telemetry your agents
produce. Its spans carry a fixed allowlist of low-cardinality identifiers and nothing else: request
bodies, payloads, and secrets are never attached in the first place, rather than attached and then
stripped. Your captured run telemetry is governed by [redaction](/observability/redaction) instead.

## Identity boundary

Every north-south request is checked before it reaches a backend. The edge resolves an API key or
session to an organization, user, and scope, then forwards trusted identity context to services. Services
derive organization scope from that context, not from untrusted request bodies.

Interactive shell sessions cross the same boundary and add no second one. `hiloop sandbox ssh`
carries the same organization-scoped API credential as every other request, and the API authorizes
each connect against the organization that owns the sandbox before it moves any bytes. There is no
separate SSH credential, no jump host, and nothing for you to rotate. See
[shell access](/concepts/architecture#shell-access).

## Data boundary

Large payloads matter most for trust reviews. Hosted deployments store event and workspace payloads
in hiloop-managed storage. Hybrid deployments keep selected payload storage under
customer-owned object storage. On-prem and air-gapped deployments keep the data plane inside the
customer environment.

## Operational boundary

Hosted deployments optimize for speed and managed operations. On-prem deployments shift more
responsibility to the customer: Kubernetes, PostgreSQL, object storage, registry, TLS certificates,
backup/restore, and local observability. BYOC and hybrid sit between those ends. On-prem, hiloop
operates nothing in your environment and holds no access into it — see
[hosted and self-managed](/concepts/architecture#hosted-and-self-managed).

## Verify it yourself

The boundaries above are observable, not just asserted. On an on-prem deployment you can confirm:

* **The data boundary holds.** Point the deployment at your own PostgreSQL and object storage, then
  confirm control-plane metadata and event/workspace payloads land only there.
* **The air-gapped posture is real.** Disable support telemetry (`supportTelemetry.enabled=false`)
  and confirm no service pod can reach the public internet — the
  [network requirements](/deployment/network-requirements#verify-it-yourself) check exercises this
  directly. In the default supported posture, the only outbound flow is a fixed platform-health
  metrics contract; workload data and event payloads never leave your environment in either posture.
* **The identity boundary holds.** Every backend derives tenancy from edge-stamped identity, not from
  request bodies — the [threat model](/deployment/threat-model#verification-gates) has the concrete
  egress, secret, signing, and non-root checks.

## Related pages

* [Architecture](/concepts/architecture)
* [Egress and secrets](/sandboxes/egress-secrets) — network policy and fail-closed secret admission
* [Deployment overview](/deployment/overview)
* [Security model](/deployment/security-model) — how hiloop prevents data exfiltration from sandboxes
* [Threat model](/deployment/threat-model) — what each control protects against, and how strongly