Direct keys make it hard to see who spent what, which models were used, and whether access is still appropriate. They also tend to spread into shell profiles, config files, and personal machines. A gateway lets teams enforce budget limits, revoke access centrally, and avoid persistent provider credentials sitting outside governed infrastructure.
Why This Matters for Security Teams
Direct developer api key are manageable when one person is experimenting, but they become a governance problem the moment Claude Code is used by a team. The issue is not just leakage risk, but loss of control over attribution, scope, and revocation. A key that lives in a personal shell profile or laptop is effectively outside central policy, which means finance, security, and engineering cannot reliably answer who used it, for what purpose, or whether it is still justified.
That shift matters because AI-assisted development tends to increase both usage frequency and distribution of credentials. NHIMG research on the State of Secrets Sprawl 2026 found Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%. This is why teams need to treat provider keys as governed production secrets, not convenience tokens. The control problem is similar to the patterns described in the NIST Cybersecurity Framework 2.0: identity, visibility, and continuous control all matter.
In practice, many security teams discover the exposure only after a key has spread through personal devices and automation scripts, rather than through deliberate access design.
How It Works in Practice
The safer pattern is to stop giving every developer a direct long-lived provider key and instead route team usage through a controlled gateway or broker. That gateway becomes the enforcement point for budget limits, model allowlists, logging, and revocation. It also creates a clean separation between developer intent and provider access, which is essential when multiple people are using Claude Code across different machines and environments.
At a practical level, teams should assign access through centrally managed identities, then issue scoped, short-lived credentials only when needed. This aligns with the broader secret hygiene guidance in NHIMG’s Guide to the Secret Sprawl Challenge. The operational flow usually looks like this:
- Developers authenticate to the gateway with their corporate identity, not a shared provider key.
- The gateway issues temporary access or exchanges identity for a scoped token tied to the task, project, or budget.
- Requests are logged centrally so usage can be attributed to a person, team, or workload.
- Revocation happens at the gateway, which cuts off access without hunting through shell configs, dotfiles, or laptops.
- Provider credentials remain inside governed infrastructure, reducing the chance they are copied into local tooling.
This model is also easier to align with standard control frameworks such as NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially where least privilege, auditability, and configuration management are required. Teams that want a real-world cautionary example can look at the BeyondTrust API key breach, where key handling failures became an operational security issue.
These controls tend to break down in heavily ad hoc environments where developers can bypass the gateway and inject keys directly into local tools, container images, or unmanaged CI jobs.
Common Variations and Edge Cases
Tighter gateway control often increases friction for developers, so organisations need to balance usability against the reduction in secret sprawl. That tradeoff becomes more pronounced when teams are experimenting rapidly, using multiple models, or running local-first workflows. Current guidance suggests that if direct keys are unavoidable for a narrow use case, they should still be time-bound, individually attributable, and quickly revocable rather than treated as permanent personal credentials.
There is no universal standard for this yet, but best practice is evolving toward per-user or per-workload isolation, budget caps, and usage policies that are enforced before the request reaches the provider. This is especially important because provider keys often escape into places security teams do not monitor closely, including terminal history, package manager configs, and sync folders. The risk is not hypothetical: NHIMG’s Cisco DevHub NHI breach and related research show how exposed credentials can move from convenience to incident very quickly.
For teams evaluating this transition, the central question is whether the environment can reliably prevent local bypasses and enforce revocation centrally. If not, direct keys will keep behaving like hidden standing privileges, which is exactly what governed team usage is trying to eliminate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Direct keys create long-lived secret exposure and weak revocation. |
| OWASP Agentic AI Top 10 | A1 | Claude Code behaves like a tool-using agent with expandable access paths. |
| CSA MAESTRO | IAM-03 | Covers identity and access control for autonomous and semi-autonomous workloads. |
| NIST AI RMF | Risk governance is needed when AI-assisted workflows use external APIs. | |
| NIST CSF 2.0 | PR.AC-1 | Access control and credential governance are central to this risk. |
Gate agent access through runtime policy and scoped credentials, not static secrets.
