The Claude SDKs make the mechanics simple: per Anthropic's authentication documentation, if the ANTHROPIC_API_KEY environment variable is set, the client libraries pick it up automatically — no key appears in your code. So credential injection in CI boils down to one question: how does that variable get populated on the build machine, without the value being stored anywhere it shouldn't be?
Two kinds of credential, two risk profiles
Anthropic's first-party API supports two authentication methods. API keys are long-lived sk-ant-api... secrets created in the Claude Console (Settings → API keys); they have no expiry, so Anthropic's guidance is to store them in a secrets manager, rotate them periodically, and revoke immediately on suspected leak. Workload Identity Federation (WIF) replaces the static key entirely: your workload exchanges a short-lived identity token from its platform for a short-lived Claude API access token, which the SDK refreshes automatically. Anthropic explicitly recommends WIF for CI/CD and lists GitHub Actions among the compatible OIDC issuers, with API keys positioned for local development, prototyping, and scripts.
Practical translation: an API key in your CI secret store is fine to start with, but a leaked build log or compromised runner then holds a credential that never expires. WIF means there is nothing long-lived to leak. Setup requires three resources in the Claude Console — a service account, a federation issuer, and a federation rule — after which the SDK is pointed at the rule. See the WIF walkthrough for details.
GitHub Actions
Store the key as an encrypted repository or organization secret, then map it into the job's environment as ANTHROPIC_API_KEY so the SDK finds it. GitHub masks registered secret values in logs, but masking is best-effort — never echo credentials or dump the environment in a step. Prefer environment-scoped secrets (e.g., a "staging" environment with required reviewers) so a fork or feature-branch build cannot reach the production key. For the keyless route, GitHub Actions can mint OIDC identity tokens that fit Anthropic's WIF flow. A full worked example lives in Using the Claude SDK in GitHub Actions.
GitLab CI
GitLab's CI/CD variables serve the same role: define ANTHROPIC_API_KEY at the project or group level, mark it masked (redacted from job logs) and protected (only exposed to pipelines on protected branches and tags). Protection matters more than masking here — it is what stops any developer's merge-request pipeline from borrowing the production credential. For larger installations, GitLab can also pull variables from an external secrets manager at job time, which keeps the value out of GitLab's own storage; consult your GitLab documentation for the integrations available on your tier.
Buildkite and SSM-style injection
Buildkite runs its agents on your own infrastructure, so the idiomatic pattern is different: don't store the key in Buildkite at all. Keep it in AWS Systems Manager Parameter Store or AWS Secrets Manager, grant the agent's IAM role read access to that one parameter, and fetch it into the ANTHROPIC_API_KEY environment variable in an agent hook at job start. The secret then lives in one auditable place, access is governed by IAM, and rotation happens without touching pipeline configuration. The same pattern applies to any self-hosted runner fleet, whichever CI product schedules it.
ANTHROPIC_API_KEY="" selects the API-key path with an empty key rather than falling through to WIF or a profile. In pipeline templates, unset variables you aren't using instead of defaulting them to blank.If you're on a cloud platform instead
Pipelines that call Claude through a third-party platform often need no Anthropic-issued secret at all. Amazon Bedrock and Claude Platform on AWS authenticate with standard AWS credentials — and the AWS default credential chain includes web identity federation, which is how a GitHub Actions job assumes an AWS role without a stored access key. Google Vertex AI uses Application Default Credentials, with an equivalent keyless federation story on the Google side. Microsoft Foundry uses a resource-scoped API key, which belongs in your CI secret store like any other. In all cases the rule is the same: prefer the platform's short-lived, identity-based credentials over long-lived pasted secrets.
Where to go next
Set up the workflow end to end in the GitHub Actions guide, then plan key rotation without downtime and secrets-manager loading in application code.