-
Notifications
You must be signed in to change notification settings - Fork 12
docs(cli): document oz logout, whoami, federate, and artifact commands #59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,77 @@ | ||
| --- | ||
| title: Artifacts | ||
| description: >- | ||
| Get metadata for and download files produced by an Oz agent run using the | ||
| `oz artifact` subcommands. | ||
| sidebar: | ||
| label: "Artifacts" | ||
| --- | ||
|
|
||
| Artifacts are files that an agent produces during a run and uploads to Oz — screenshots, generated reports, build outputs, logs, or any other file the agent saves alongside its conversation. Use `oz artifact` to inspect those files from outside the run and pull them down to your machine. | ||
|
|
||
| ## When to use artifacts | ||
|
|
||
| Use artifacts when you need to retrieve files an agent produced after a run completes, without re-running the agent or scraping the conversation output. | ||
|
|
||
| * **Hand-offs between runs** - A scheduled agent produces a report; a follow-up workflow downloads and processes it. | ||
| * **Local inspection** - Pull a generated file (HTML, image, CSV) onto your laptop to review. | ||
| * **CI integration** - Fetch an agent-produced build artifact from a pipeline step that runs after the agent finishes. | ||
|
|
||
| Artifacts are referenced by an artifact UID. You can find UIDs in the agent's run detail view, in the JSON returned by [`oz run get`](/reference/cli/), or in the response from the [Oz API](/reference/api-and-sdk/). | ||
|
|
||
| ## `oz artifact get` | ||
|
|
||
| Print metadata for an artifact without downloading it. | ||
|
|
||
| ```sh | ||
| oz artifact get <ARTIFACT_UID> | ||
| ``` | ||
|
|
||
| The output describes the artifact (file name, content type, size, the run or conversation it's associated with, and the description supplied when it was uploaded). Use `--output-format json` for a structured response that's easy to parse from a script: | ||
|
|
||
| ```sh | ||
| oz artifact get <ARTIFACT_UID> --output-format json | ||
| ``` | ||
|
|
||
| This command is useful for confirming an artifact exists and inspecting its size before you decide to download it. | ||
|
|
||
| ## `oz artifact download` | ||
|
|
||
| Download the file contents of an artifact. | ||
|
|
||
| ```sh | ||
| oz artifact download <ARTIFACT_UID> [--out <PATH>] | ||
| ``` | ||
|
|
||
| ### Flags | ||
|
|
||
| * **`<ARTIFACT_UID>`** - The UID of the artifact to download. Required positional argument. | ||
| * **`--out <PATH>`** (`-o`) - Write the downloaded artifact to a specific file path. When omitted, the file is written to the current directory using the artifact's stored file name. | ||
|
|
||
| ### Examples | ||
|
|
||
| Download an artifact to the current directory, preserving its original name: | ||
|
|
||
| ```sh | ||
| oz artifact download <ARTIFACT_UID> | ||
| ``` | ||
|
|
||
| Download to a specific path: | ||
|
|
||
| ```sh | ||
| oz artifact download <ARTIFACT_UID> --out ./reports/nightly.html | ||
| ``` | ||
|
|
||
| Use the artifact in a pipeline by combining `oz run get` and `oz artifact download`: | ||
|
|
||
| ```sh | ||
| # Pull the latest run for a scheduled agent, grab its first artifact | ||
| RUN_ID=$(oz run list --limit 1 --output-format json | jq -r '.[0].uid') | ||
| ARTIFACT_UID=$(oz run get "$RUN_ID" --output-format json | jq -r '.artifacts[0].uid') | ||
| oz artifact download "$ARTIFACT_UID" --out ./latest-report.html | ||
| ``` | ||
|
|
||
| ## Related | ||
|
|
||
| * [Oz API & SDK](/reference/api-and-sdk/) - retrieve artifacts programmatically over HTTP. | ||
| * [Scheduled cloud agents](/agent-platform/cloud-agents/triggers/scheduled-agents/) - common producer of recurring artifacts that downstream tooling consumes. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,98 @@ | ||
| --- | ||
| title: Federated identity tokens | ||
| description: >- | ||
| Issue short-lived OIDC identity tokens from a running Oz agent so it can | ||
| authenticate to cloud providers without long-lived credentials. | ||
| sidebar: | ||
| label: "Federated identity" | ||
| --- | ||
|
|
||
| `oz federate` issues short-lived OIDC identity tokens for the agent that's currently running. Use these tokens to authenticate to cloud providers (AWS, GCP, Azure, and other OIDC-aware systems) without baking long-lived credentials into your environment. | ||
|
|
||
| This command can only be called from inside a running Oz agent session — typically as part of a [skill](/agent-platform/capabilities/skills/), a tool, or a script the agent executes while a run is in progress. | ||
|
|
||
| ## When to use federation | ||
|
|
||
| Use federated identity tokens when you want an agent to act against a cloud account without storing service-account keys, access keys, or refresh tokens in the environment. | ||
|
|
||
| * **Short-lived credentials** - Tokens expire on a schedule you choose. Even if a token leaks, its blast radius is bounded. | ||
| * **No secret rotation** - Federation removes the need to rotate static keys in environments or secrets. | ||
| * **Per-run identity** - Each run can claim a different subject (user, team, environment, skill, run ID), giving you fine-grained IAM policies. | ||
|
|
||
| For background on federation, see your cloud provider's workload identity federation guide (for example, [Google Cloud's workload identity federation](https://cloud.google.com/iam/docs/workload-identity-federation) or [AWS IAM Identity Center](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html)). | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should probably link to https://docs.warp.dev/agent-platform/cloud-agents/integrations/cloud-providers/ as well here - there are streamlined paths for AWS and GCP OIDC |
||
|
|
||
| ## `oz federate issue-token` | ||
|
|
||
| Issue an OIDC identity token for the current run. | ||
|
|
||
| ```sh | ||
| oz federate issue-token \ | ||
| --run-id <RUN_ID> \ | ||
| --audience <AUDIENCE> \ | ||
| [--duration <DURATION>] \ | ||
| [--subject-template <COMPONENT> ...] | ||
| ``` | ||
|
|
||
| ### Flags | ||
|
|
||
| * **`--run-id <RUN_ID>`** - The ID of the Oz run requesting the token. The token is bound to this run. | ||
| * **`--audience <AUDIENCE>`** - The `aud` claim for the issued token. Set this to the value your cloud provider's identity pool expects (for example, an AWS IAM Identity Center audience or a GCP workload identity pool URL). | ||
| * **`--duration <DURATION>`** - Requested token lifetime. Accepts human-readable durations like `15m`, `1h`, or `2h30m`. Defaults to `1h`. | ||
| * **`--subject-template <COMPONENT> ...`** - Controls how the OIDC token's `sub` claim is formatted. Pass one or more components, which are joined to form the subject. Defaults to `principal` (for example, `user:my-user-id`). | ||
|
|
||
| ### Subject template components | ||
|
|
||
| The subject claim is what your cloud provider's policy will match on, so pick the combination that gives you the IAM granularity you need. Supported components: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The OIDC token also includes all of these as structured claims, which is strongly preferable to squishing them all into the subject claim. We support this for providers like AWS that only handle the subject claim, and not any custom claims |
||
|
|
||
| * **`principal`** - The acting principal, like `user:my-user-id` or `service_account:my-sa-id`. | ||
| * **`scoped_principal`** - The principal scoped to a team, like `principal:my-team-id/user:my-user-id`. | ||
| * **`email`** - The principal's email, like `email:user@warp.dev`. | ||
| * **`teams`** - The principal's team, like `teams:my-team-id`. | ||
| * **`environment`** - The [cloud environment](/agent-platform/cloud-agents/environments/) the run is using, like `environment:my-environment-id`. | ||
| * **`agent_name`** - The configured name of the run, like `agent_name:my-agent`. | ||
| * **`skill_spec`** - The skill the run was launched from, like `skill_spec:warpdotdev/repo_path_to_skill`. | ||
| * **`run_id`** - The run's unique ID, like `run_id:abc123`. | ||
| * **`host`** - The self-hosted worker the run is on, like `host:my-worker-id`. | ||
|
|
||
| When you pass multiple components, the resulting subject joins them in the order you specified. | ||
|
|
||
| ### Examples | ||
|
|
||
| Issue a one-hour token bound to the current user, for an AWS audience: | ||
|
|
||
| ```sh | ||
| oz federate issue-token \ | ||
| --run-id "$OZ_RUN_ID" \ | ||
| --audience "sts.amazonaws.com" | ||
| ``` | ||
|
|
||
| Issue a 15-minute token whose subject identifies the team and environment, so a GCP IAM policy can grant access only to that pair: | ||
|
|
||
| ```sh | ||
| oz federate issue-token \ | ||
| --run-id "$OZ_RUN_ID" \ | ||
| --audience "//iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/oz/providers/oz-oidc" \ | ||
| --duration 15m \ | ||
| --subject-template teams environment | ||
| ``` | ||
|
|
||
| ## Using tokens with cloud providers | ||
|
|
||
| Once you have a token, exchange it for cloud credentials using your provider's standard OIDC federation flow. The exchange happens between the cloud provider and your script — Oz only issues the OIDC token. | ||
|
|
||
| A typical AWS flow: | ||
|
|
||
| 1. Run `oz federate issue-token` to get the OIDC JWT. | ||
| 2. Call `sts:AssumeRoleWithWebIdentity` with the JWT and an IAM role ARN. | ||
| 3. Use the temporary AWS credentials returned by STS. | ||
|
|
||
| A typical GCP flow: | ||
|
|
||
| 1. Run `oz federate issue-token` to get the OIDC JWT. | ||
| 2. Call the [Security Token Service `token` endpoint](https://cloud.google.com/iam/docs/reference/sts/rest/v1/TopLevel/token) to exchange the JWT for a federated access token. | ||
| 3. Optionally impersonate a service account for the final credentials. | ||
|
|
||
| ## Related | ||
|
|
||
| * [Cloud environments](/agent-platform/cloud-agents/environments/) - configure the environment your agent runs in. | ||
| * [Secrets](/agent-platform/cloud-agents/secrets/) - alternative for credentials that can't be federated. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably replace this with the
warp-serverversion, unless it's synced from there?