Weights and Biases Security Guide: Protecting API keys, projects and artifacts

A Weights and Biases (W&B) API key sitting in a notebook, a training script or a CI log can give whoever finds it read and write access to experiments, model artifacts and traces, and a personal key works in every organisation its owner belongs to. W&B keys turn up regularly in public code because data scientists set WANDB_API_KEY in the same places they keep training code. This guide covers how identity works across W&B Models and Weave, the organisation, team and project roles, how to replace personal keys with service accounts and federated identity, what the audit logs record, and a hardening baseline across Multi-tenant Cloud, Dedicated Cloud and Self-Managed deployments. It is for ML platform owners and identity teams. Facts are from W&B's own documentation (now hosted by CoreWeave), read from the official documentation source on 8 November 2026.

This is an independent guide from NHI Mgmt Group, based on Weights & Biases's public documentation as of November 2026. It is not sponsored or reviewed by Weights & Biases. Product features change, so confirm settings against Weights & Biases's current documentation.

Key takeaways

• Personal keys travel. W&B states a personal API key reaches every organisation its user belongs to. On Multi-tenant Cloud Enterprise, Enforce organization-scoped API keys stops a key leaked elsewhere from reaching your organisation.
• Automation belongs to service accounts. Team-scoped service accounts limit a pipeline to one team's projects; organisation-scoped ones reach every non-restricted project and should be rare.
• Keyless is available. Identity federation (preview, Enterprise licence) exchanges a short-lived JWT from your identity provider for a W&B access token, removing long-lived keys from CI.
• Project visibility is the data boundary. Open and Public projects are readable by anyone who knows about them; use Enforce private projects and Restricted scope for sensitive work.
• Rotation is replace and delete. W&B has no single rotate action and an exposed key stays valid until you delete it, so delete first when a key is public.

How identity and access work in Weights and Biases

A W&B organisation contains teams (also called entities), and teams own projects, which hold runs, artifacts, reports and Weave traces. People sign in to the web app; code authenticates with an API key or a federated token. Those are separate paths and need separate controls.

Provisioning: users join by invitation, by auto-provisioning through SSO (W&B's just-in-time provisioning, which assigns the Member role by default and is on by default for Dedicated Cloud and Self-Managed), or by domain capture. The SCIM API, compatible with Okta and Microsoft Entra, provisions and deprovisions users, manages team membership and defines custom roles. Use SCIM where available so leavers lose app access automatically, then remember that their API keys need separate handling.

Encryption and storage: on Dedicated Cloud, W&B encrypts each instance's managed database and object storage with a unique W&B-managed cloud-native key; customer-supplied keys are reviewed only by exception, and W&B warns it is not liable for data loss if a customer revokes such a key. With BYOB, files such as artifacts, media and run files go to your bucket through pre-signed URLs, while metadata, reports, experiment logs, system metrics and console logs remain in W&B's central database. Console logs are where secrets printed by training code end up, so BYOB does not remove the need to keep secrets out of output.

Availability: W&B's documentation lists the Viewer and View-Only roles, custom roles, service accounts, SSO on Multi-tenant Cloud, audit logs on Multi-tenant Cloud and identity federation as Enterprise features. Enforce organization-scoped API keys is a Multi-tenant Cloud Enterprise setting enabled per organisation. Disable API key creation needs Dedicated Cloud or Self-Managed v0.84.0 or later.

Admin roles and privileged access

Organisation Admins hold the keys to everything, including every organisation service account key in the API Keys tab. W&B recommends more than one Admin so the organisation is never locked out; keep the number small, put them behind SSO with phishing-resistant MFA, and review them quarterly. Team Admins can delete artifacts and runs, which matters for model integrity, not only confidentiality: a compromised team admin can remove or replace a model artifact that downstream deployment pulls. Project level roles (preview) let a user's role in a Team or Restricted project differ from their team role; use them to give reviewers View-Only on one sensitive project rather than widening team roles. See the Securing AI Model Weights.

Integrations, API tokens and service accounts

Key types

Service accounts: organisation Admins create organisation-scoped service accounts, which need a default team; team Admins create team-scoped ones. W&B's own best practices are to store keys in a secrets manager, prefer team scope, create one service account per workflow (for example ci-model-training and nightly-eval-pipeline), audit regularly, and set WANDB_USERNAME or WANDB_USER_EMAIL to attribute runs triggered by people through shared automation. On Dedicated Cloud and Self-Managed v0.83.0 and later, setting GORILLA_DISABLE_TEAM_SERVICE_ACCOUNT_CREATION to true stops team admins creating new team service accounts, which centralises issuance.

Identity federation: an organisation Admin registers a JWT issuer under Settings, Authentication, Set up JWT Issuer. W&B reads the issuer's OIDC discovery document and JWKS, based on RFC 7523. The SDK reads the token from the file named in WANDB_IDENTITY_TOKEN_FILE and exchanges it for a W&B access token, stored by default at ~/.config/wandb/credentials.json. W&B validates the signature, iss (must equal the configured issuer), sub (the user's email, or the Subject configured for an external service account), aud (the organisation name) and exp. External service accounts are created in the team's Service Accounts tab with Federated Identity as the authentication method; the Subject match is exact and case-sensitive. W&B warns not to paste JWTs into third-party online decoders, because a JWT is a credential. Note that the cached access token file is itself a credential on the runner.

Key handling: W&B's guidance is to pass keys through the WANDB_API_KEY environment variable, never commit them, never keep them in plain-text configuration, never pass them on the command line (where ps shows them) and never send them by chat or email. Treat W&B keys as non-human identities with an owner, a purpose in the key name, and a review date. See the API Key Management Guide.

Restricting how keys are created and used

• Enforce organization-scoped API keys (Multi-tenant Cloud Enterprise, Settings, Authentication): only organisation API keys and organisation service account keys reach your resources. W&B warns that personal keys lose access immediately, so inventory integrations first.
• Disable API key creation (Dedicated Cloud and Self-Managed v0.84.0+, Privacy, Access Control): users and team service accounts cannot create keys; organisation service accounts still can and existing keys keep working.
• API Keys tab: lists key name, key ID, owner, Last used and Created on. Last used is the fastest way to find dormant keys to delete.

Weave traces

Weave stores LLM and agent traces, which often contain prompts, retrieved documents and user data. The Weave Python SDK's Sensitive Data Protection feature, enabled with weave.init("project", settings={"redact_pii": True}), uses Microsoft Presidio to redact entities such as EMAIL_ADDRESS, CREDIT_CARD and IP_ADDRESS before traces leave the process; redact_pii_fields and redact_pii_exclude_fields tune the list. It is Python SDK only and does not detect API keys, so keep secrets out of traced function arguments. Tracing can be turned off with the WEAVE_DISABLED environment variable in environments where it should not run.

Logging and detection

Audit logs are JSON. On Dedicated Cloud and Self-Managed they sync to the instance-level bucket every 10 minutes and are also available through the Audit Logging API at /admin/audit_logs; on Multi-tenant Cloud they are Enterprise only and available only through the API. Only organisation-level admins, or a service account with adequate permissions, can fetch them. PII fields are returned only by the API; Dedicated Cloud and Self-Managed admins can exclude them with anonymize=true. W&B recommends transferring logs to long-term storage if you must retain them for a set period.

Outside W&B, run secret scanning on repositories, notebooks and CI logs for W&B keys, and treat a match as an incident: delete the key, then review audit logs for the key's owner over the exposure window. See the Developer Secret Scanning Triage.

Metrics:

• Share of automated runs logged by service accounts or federated identities rather than personal keys (target above 95%).
• Number of keys with no use in 90 days, from the Last used column (target zero).
• Number of organisation-scoped service accounts, each with a named owner.
• Count of Open or Public projects in the organisation (target zero unless approved).
• Mean time from a secret scanning hit to key deletion.
• Number of organisation Admins, trended quarterly.

Hardening baseline

1. Inventory keys and projects. As an organisation Admin, export the API Keys tab view (owner, Last used) and list projects by visibility scope. Flag personal keys used by automation and every Open or Public project.
2. Set organisation privacy settings. Turn on Enforce private projects, Disable public report sharing (which deactivates existing public links), Limit invitation privileges, Restrict invitations to claimed domain and, where code is sensitive, Disable default code saving. Consider Enforce team visibility restrictions in large organisations.
3. Move automation to service accounts. Create one team-scoped service account per workflow, store its key in your secrets manager, and add it explicitly to any restricted project it needs. Reserve organisation scope for documented cross-team jobs.
4. Pilot identity federation. Where your CI or Kubernetes platform issues JWTs, configure the issuer and an external service account for one pipeline, confirm runs log correctly, then roll out.
5. Close the personal key path. On Multi-tenant Cloud Enterprise, announce a date and enable Enforce organization-scoped API keys. On Dedicated Cloud or Self-Managed, enable Disable API key creation and GORILLA_DISABLE_TEAM_SERVICE_ACCOUNT_CREATION once central issuance works.
6. Restrict sensitive projects. Use Restricted scope for projects with regulated data or production models, and project level roles for reviewers.
7. Protect the network. On Dedicated Cloud, use private connectivity for workload traffic and IP allowlisting with corporate egress CIDR ranges for administration, as W&B recommends.
8. Turn on Weave redaction for traced applications handling personal data, and stream audit logs to your SIEM.

Rollback: Enforce organization-scoped API keys can be switched off from the same Authentication page (Disable), and Disable API key creation is a toggle that leaves existing keys working, so both are low-risk to trial. Rotation should overlap old and new keys only briefly, as W&B advises.

Small versus large teams: a small team on a non-Enterprise plan without service accounts or SSO should give each automation its own dedicated W&B user where licensing permits, keep projects at Team scope, store keys in a secrets manager, and review keys monthly. Larger organisations should use SCIM, service accounts or federation for all automation, privacy enforcement at organisation level, and audit log monitoring.

Framework mapping

Common misconfigurations

• Personal keys in shared notebooks and CI. The key leaves with the notebook, works across every organisation its owner joins, and attributes all activity to one person.
• Keys passed on the command line or printed. They land in shell history, ps output and console logs, which W&B stores in its central database even with BYOB.
• Open or Public projects by default. Experiments, configs and artifacts become readable by anyone who finds the project; Open projects also accept runs from anyone.
• Organisation-scoped service accounts for convenience. One leaked key then reaches every non-restricted project in every team.
• Deleting a leaked key last. W&B states an exposed key stays valid until deleted; teams that wait to update every job first leave the key live.
• Weave tracing raw prompts. Without redaction, traces keep customer data and any secret that reached a traced function.

Practitioner checklist

• Enable SSO and SCIM, and keep organisation Admins to a small reviewed group with phishing-resistant MFA.
• Move every pipeline to a team-scoped service account or identity federation; one identity per workflow.
• Enforce organisation-scoped API keys (Multi-tenant Cloud) or disable API key creation (Dedicated Cloud, Self-Managed).
• Delete keys unused for 90 days using the Last used column.
• Turn on Enforce private projects and Disable public report sharing; use Restricted scope for sensitive projects.
• Add W&B key patterns to secret scanning and delete exposed keys immediately.
• Enable Weave redact_pii for applications handling personal data.
• Fetch audit logs into your SIEM and alert on key creation, service account creation and Admin grants.

Standards and references

• W&B documentation: Manage API keys
• W&B documentation: Use service accounts to automate workflows
• W&B documentation: Use federated identities with SDK
• W&B documentation: Manage your organization
• W&B documentation: Configure privacy settings
• W&B documentation: Track user activity with audit logs
• IETF: RFC 7523 JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: API Key Management Guide · Developer Secret Scanning Triage · Securing AI Model Weights · Secrets Management Guide