Automation Platform > Agent configuration
Legacy cloud agent secrets
# Legacy cloud agent secrets :::note **Using Warp Factories?** Follow [Managing factory secrets](https://docs.warp.dev/factories/secrets/) to create secrets and grant agents access in the current web app. The instructions on this page cover supported legacy workflows, including the Oz CLI. ::: Use the [Oz CLI](/agents/cli/oz-cli/) to create, list, rotate, and delete managed secrets for standalone cloud-agent workflows. The commands remain supported. ## Secret scopes Secret ownership determines which credentials a run is eligible to use; its configuration determines which eligible secrets are injected. ### Team secrets Team secrets belong to the team. Use narrowly scoped service-account credentials rather than credentials tied to an individual person. Attach secrets by name to a [cloud agent](/platform/agents/) or its execution configuration. ### Personal secrets Personal secrets belong to your user account. Runs without your user context cannot use them. They aren't listed in the factory secret picker; use team secrets for factories. ## Managing agent secrets with the CLI In the Oz CLI, use the `oz secret` commands. Log in first as described in the [CLI quickstart](/agents/cli/oz-cli/quickstart/). ### Creating a secret Create a team secret interactively: ```bash oz secret create --team METABASE_API_KEY ``` The CLI prompts for the credential without displaying it. For a personal secret, replace `--team` with `--personal`. To read a credential from a file, replace `SECRET_FILE` below with its path. Protect the file and exclude it from version control. ```bash oz secret create --personal --value-file SECRET_FILE METABASE_API_KEY ``` ### Adding descriptions Use a description to record ownership and rotation requirements without including the credential: ```bash oz secret create --team \ --description "Rotate every 2 weeks; owned by platform team" \ METABASE_API_KEY ``` ### Updating a secret Replace the value while keeping the same name and scope: ```bash oz secret update --team --value METABASE_API_KEY ``` The CLI prompts for the replacement credential. To read it from a file instead, replace `NEW_SECRET_FILE` with the file's path: ```bash oz secret update --team --value-file NEW_SECRET_FILE METABASE_API_KEY ``` Update only the description: ```bash oz secret update --team \ --description "Owned by platform team; rotated monthly" \ METABASE_API_KEY ``` ### Listing secrets List metadata for secrets you can access: ```bash oz secret list ``` Stored values aren't displayed. ### Deleting a secret Delete a team secret: ```bash oz secret delete --team METABASE_API_KEY ``` The CLI asks for confirmation. Add `--force` to skip confirmation, or replace `--team` with `--personal` for a personal secret. :::caution Deletion is permanent and affects workflows that reference the secret. Remove or replace those references first, and revoke the credential in the external service if it must no longer be usable. ::: ### How secrets are made available to cloud agents Raw-value secrets are injected as environment variables using the secret name. Avoid printing credentials in commands or agent outputs; [secret redaction](/support-and-community/privacy-and-security/secret-redaction/) is a backstop, not a replacement for restricted access. #### Secret size limit See the shared [secret size limit](https://docs.warp.dev/factories/secrets/#a-secret-value-is-too-large) and guidance for large payloads. ## Secret availability by trigger type Runs associated with your user can resolve eligible personal secrets as well as team secrets. Runs without a user context, such as unattended automations, cannot use personal secrets. Ownership alone doesn't attach a secret to a run; check its configured secret list rather than assuming every team secret is injected. ## Scoping secrets to environments and runs An [environment](/platform/environments/) or [cloud agent account](/platform/agents/) can supply secret references. Run configuration can override the inherited list. Use an explicit list to select the execution secrets needed for a task. ### Environment-level scoping Attach the credentials an environment needs through its secret configuration. References use names, not stored values, so rotating a secret doesn't require changing its references. ### Run-level scoping A run's explicit `secrets` list selects its execution secrets. An empty list selects no generic execution secrets; harness authentication and credentials required by attached MCP servers are handled separately. See the [Warp Platform API reference](https://docs.warp.dev/factories/api-and-sdk/) for the request shape. ## Creating secrets in the web app For the current web-app workflow, follow [creating a factory secret](https://docs.warp.dev/factories/secrets/#creating-a-secret). The legacy [Oz web app](/platform/oz-web-app/) is a separate surface for standalone workflows. ### AWS ECR credentials The image-pull setup now lives under [Configuring AWS ECR credentials](https://docs.warp.dev/factories/secrets/aws-ecr/). ### Warp could not assume the IAM role See [IAM role troubleshooting](https://docs.warp.dev/factories/secrets/aws-ecr/#ecr-role-assumption-fails). ### Warp assumed the role, but could not get an ECR token See [ECR token troubleshooting](https://docs.warp.dev/factories/secrets/aws-ecr/#ecr-token-retrieval-fails). ### Image pulls fail See [image-pull troubleshooting](https://docs.warp.dev/factories/secrets/aws-ecr/#ecr-image-pulls-fail). ## Related pages * [Managing factory secrets](https://docs.warp.dev/factories/secrets/) - Use the current factory workflow * [Oz CLI reference](/agents/cli/oz-cli/) - Look up legacy command options * [Cloud agent accounts](/platform/agents/) - Configure a standalone agent's accessTell me about this feature: https://docs.warp.dev/platform/secrets/Manage team and personal secrets with the legacy Oz CLI for standalone workflows.
Use the Oz CLI to create, list, rotate, and delete managed secrets for standalone cloud-agent workflows. The commands remain supported.
Secret scopes
Section titled “Secret scopes”Secret ownership determines which credentials a run is eligible to use; its configuration determines which eligible secrets are injected.
Team secrets
Section titled “Team secrets”Team secrets belong to the team. Use narrowly scoped service-account credentials rather than credentials tied to an individual person. Attach secrets by name to a cloud agent or its execution configuration.
Personal secrets
Section titled “Personal secrets”Personal secrets belong to your user account. Runs without your user context cannot use them. They aren’t listed in the factory secret picker; use team secrets for factories.
Managing agent secrets with the CLI
Section titled “Managing agent secrets with the CLI”In the Oz CLI, use the oz secret commands. Log in first as described in the CLI quickstart.
Creating a secret
Section titled “Creating a secret”Create a team secret interactively:
oz secret create --team METABASE_API_KEYThe CLI prompts for the credential without displaying it. For a personal secret, replace --team with --personal.
To read a credential from a file, replace SECRET_FILE below with its path. Protect the file and exclude it from version control.
oz secret create --personal --value-file SECRET_FILE METABASE_API_KEYAdding descriptions
Section titled “Adding descriptions”Use a description to record ownership and rotation requirements without including the credential:
oz secret create --team \ --description "Rotate every 2 weeks; owned by platform team" \ METABASE_API_KEYUpdating a secret
Section titled “Updating a secret”Replace the value while keeping the same name and scope:
oz secret update --team --value METABASE_API_KEYThe CLI prompts for the replacement credential. To read it from a file instead, replace NEW_SECRET_FILE with the file’s path:
oz secret update --team --value-file NEW_SECRET_FILE METABASE_API_KEYUpdate only the description:
oz secret update --team \ --description "Owned by platform team; rotated monthly" \ METABASE_API_KEYListing secrets
Section titled “Listing secrets”List metadata for secrets you can access:
oz secret listStored values aren’t displayed.
Deleting a secret
Section titled “Deleting a secret”Delete a team secret:
oz secret delete --team METABASE_API_KEYThe CLI asks for confirmation. Add --force to skip confirmation, or replace --team with --personal for a personal secret.
How secrets are made available to cloud agents
Section titled “How secrets are made available to cloud agents”Raw-value secrets are injected as environment variables using the secret name. Avoid printing credentials in commands or agent outputs; secret redaction is a backstop, not a replacement for restricted access.
Secret size limit
Section titled “Secret size limit”See the shared secret size limit and guidance for large payloads.
Secret availability by trigger type
Section titled “Secret availability by trigger type”Runs associated with your user can resolve eligible personal secrets as well as team secrets. Runs without a user context, such as unattended automations, cannot use personal secrets. Ownership alone doesn’t attach a secret to a run; check its configured secret list rather than assuming every team secret is injected.
Scoping secrets to environments and runs
Section titled “Scoping secrets to environments and runs”An environment or cloud agent account can supply secret references. Run configuration can override the inherited list. Use an explicit list to select the execution secrets needed for a task.
Environment-level scoping
Section titled “Environment-level scoping”Attach the credentials an environment needs through its secret configuration. References use names, not stored values, so rotating a secret doesn’t require changing its references.
Run-level scoping
Section titled “Run-level scoping”A run’s explicit secrets list selects its execution secrets. An empty list selects no generic execution secrets; harness authentication and credentials required by attached MCP servers are handled separately. See the Warp Platform API reference for the request shape.
Creating secrets in the web app
Section titled “Creating secrets in the web app”For the current web-app workflow, follow creating a factory secret. The legacy Oz web app is a separate surface for standalone workflows.
AWS ECR credentials
Section titled “AWS ECR credentials”The image-pull setup now lives under Configuring AWS ECR credentials.
Warp could not assume the IAM role
Section titled “Warp could not assume the IAM role”Warp assumed the role, but could not get an ECR token
Section titled “Warp assumed the role, but could not get an ECR token”See ECR token troubleshooting.
Image pulls fail
Section titled “Image pulls fail”See image-pull troubleshooting.
Related pages
Section titled “Related pages”- Managing factory secrets - Use the current factory workflow
- Oz CLI reference - Look up legacy command options
- Cloud agent accounts - Configure a standalone agent’s access