warpdotdev · seemeroland · May 26, 2026
diff --git a/src/content/docs/agent-platform/cloud-agents/agents.mdx b/src/content/docs/agent-platform/cloud-agents/agents.mdx
@@ -18,7 +18,7 @@ Agent identities are useful when you want to:
 
 ## How agent identities work
 
-Each team has one default agent identity. Headless runs (such as team API key runs that don't specify an identity) execute under this default. User-triggered runs default to running as the calling user, which is surfaced as **Quick run** in the web app, unless you pick a specific agent identity. You can create additional agent identities on top of the default and run as any of them. Identities are team-scoped, so every member of a team can see and use the same set of agent identities.
+Each team has one default agent identity called **Default Service Account**. Headless runs that use an Agent API key for **Default Service Account** execute under this default, which is equivalent to the old team API key behavior. User-triggered runs default to running as the calling user, which is surfaced as **Quick run** in the web app, unless you pick a specific agent identity. You can create additional agent identities on top of the default and run as any of them. Identities are team-scoped, so every member of a team can see and use the same set of agent identities.
 
 You can attach the following configuration to an agent identity:
 
@@ -68,9 +68,9 @@ A few constraints apply across every endpoint:
 
 ## API keys bound to an agent identity
 
-A team API key can be bound to a specific agent identity at creation time. Calls authenticated with that key run as the chosen identity. The team is resolved automatically from the identity, so you don't need to specify a team when generating the key.
+An Agent API key is bound to a specific agent identity at creation time. Calls authenticated with that key run as the chosen identity. The team is resolved automatically from the identity, so you don't need to specify a team when generating the key.
 
-To create a key bound to an agent identity, choose the identity when creating the team API key. See [API keys](/reference/cli/api-keys/) for the full key creation flow and for the difference between user-scoped and team-scoped keys.
+To create a key bound to an agent identity, choose the identity when creating the Agent API key. Choose **Default Service Account** for the same behavior as the old team API key. See [API keys](/reference/cli/api-keys/) for the full key creation flow.
 
 Once the key exists, the CLI and SDK authenticate as that agent identity for every call. There is no extra flag to set; the binding is on the key itself.
 
@@ -81,7 +81,7 @@ There are two ways to run a cloud agent as a specific agent identity:
 * **Authenticate with a key bound to the identity** - Every run started with that key executes as the bound agent identity. This is the typical path for CI pipelines and scheduled work.
 * **Pass `agent_identity_uid` on `POST /agent/runs`** - For one-off runs, send the agent identity's `uid` in the request body. The field is only valid for team-owned runs.
 
-When neither path is used, headless runs (team API key runs without an identity) execute under the team's default agent identity. User-triggered runs (Warp app, personal API key, Slack, Linear) execute as the calling user and are surfaced as **Quick run** in the web app.
+When neither path is used, headless runs execute under the team's default agent identity. User-triggered runs (Warp app, `oz login`, Slack, Linear) execute as the calling user and are surfaced as **Quick run** in the web app.
 
 ## Where agent identities appear in the product
 

diff --git a/src/content/docs/agent-platform/cloud-agents/environments.mdx b/src/content/docs/agent-platform/cloud-agents/environments.mdx
@@ -133,7 +133,7 @@ You can create and configure environments with Warp’s guided setup, or through
 Make sure you have:
 
 * One or more GitHub repositories that the agent should clone and work in.
-* **GitHub authorization configured** so the agent can access your repos. For user-triggered runs, each user authorizes GitHub individually. For automated workflows using team API keys, configure [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) in the Admin Panel.
+* **GitHub authorization configured** so the agent can access your repos. For user-triggered runs, each user authorizes GitHub individually. For automated workflows using Agent API keys, configure [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) in the Admin Panel.
 * A publicly-accessible Docker image that can build and run your code. Official images like [node](https://hub.docker.com/_/node), [python](https://hub.docker.com/_/python), or [rust](https://hub.docker.com/_/rust) work for many projects. You can also use one of [Warp's prebuilt dev images](https://github.com/warpdotdev/oz-dev-environments).
 
 :::caution

diff --git a/...ent/docs/agent-platform/cloud-agents/integrations/quickstart-github-actions.mdx b/...ent/docs/agent-platform/cloud-agents/integrations/quickstart-github-actions.mdx
@@ -13,7 +13,7 @@ Add agents to your GitHub Actions workflows with [`oz-agent-action`](https://git
 
 ## Prerequisites
 
-* **Warp API key** - In the Warp app, click your profile photo, then go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create one. Use a personal key if the agent needs to write to your repo. See [API Keys](/reference/cli/api-keys/) for details.
+* **Agent API key** - In the Warp app, click your profile photo, then go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create one. Use **Default Service Account** for the same behavior as the old team API key, and configure [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) if the agent needs to write to your repo. See [API Keys](/reference/cli/api-keys/) for details.
 * **A GitHub repository with Actions enabled** - The workflow file will live in `.github/workflows/` in your repo.
 
 ---

diff --git a/src/content/docs/agent-platform/cloud-agents/quickstart.mdx b/src/content/docs/agent-platform/cloud-agents/quickstart.mdx
@@ -154,7 +154,7 @@ Use the [Oz API & SDK](/reference/api-and-sdk/) to trigger agents programmatical
 Use official Docker Hub images like `node`, `python`, or `rust` for best compatibility. Ensure your GitHub repos are accessible. If using a custom image, avoid Alpine/musl-based images—the agent runtime requires glibc. See [Environments](/agent-platform/cloud-agents/environments/) for more guidance on choosing Docker images.
 
 **Agent can't access repos**\
-Warp prompts you to authorize GitHub when you create an environment or trigger your first agent. If authorization fails or needs updating, see [How GitHub Authorization works](/reference/cli/integration-setup/#how-github-authorization-works). For automated workflows using team API keys, make sure [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) is configured in the Admin Panel. Also verify that repos are correctly configured in your environment with `oz environment get <ENV_ID>`.
+Warp prompts you to authorize GitHub when you create an environment or trigger your first agent. If authorization fails or needs updating, see [How GitHub Authorization works](/reference/cli/integration-setup/#how-github-authorization-works). For automated workflows using Agent API keys, make sure [team GitHub authorization](/agent-platform/cloud-agents/team-access-billing-and-identity/#team-github-authorization) is configured in the Admin Panel. Also verify that repos are correctly configured in your environment with `oz environment get <ENV_ID>`.
 
 **Not enough credits to run cloud agents**\
 Your team needs at least 20 credits available. Check your credit balance in Settings or see [Access, Billing, and Identity](/agent-platform/cloud-agents/team-access-billing-and-identity/) for details on credit requirements and which plans support cloud agents.

diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-direct.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-direct.mdx
@@ -39,7 +39,7 @@ The Direct backend does not provide per-task container isolation. Each task runs
 * **Enterprise plan with self-hosting enabled** — [Contact sales](https://www.warp.dev/contact-sales) if self-hosting is not yet enabled for your team.
 * **A worker host** with write access to `workspace_root` (defaults to `/var/lib/oz/workspaces`).
 * **The Oz CLI** installed and available in `PATH` on the worker host (or specify `oz_path` in the config file). See [Installing the CLI](/reference/cli/#installing-the-cli).
-* **A team API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create a team-scoped API key. See [API Keys](/reference/cli/api-keys/) for details.
+* **An Agent API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create an Agent API key. Use **Default Service Account** for the same behavior as the old team API key. See [API Keys](/reference/cli/api-keys/) for details.
 
 ---
 
@@ -50,7 +50,7 @@ The Direct backend does not provide per-task container isolation. Each task runs
 Export the API key so the worker can authenticate to Oz:
 
 ```bash
-export WARP_API_KEY="your_team_api_key"
+export WARP_API_KEY="your_agent_api_key"
 ```
 
 ### 2. Start the worker with the Direct backend

diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-docker.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-docker.mdx
@@ -26,7 +26,7 @@ This page covers the [managed architecture](/agent-platform/cloud-agents/self-ho
 * **Enterprise plan with self-hosting enabled** — [Contact sales](https://www.warp.dev/contact-sales) if self-hosting is not yet enabled for your team.
 * **A machine to run the worker** — A VM, server, or local machine running Linux (recommended for production). For testing, macOS and Windows hosts running Docker Desktop work.
 * **Docker installed** — The worker uses Docker to spawn task containers. The Docker daemon must run Linux containers (Windows containers are not supported). Verify with `docker info`.
-* **A team API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create a team-scoped API key. See [API Keys](/reference/cli/api-keys/) for details.
+* **An Agent API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create an Agent API key. Use **Default Service Account** for the same behavior as the old team API key. See [API Keys](/reference/cli/api-keys/) for details.
 
 :::caution
 Task containers require a **linux/amd64** or **linux/arm64** Docker daemon. The worker host itself can be any OS — Docker Desktop on macOS and Windows runs a Linux VM that satisfies this requirement.
@@ -46,10 +46,10 @@ docker info
 
 ## Set your API key
 
-Export your team API key so the worker can authenticate to Oz:
+Export your Agent API key so the worker can authenticate to Oz:
 
 ```bash
-export WARP_API_KEY="your_team_api_key"
+export WARP_API_KEY="your_agent_api_key"
 ```
 
 ## Install and run the worker

diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-kubernetes.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/managed-kubernetes.mdx
@@ -38,7 +38,7 @@ This page covers the [managed architecture](/agent-platform/cloud-agents/self-ho
   * Allow the worker's namespace to create Jobs with a **root init container** (sidecar materialization depends on this pattern).
   * Grant the worker these namespace-scoped permissions: `create`, `get`, `list`, `watch`, `delete` on `jobs`; `get`, `list`, `watch` on `pods`; `get` on `pods/log`; `list` on `events`.
 * **[Helm](https://helm.sh/docs/intro/install/)** installed locally, plus `kubectl` authenticated against the target cluster.
-* **A team API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create a team-scoped API key. See [API Keys](/reference/cli/api-keys/) for details.
+* **An Agent API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create an Agent API key. Use **Default Service Account** for the same behavior as the old team API key. See [API Keys](/reference/cli/api-keys/) for details.
 
 ---
 
@@ -59,7 +59,7 @@ The chart does not create CRDs or cluster-scoped RBAC resources.
 ### 1. Set your API key and namespace
 
 ```bash
-export WARP_API_KEY="your_team_api_key"
+export WARP_API_KEY="your_agent_api_key"
 ```
 
 Create the namespace if it doesn't exist:

diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/quickstart.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/quickstart.mdx
@@ -19,7 +19,7 @@ This quickstart sets up the [managed architecture](/agent-platform/cloud-agents/
 
 * **Enterprise plan with self-hosting enabled** — [Contact sales](https://www.warp.dev/contact-sales) if self-hosting is not yet enabled for your team.
 * **A Linux machine with Docker** — A VM, server, or local machine with the Docker daemon running Linux containers. Verify with `docker info`. Docker Desktop on macOS or Windows works for testing.
-* **A team API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create a team-scoped API key. See [API Keys](/reference/cli/api-keys/) for details.
+* **An Agent API key** — In the Warp app, go to **Settings** > **Cloud platform** > **Oz Cloud API Keys** to create an Agent API key. Use **Default Service Account** for the same behavior as the old team API key. See [API Keys](/reference/cli/api-keys/) for details.
 * **The Oz CLI** (for routing a test run) — See [Installing the CLI](/reference/cli/#installing-the-cli).
 
 ---
@@ -30,10 +30,10 @@ _~10 minutes_
 
 ### 1. Export your API key
 
-Export the team API key so the worker container can authenticate to Oz automatically:
+Export the Agent API key so the worker container can authenticate to Oz automatically:
 
 ```bash
-export WARP_API_KEY="your_team_api_key"
+export WARP_API_KEY="your_agent_api_key"
 ```
 
 ### 2. Start the worker
@@ -83,7 +83,7 @@ Open the [Oz dashboard](https://oz.warp.dev), find the new task, and confirm the
 Verify Docker is running (`docker info`) and that the daemon platform is `linux/amd64` or `linux/arm64`. Musl-based (Alpine) worker hosts are not supported.
 
 **Worker won't connect**\
-Verify your API key has team scope. Ensure the machine has outbound internet access to `oz.warp.dev:443`. Increase log verbosity with `--log-level debug` to see connection details.
+Verify your API key is an Agent API key for the same Warp team as the worker. Ensure the machine has outbound internet access to `oz.warp.dev:443`. Increase log verbosity with `--log-level debug` to see connection details.
 
 **Task stays queued and never runs**\
 Confirm the `--host` value you passed to `oz agent run-cloud` matches your `--worker-id` exactly (case-sensitive). Check that the worker's team matches the team creating the task.

diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/reference.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/reference.mdx
@@ -20,7 +20,7 @@ The following flags are available when starting the worker.
 ### Required
 
 * `--worker-id` — A string identifying this worker. This is the value you pass to `--host` when routing tasks. Choose something meaningful for your team (e.g., `prod-runner-1` or `ci-worker`). Multiple workers can share the same ID for load balancing.
-* `--api-key` or `WARP_API_KEY` env var — Your team API key for authentication. When running via Docker, pass it as `-e WARP_API_KEY="..."`. When running the binary directly, use `--api-key` or the environment variable.
+* `--api-key` or `WARP_API_KEY` env var — Your Agent API key for authentication. Use a key for **Default Service Account** for the same behavior as the old team API key. When running via Docker, pass it as `-e WARP_API_KEY="..."`. When running the binary directly, use `--api-key` or the environment variable.
 
 ### Optional
 

diff --git a/src/content/docs/agent-platform/cloud-agents/self-hosting/unmanaged.mdx b/src/content/docs/agent-platform/cloud-agents/self-hosting/unmanaged.mdx
@@ -33,14 +33,14 @@ No Docker, no worker daemon, no environment required — just the Oz CLI on any
 ### Prerequisites
 
 * **The Oz CLI** installed on the machine where agents will run. See [Installing the CLI](/reference/cli/#installing-the-cli) for platform-specific instructions.
-* **A Warp API key** — For automation, create a team-scoped API key in the Warp app at **Settings** > **Cloud platform** > **Oz Cloud API Keys**. See [API Keys](/reference/cli/api-keys/) for details.
+* **An Agent API key** — For automation, create an Agent API key in the Warp app at **Settings** > **Cloud platform** > **Oz Cloud API Keys**. Use **Default Service Account** for the same behavior as the old team API key. See [API Keys](/reference/cli/api-keys/) for details.
 
 ### 1. Authenticate
 
 Export your API key so the CLI can authenticate requests automatically:
 
 ```bash
-export WARP_API_KEY="your_team_api_key"
+export WARP_API_KEY="your_agent_api_key"
 ```
 
 ### 2. Run an agent
@@ -63,7 +63,7 @@ Use `--share` to control who can attach to the session and steer the agent:
 * `--share user@example.com` — Give a specific user read-only access.
 * `--share user@example.com:edit` — Give a specific user read/write access.
 
-The `--share` flag can be repeated to combine multiple sharing targets. If you authenticate with a team API key, agents are automatically team-scoped.
+The `--share` flag can be repeated to combine multiple sharing targets. If you authenticate with an Agent API key, agents are automatically team-scoped.
 
 ---