Treat it as a non-human identity problem. Use enterprise SSO, RBAC, and centralized gateway policy so access is revocable, auditable, and consistent across users and devices. If developers can point the tool directly at a provider with local credentials, governance becomes fragmented and offboarding remains incomplete.
Why This Matters for Security Teams
Claude Code should be governed like any other high-impact non-human identity, not like a personal developer convenience tool. The risk is not just who can launch it, but what it can reach once authenticated. If access is tied to local credentials or ad hoc provider logins, teams lose centralized revocation, consistent policy, and auditability across devices and accounts.
That pattern shows up in broader NHI failures as well. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges and only 20% of organisations have formal processes for offboarding and revoking API keys. Those conditions matter here because AI coding tools can blend developer workflow, secrets access, and automated action in a single session. Security teams should also anchor the governance model in OWASP Non-Human Identity Top 10, which frames overprivilege, weak lifecycle control, and secret exposure as core NHI risks.
In practice, many security teams discover the governance gap only after a developer leaves, a token remains live, or an agentic tool has already accessed systems that no one expected it to reach.
How It Works in Practice
The practical goal is to make Claude code access centrally issued, centrally observed, and centrally revocable. That starts with enterprise SSO so the individual developer session is tied to a managed corporate identity, then layers RBAC for coarse entitlement and gateway policy for request-level control. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward governed access, asset visibility, and continuous monitoring rather than one-time setup.
For teams with multiple projects or security tiers, the best pattern is to avoid direct provider credentials on endpoints. Instead, route Claude Code through a centralized gateway or broker that can enforce which repositories, tools, environments, and data classes are allowed for a given team, device posture, and task. NHI Management Group’s Analysis of Claude Code Security highlights why this matters: once the tool can act directly against external services, governance fragments across local auth, developer machines, and provider-side permissions.
- Use SSO as the primary authentication layer, not shared API keys.
- Bind access to team membership and project scope through RBAC.
- Issue short-lived tokens or session-bound credentials where possible.
- Log every tool call, repository touchpoint, and privilege escalation attempt.
- Revoke access from one control plane, not from each developer workstation.
This model works best when the gateway can inspect context in real time and deny unsafe tool use before execution. These controls tend to break down in unmanaged local setups, where developers can bypass the gateway and authenticate directly to upstream AI or code-hosting services.
Common Variations and Edge Cases
Tighter Claude Code governance often increases workflow friction, so organisations have to balance developer speed against blast-radius reduction. That tradeoff is real, especially when teams want fast experimentation but also need audit-ready controls for production repositories and regulated data.
Best practice is evolving on how far to go beyond SSO, RBAC, and gateway policy. Some teams will need repository allowlists, data-loss controls, and environment-based restrictions; others may only need a lighter approval model for low-risk use cases. The current guidance suggests that the more autonomous the tool use becomes, the less effective static rules are on their own and the more important runtime policy becomes. That aligns with the broader lifecycle and offboarding emphasis in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the risk framing in Top 10 NHI Issues.
Edge cases include contractor access, multi-tenant engineering groups, and hybrid environments where some developers still need direct provider access for testing. In those environments, security teams should treat exceptions as time-bound and monitored, not as a separate normal path. There is no universal standard for this yet, but the safest approach is to keep exceptions narrow, logged, and automatically expired.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 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 Agentic AI Top 10 | AI-01 | Claude Code is an autonomous tool with execution authority and tool access. |
| CSA MAESTRO | GOV-02 | MAESTRO covers governance for agentic AI access, review, and oversight. |
| NIST AI RMF | GOVERN | AI RMF GOVERN applies to accountability, roles, and oversight for AI-enabled workflows. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Direct credentials and weak lifecycle handling are core NHI governance risks. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management fits team-wide Claude Code governance. |
Constrain agent tool use to approved actions and require runtime authorization for each step.
