Keyless CI: OIDC and workload identity before API keys

In Claude Code

There are three keyless routes available in Claude Code for the most popular cloud providers, one per provider; they all follow the same pattern — a single env var is being set to enable them and from that point on no Anthropic API key is queried by the tool at all.

The official docs confirm it for each provider. The Bedrock one: "Claude Code uses the default AWS SDK credential chain". The Foundry one: "When neither ANTHROPIC_FOUNDRY_API_KEY nor ANTHROPIC_FOUNDRY_AUTH_TOKEN is set, Claude Code automatically uses the Azure SDK default credential chain."

If we look at the CLI, in version 2.1.221 this is also described from the other side, in the help message under --bare: "Anthropic auth is strictly ANTHROPIC_API_KEY or apiKeyHelper via --settings (OAuth and keychain are never read). 3P providers (Bedrock/Vertex/Foundry) use their own credentials."

For instance, Anthropic's own GitHub Actions docs include a ready Bedrock setup — assuming an OIDC role and generating a GitHub App token to use with claude-code-action:

permissions:
  contents: write
  pull-requests: write
  issues: write
  id-token: write

jobs:
  claude:
    runs-on: ubuntu-latest
    env:
      AWS_REGION: us-west-2
    steps:
      - uses: actions/checkout@v4
      - name: Generate GitHub App token
        id: app-token
        uses: actions/create-github-app-token@v2
        with:
          app-id: ${{ secrets.APP_ID }}
          private-key: ${{ secrets.APP_PRIVATE_KEY }}
      - name: Configure AWS Credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
          aws-region: us-west-2
      - uses: anthropics/claude-code-action@v1
        with:
          github_token: ${{ steps.app-token.outputs.token }}
          use_bedrock: "true"
          claude_args: '--model us.anthropic.claude-sonnet-4-6 --max-turns 10'

AWS_ROLE_TO_ASSUME stores a role ARN, which is not a credential.

So we still need to provide another token to the action for it to be able to read the PR and post comments. For third-party providers Anthropic recommends creating a GitHub App and then using actions/create-github-app-token to mint a token, storing APP_ID and APP_PRIVATE_KEY in secrets. The bottom line is that we replace a model key with an App's private key, which is still the better side of the trade as the App has only the permissions that were granted to it and can't be used to spend on models. It's not the zero-secrets solution, though.

If you use the CLI without the action, you don't need anything else — claude -p just picks up whatever the login step left in the environment.

If you're using the tool locally, you can define the settings entries awsAuthRefresh and gcpAuthRefresh which run a command when credentials expire, sparing SSO users from pasting keys.

In Codex CLI

0.146.0 doesn't support OIDC and doesn't have any kind of federation flag at all — we checked every option in codex --help, codex exec --help and codex login --help. Instead it gives two ways to provide a credential that isn't a stored key, and one of them is the most general mechanism among the six tools we examined.

The built-in Bedrock provider. Codex ships an amazon-bedrock provider, and the two settings the configuration reference documents for it are AWS ones — an AWS profile name and an AWS region:

[model_providers.amazon-bedrock.aws]
region = "us-east-1"

That's the shape of a provider which resolves AWS credentials rather than an OpenAI key, which is what we want. Two caveats worth knowing before you build on it, though. The reference only mentions those two properties, so it's hard to know which parts of the AWS credential chain it consults, and we haven't exercised it ourselves either (that needs a real AWS account with Bedrock access). And if you do reach for profile, note that configure-aws-credentials exports credentials into the environment by default and only writes a named profile when you ask for it — so a profile = "ci" line and an OIDC login step don't wire together on their own.

The token command, which is the interesting one. Any custom provider can point at a command that emits a bearer token on stdout:

[model_providers.internal]
name     = "Internal gateway"
base_url = "https://models.internal.example.com/v1"

[model_providers.internal.auth]
command             = "/usr/local/bin/mint-token"
refresh_interval_ms = 300000

The reference describes auth.command as the "command to run when Codex needs a bearer token. The command must print the token to stdout", with refresh_interval_ms controlling how often Codex proactively refreshes it — 300000 by default, and 0 meaning refresh only after an authentication retry. It's very powerful, as you can plug in any identity system you already run: a script exchanges the CI OIDC token for whatever your gateway accepts, and Codex never sees a stored secret. One rule — the reference says do not combine auth with env_key, experimental_bearer_token or requires_openai_auth.

Otherwise it's a key. env_key names an environment variable holding the provider API key; for OpenAI directly that's OPENAI_API_KEY or a ChatGPT session. Two things about the login flags matter in CI:

printenv OPENAI_API_KEY | codex login --with-api-key
printenv CODEX_ACCESS_TOKEN | codex login --with-access-token

Both read their value from stdin rather than the command line, which means it doesn't end up in shell history or a process listing. And --with-access-token is the enterprise path, for when something upstream has already obtained a token for you. codex login --device-auth is there for headless hosts, but it still needs a person at a browser — so it's for provisioning a box, not for a pipeline.

The gotcha. You can cache the ~/.codex/auth.json file that codex login writes, but we wouldn't: it puts a durable credential in your cache store, with none of the properties we came here for. Best to pass a key per run instead, so it dies with the runner.

In GitHub Copilot CLI

It's probably the simplest of the six, and it doesn't involve OIDC at all — both the CI and the model come from the same company, so there's no federation to arrange; the job's own token is the credential.

Since July 2nd, 2026 Copilot CLI authenticates in GitHub Actions with the built-in GITHUB_TOKEN; before that you had to create a PAT and store it. The whole change is one permission — here's a minimal workflow which reads the repository's contents, writes to copilot-requests, installs the CLI and runs it with GITHUB_TOKEN set as an environment variable:

name: Copilot CLI example
on: [push]

permissions:
  contents: read
  copilot-requests: write

jobs:
  copilot:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - name: Install Copilot CLI
        run: npm install -g @github/copilot
      - name: Run Copilot
        run: copilot --yolo -p "Summarize the changes in this commit"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

GitHub says that "The GITHUB_TOKEN provided by GitHub Actions handles authentication automatically, no additional secrets are needed" — that's important, because just like in the other solutions presented in this lesson it's a token minted per job and expiring with it.

To use it you'll need:

• the organisation policy "Allow use of Copilot CLI billed to the organisation" enabled (which is on by default if the Copilot CLI policy already is)

• an up-to-date version of the CLI (copilot update, or a fresh install)

• to accept that AI credits are charged to the organisation, so per-user budgets aren't applicable and the limit comes from a cost centre or a session cap

If you want Copilot to have different permissions than the rest of the job without disturbing the GITHUB_TOKEN your other steps are using, set COPILOT_GITHUB_TOKEN, as shown on the environment help page on 1.0.78 — "COPILOT_GITHUB_TOKEN, GH_TOKEN, GITHUB_TOKEN (in order of precedence)".

The --yolo flag in the example above is necessary, not a decoration — it suppresses the interactive prompts that an environment without a terminal can't answer. Which also means the same workflow hands an agent a lot of power over the job, and GitHub says so plainly: "Invoking Copilot CLI directly in workflow steps gives it broad access to your workflow environment", and "Workflows triggered by pull requests from forks are particularly at risk." So gate the fork case before you ship this.

None of the above applies to the model call if you're on BYOK — COPILOT_PROVIDER_BASE_URL pointed at your own endpoint. But there COPILOT_PROVIDER_BEARER_TOKEN takes precedence over COPILOT_PROVIDER_API_KEY, which is the hook for a short-lived token from a gateway instead of a stored key.

In Cursor

In this tool, we can't get rid of secrets, so we'll just say it. The Cursor CLI supports two ways of authentication:

• browser-based, with credentials stored on the machine

• via API key

You can see in the docs that they encourage the latter for automation — "For automation, scripts, or CI environments, use API key authentication" — by setting an env var called CURSOR_API_KEY or using the --api-key flag. For instance, this is what the official GitHub Actions snippet looks like:

- name: Run Cursor Agent
  env:
    CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
  run: |
    agent -p "Your prompt here" --model gpt-5

To be sure we looked into the shipped 2026.07.23 build and saw CURSOR_API_KEY throughout the bundles; there's also no mention of ACTIONS_ID_TOKEN_REQUEST_URL, workloadIdentityPools or AssumeRoleWithWebIdentity. There's an --endpoint flag, but that's for the Cursor API (https://api2.cursor.sh by default), not a cloud model endpoint, which means credential chaining isn't available. So let's accept that as a dead end and focus on these four things instead:

1. A key dedicated to this pipeline only, different from your local dev key, so we know where it lives and revoking it breaks exactly one thing

2. Using the env var rather than the flag, so the key isn't visible in the process list of a shared runner and doesn't end up pasted into a debugging comment

3. Limiting the agent's behaviour, since the key is long-lived — Cursor has a permissions config with allow and deny rules, so deny Write(.env*) and shell access to git, and allow only the paths this job actually needs. With a key like this, that config is doing the job an IAM role does elsewhere

4. Writing down the rotation date, because nothing in this setup will remind you

Also, agent status prints the account a session is authenticated as — the fastest way to make sure the runner is using the pipeline's identity and not a personal login someone forgot in a cached home directory.

In Antigravity CLI

Antigravity — we would personally avoid setting up CI pipelines to run it in an automated way for now, and there's one specific reason for that.

There's no authentication flag and no auth subcommand. Run agy --help on 1.1.10 and the whole surface is agent, changelog, help, install, models, plugin and update, plus agents and plugins as aliases of two of those.

What is more, their docs for headless usage — which is what you need for CI — say plainly: "Headless mode uses your cached credentials. Authenticate once with an interactive agy session first." In a non-interactive environment with no terminal it fails with an authentication error rather than hanging, which is better, but given a CI scenario starts on a clean machine it means you'll need to store whatever that session cached and put it back on disk before the run.

What we don't like about this is that we don't know anything about that credential — they don't document it, so we can't know its scope or how long it stays valid, and we can't be confident it was properly revoked after use (if that's even possible). It's the opposite direction from everything else in this lesson.

That being said, running the CLI headlessly is fine in itself, and their own CI sample is a good pattern to keep:

result=$(agy -p "Name three popular version control systems, comma-separated." \
  --output-format json --print-timeout 10m)

Then inspect the status field and exit non-zero when it isn't a success, so the pipeline fails on such a run instead of quietly producing nothing.

On the API key you'll find suggested elsewhere. Blog posts and third-party wrappers name an ANTIGRAVITY_API_KEY. Looking into the 1.1.10 binary we can't find that string at all — what we do find is GEMINI_API_KEY, GOOGLE_API_KEY, GOOGLE_APPLICATION_CREDENTIALS and GOOGLE_GENAI_USE_VERTEXAI, along with the CLI's own warning text for having two of them set at once. None of it is in the vendor's CLI documentation, and a string in a binary doesn't prove which code path reads it. Undocumented auth is definitely not a good foundation for a pipeline.

If they add support for an API key in the future, it will be documented.

Generally speaking — use agy on your dev machine if you want to work with it interactively, and pick sth else for CI.

In Kimi Code CLI

No keyless path here, and one trap which can cost you significant time if you fall into it.

Auth flow — device-code login, via the kimi login command or /login inside the TUI. You have two options: Kimi Code OAuth, or an API key from the Moonshot AI Open Platform. After login, kimi provider list shows which provider is active, its type, how many models it has, where the credentials came from, and what the default model is:

managed:kimi-code  type=kimi  models=4  source=oauth

Default model: kimi-code/k3

The trap — it ignores environment variables exported to the shell.

It's a very common mistake, and the official docs call it out by name: "many users run export KIMI_API_KEY=xxx in the shell expecting the CLI to pick it up automatically, but it does not."

Provider credentials resolve from [providers.<name>].api_key in the config file first, and only when that's empty from the matching key inside the [providers.<name>.env] sub-table.

The main thing is that the env sub-table is just a section of the config file. It doesn't read anything from your shell environment, so with KIMI_API_KEY=abc123 exported the CI run exits with a missing-credentials error even though env clearly shows the variable is set.

The exception — the KIMI_MODEL_* channel, and the recommended CI setup.

If you set KIMI_MODEL_NAME, the CLI takes a different route: it "synthesizes a temporary provider and model alias from the KIMI_MODEL_* variables in memory — nothing is written back to the config file". For example:

export KIMI_MODEL_NAME="kimi-k2.5"
export KIMI_MODEL_API_KEY="$MOONSHOT_KEY"
export KIMI_MODEL_PROVIDER_TYPE="kimi"
kimi -p "Summarise the changes on this branch"

You need to set both KIMI_MODEL_NAME and KIMI_MODEL_API_KEY. If you set only the name, the CLI fails immediately at startup with a clear error saying a required part is missing.

There are also a few optional variables: KIMI_MODEL_BASE_URL, KIMI_MODEL_PROVIDER_TYPE (kimi, anthropic or openai) and context and thinking settings.

So basically, if you want to run the CLI from CI, use this env-var channel. That way you don't need a config file holding credentials, and the secret is bound to the job environment rather than stored on the runner. If for some reason you really do need a config file, set KIMI_CODE_HOME to a per-job directory so it dies with the runner:

export KIMI_CODE_HOME="$RUNNER_TEMP/kimi"

One more thing to keep out of your artifacts. Kimi's own security note says session directories, wire files and task records "may contain user prompts, command output, repository paths, tool return values, or traces of credentials". All of those live under KIMI_CODE_HOME — so don't upload that directory as a build artifact.