What breaks when Claude Code users manage their own API keys?

Why This Matters for Security Teams

Per-user api key turn Claude Code from a controllable workload into a collection of individual trust edges. That matters because the blast radius is no longer limited by a central policy layer. Instead, each developer, device, repo, and token becomes a separate path to model access, billing, and data movement. NIST’s NIST Cybersecurity Framework 2.0 expects governance, inventory, and access control to be explicit, but user-managed keys often bypass those basics in day-to-day use. NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly secrets spread once they leave a managed boundary, and AI workflows accelerate that spread because keys are copied into terminals, local config files, and automation scripts. In practice, many security teams discover the problem only after an offboarding delay, leaked key, or unexpected provider usage has already created exposure.

How It Works in Practice

When users manage their own API keys, the organisation loses the enforcement point that normally sits between the identity provider and the model service. That means security teams cannot reliably apply conditional access, usage caps, approval workflows, or provider-level logging from a single control plane. The result is weak visibility into who called which model, from where, and under what business context. The better pattern is to treat the agent or developer workflow as a governed workload, not a personal convenience layer. That usually means:

• Issuing short-lived credentials through a central broker instead of storing long-lived keys on endpoints.
• Binding access to workload identity, device posture, and approved runtime context rather than a static user token.
• Recording model usage centrally for audit, cost control, and anomaly detection.
• Revoking access automatically when employment status, device trust, or project assignment changes.

This is consistent with NIST SP 800-53 Rev. 5 expectations around account management, least privilege, and auditability, and it aligns with NHIMG guidance in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. The practical lesson is that API key ownership should sit with the organisation, while users receive narrowly scoped access to a managed broker or gateway. That preserves offboarding, logging, and policy enforcement even when the underlying model provider changes. These controls tend to break down in fast-moving developer environments where CLI tooling, local experimentation, and ad hoc scripts bypass the central gateway because convenience beats policy in the moment.

Common Variations and Edge Cases

Tighter key control often increases friction for developers, requiring organisations to balance speed against governance. There is no universal standard for this yet, especially in teams that prototype locally or use multiple model providers at once. In those environments, the main tradeoff is between rapid experimentation and the risk of secret sprawl. Some teams attempt to solve the issue with shared service keys. That reduces per-user sprawl, but it also collapses accountability and makes abuse harder to trace. Others keep per-user keys but add periodic rotation. That helps only partially, because rotation does not fix weak audit trails, delayed revocation, or uncontrolled copying into local files and CI jobs. NHIMG’s Top 10 NHI Issues highlights that lifecycle gaps are usually the real failure, not just the presence of a credential. A stronger operating model is to pair central policy with least-privilege issuance and automatic revocation, then reserve direct vendor keys for exceptional cases only. That approach is especially important when Claude Code is used alongside automation, because one leaked key can become a durable access path. In mixed human and automated workflows, direct key management by end users tends to fail when onboarding is fast, offboarding is slow, or secrets are copied into places security never intended to monitor.

Related resources from NHI Mgmt Group

• What breaks when users manage their own encryption keys?
• How should security teams govern API keys used for generative AI access?
• What problem does ownership attribution solve for service accounts and API keys?
• What challenges do unmanaged API keys pose within MCP?