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

# Keyless cloud access

> Give a workload short-lived AWS, Google Cloud, or Microsoft Entra credentials through OIDC federation — no static cloud keys anywhere.

A sandbox that needs to reach your cloud account should never hold a long-lived cloud key. Instead,
a sandbox running as a [workload](/concepts/workload-identity) mints a short-lived, audience-bound
JWT from the deployment's workload-identity issuer and exchanges it directly with your cloud through
its native workload-identity federation. No static credential is stored anywhere and no refresher
daemon runs in the guest: AWS and Google Cloud tokens are minted on demand rather than parked in a
default token file, and the Microsoft Entra lane writes only its explicit SDK fallback token file,
on boot-local tmpfs.

<Warning>
  Steps 1 and 2 below work today. **Step 3 does not yet**: `hiloop sandbox create` has no workload
  declaration, so a sandbox cannot be launched as a workload and carries no ambient identity for
  `hiloop workload-identity` to mint against. You can register federation and configure the cloud-side
  trust now, but do not build a flow that depends on the in-sandbox exchange until the sandbox lane
  lands. See [workload identity](/concepts/workload-identity).
</Warning>

The flow has three parts: register the federation (owner/admin, once per workload and cloud),
configure the trust on the cloud side (once), and use it from inside the sandbox.

## 1. Register the federation

Federation is registered per workload, per cloud. The token audience is derived server-side from
the registered descriptor, so a workload can only request tokens for audiences an owner or admin
registered — the registration list *is* the workload's token-audience allowlist.

```sh theme={null}
# AWS: trust codex-runner to assume exactly one IAM role
hiloop workloads federation add codex-runner \
  --cloud aws \
  --role-arn arn:aws:iam::123456789012:role/agent-readonly \
  --idempotency-key reg-codex-aws-1

# Review the allowlist
hiloop workloads federation list codex-runner
```

Google Cloud registrations take `--project-id`, `--project-number`, `--pool-id`, and
`--provider-id` (plus optional `--service-account-email` to impersonate). Microsoft Entra
registrations take `--application-id` and `--entra-tenant-id`.

## 2. Configure the cloud-side trust

`federation setup` prints the exact, copyable trust configuration for one registration — read-only,
it never changes your cloud account:

```sh theme={null}
hiloop workloads federation setup codex-runner <federation-id>
```

The generated trust policy pins the deployment's issuer and the workload's subject
(`org:<id>:workload:<id>`), so the mapping is exact and auditable on both sides. For AWS,
`--organization-wide` widens the trust from one workload to every workload in the organization; the
pattern stays organization-pinned. Two operational notes: Microsoft Entra allows at most 20 federated identity
credentials per application, and a typo in issuer/subject/audience is often accepted at creation
and fails only at exchange — verify the exact values if an exchange is rejected.

## 3. Use it inside the sandbox

This is the shape the sandbox lane will take, and it is not reachable yet (see the warning above).
Once a sandbox can run as the workload, `hiloop workload-identity` wires the cloud SDKs to the
ambient identity. `setup` prints the exact SDK wiring for every registered federation descriptor
(pass `--cloud aws|gcp|azure` to narrow it):

```sh theme={null}
hiloop workload-identity setup
```

The commands it wires, per cloud — tokens are minted on demand:

```sh theme={null}
# AWS: standard credential_process integration
# ~/.aws/config inside the sandbox:
#   [profile agent]
#   credential_process = hiloop workload-identity aws-credentials \
#     --audience sts.amazonaws.com \
#     --role-arn arn:aws:iam::123456789012:role/agent-readonly

# Google Cloud: executable-sourced subject tokens for the registered provider audience
hiloop workload-identity gcp-credential-source --audience "$GCP_PROVIDER_AUDIENCE"

# Microsoft Entra: refresh the SDK fallback token file (boot-local tmpfs)
hiloop workload-identity azure-token-file \
  --audience api://AzureADTokenExchange \
  --federation-id "$FEDERATION_ID"
```

`hiloop workload-identity token --audience <audience>` mints one raw federation JWT to stdout when
you need to drive an exchange yourself. Every audience must be on the workload's registered
allowlist — an unregistered audience is refused.

## Revoke

Removing a registration revokes the audience on the hiloop side immediately:

```sh theme={null}
hiloop workloads federation remove codex-runner <federation-id>
```

The trust object you created in the cloud account is yours — remove it there separately.

## Why this shape

* **Nothing to leak.** There is no long-lived cloud key in the sandbox, its environment, its
  workspace, or the platform's stores.
* **Attribution on both sides.** A cloud API call made this way carries the workload's pinned
  subject in your cloud audit log and the workload's name in the hiloop run record.
* **Scoped by construction.** The audience allowlist is registered per workload by an owner or
  admin, and your cloud trust policy decides exactly what that audience may do.

## Related pages

* [Workload identity](/concepts/workload-identity) — principals, launch ACLs, and attribution.
* [Managing secrets](/guides/managing-secrets) — for third-party API credentials that are not
  cloud-native.
* [Security model](/deployment/security-model) — where keyless access sits in the layered defense.