Anthropic Adds Service Accounts to Claude Console, Giving CI and Agent Workflows a Non-Human Identity
Production Claude API deployments running on individual employees' keys just got an organizational security upgrade. Anthropic updated its Console on August 28 to make service account keys a first-class option, per its platform documentation: CI pipelines and agent workflows now get a named, non-human identity that does not expire when an employee leaves the company.
What changed
Anthropic's updated platform documentation describes three key types available in Settings > API keys:
- A personal key acts as the authenticated developer and stops working if that person leaves the organization.
- A service account key is tied to a service account (identified with an
svac_prefix in the Console), a named, non-human identity at the organization level. It is the prescribed type for any shared workload or automated pipeline. - A workspace key is the legacy type. It has no named owner and belongs to the workspace, so it continues to function after its creator leaves. Anthropic's documentation now explicitly recommends against issuing new workspace keys.
Service accounts live at the organization level and gain access to specific workspaces when added as workspace members. That workspace membership controls rate limits and usage attribution, identical to a human API key. Unlike workspace keys, a service account key stops working only when the service account itself is deleted, not when any individual account is removed.
The service account model also unlocks Workload Identity Federation (WIF). Rather than storing a static API key, workloads can authenticate by exchanging a short-lived OIDC token from their identity provider. AWS IAM, Google Cloud, GitHub Actions, Kubernetes, and any standards-compliant OIDC issuer are all supported. Anthropic's WIF documentation describes the full setup, including a guided "Connect workload" wizard in the Console that creates the issuer, service account, and federation rule in a single flow.
Why it matters
The workspace key model left teams with two unpleasant options: tie production services to a named individual's account (creating a fragile dependency on that person staying) or use an ownerless workspace key with no clear audit identity. Neither option satisfied enterprise security reviews that require non-human principals in IAM policies.
Service account keys resolve both problems. Automated workloads get a stable identity that does not depend on any individual remaining employed. Audit logs distinguish service account API calls from human developer calls by principal name. For teams building multi-step agent workflows or CI pipelines that call Claude at production scale, this removes a recurring objection from security and compliance reviewers.
WIF goes further: no static secret to rotate, store, or leak. Teams that already use WIF for AWS or GCP services can apply the same keyless pattern to their Claude API workloads.
What to watch next
Anthropic's Admin API already supports programmatic management of service accounts, federation issuers, and federation rules, per the WIF documentation. Watch for whether Anthropic adds Admin API endpoints for creating and rotating service account API keys directly. That step would complete a full infrastructure-as-code path for teams managing Claude API access at scale.
Teams currently using workspace keys in production should audit their key inventory in the Console at Settings > API keys. The workspace key type continues to function, but service account keys carry a cleaner IAM posture for new workloads.
Sources
- Get your Claude API key - Anthropic Platform Docs: primary documentation on key types, per Anthropic
- Workload Identity Federation - Anthropic Platform Docs: service account and keyless authentication reference, per Anthropic
