Claude Code Security exposes the identity gap behind faster development

At a glance

What this is: Claude Code Security is presented as an AI-driven code scanning capability, and the article argues that its real significance is exposing the identity and Shadow SaaS risks created by faster agentic development.

Why it matters: IAM, IGA, and NHI teams need to treat agentic coding as an identity expansion problem as much as an application security problem, because unmanaged developer tools and residual accounts enlarge attack surface outside the core directory.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Unixi's analysis of Claude Code Security and the identity gap

Context

Claude Code Security is a code-scanning capability embedded in an agentic coding workflow, so the immediate question for practitioners is not whether it can identify application defects but whether their identity controls can keep pace with the tools developers now create, adopt, and abandon around it. The primary issue is not code quality alone; it is the identity perimeter around the code.

The article’s central claim is that speed from AI-assisted development creates a Shadow SaaS and offboarding problem. When developers can spin up niche tools, staging platforms, and browser-based accounts faster than procurement and IAM can govern them, the enterprise ends up with access paths that sit outside SAML, lifecycle review, and central visibility.

That is a familiar pattern in modern identity programmes. Application security may improve, but if surrounding tools still depend on passwords, shared logins, and residual accounts, the risk simply moves sideways into uncontrolled non-human and human-managed access edges.

Key questions

Q: How should security teams govern agentic IDEs in development environments?

A: Security teams should govern agentic IDEs like any other identity-bearing runtime, starting with inventory, privilege scope, and tool reach. Assign the narrowest possible credentials, segment production from sandboxes, and make autonomy settings part of the policy model. The goal is to control what the agent can touch, not just how the interface looks.

Q: Why do non-federated developer apps create more risk than standard SaaS?

A: They push users toward local passwords, shared accounts, and browser-stored credentials, which are much harder to govern centrally. Those access paths often sit outside recertification and offboarding workflows, so a single unmanaged app can become a persistence point even when the main corporate directory remains protected.

Q: What breaks when offboarding only disables the primary account?

A: The lifecycle control remains incomplete. Users may still have active sessions, linked app permissions, or residual access through connected systems, which means the organisation records termination without actually ending access. That is a governance failure because it creates a false sense of closure and leaves exposure behind.

Q: Who should own the risk created by shadow SaaS in engineering teams?

A: Ownership should sit across IAM, IGA, security engineering, and application platform teams. The risk is created by human behaviour but expressed through non-human identities and unmanaged tool access, so a single control owner will miss part of the chain. Governance needs one accountable process, not separate silos.

Technical breakdown

How agentic coding expands the shadow SaaS surface

Agentic coding tools increase the rate at which developers create supporting services, test environments, and short-lived browser-based applications. That growth matters because identity governance normally depends on catalogued assets, approved access patterns, and predictable joiner-mover-leaver handling. When a tool is created ad hoc to support a code task, it often lands outside procurement, outside the directory, and outside recertification. The result is not merely more software, but more identities, more passwords, and more unmanaged trust edges around the development pipeline.

Practical implication: teams need visibility into developer-spawned apps and accounts before those assets become permanent exceptions.

Why non-SAML apps become identity weak points

Traditional IdPs work best when applications support enterprise federation and central policy. Many niche developer tools and AI infrastructure platforms do not, or they place SSO behind commercial friction that pushes users back to local passwords. That creates a separate identity plane where shared credentials, browser-cached logins, and reused passwords become the default. In practice, the code environment may be governed, but the systems around it are not. Attackers often target those less protected edges because they are easier to phish, stuff, or reuse than the primary corporate directory.

Practical implication: prioritise non-federated developer tools for access discovery and password elimination.

Why offboarding fails when residual accounts outlive the employee

Offboarding usually assumes that disabling the primary corporate identity also removes effective access. That assumption breaks when employees have created or used multiple external accounts during development work. Those residual accounts may still hold administrative rights, linked passwords, or cached browser sessions long after the person has left. The enterprise sees a completed HR workflow, but the access graph remains active in the surrounding SaaS layer. This is a lifecycle governance failure, not an isolated technical oversight.

Practical implication: offboarding must include external account discovery and verification, not just directory deprovisioning.

Threat narrative

Attacker objective: The attacker wants to reach the developer pipeline through unmanaged identities and then reuse those access paths for persistence or lateral movement.

1. Entry begins when developers adopt browser-based, non-approved tools to support agentic coding workflows and authenticate with local passwords instead of federated access.
2. Escalation occurs when those tools become part of the build, test, or deployment chain and shared or cached credentials are reused across systems outside central visibility.
3. Impact follows when offboarded users leave behind residual accounts that remain live and provide an unmonitored path back into the development environment and related infrastructure.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Claude Code Security does not close the governance gap created by agentic development. It improves code-level analysis, but the article shows that the bigger risk sits outside the scanner: developers are creating shadow SaaS, unmanaged passwords, and residual access paths while shipping faster. That means the security boundary is shifting from code defects to identity sprawl, and practitioners need to treat the surrounding toolchain as part of the control plane.

Identity perimeter control is now a development governance issue, not only an IAM issue. When AI-assisted coding normalises rapid adoption of non-federated tools, traditional directory-centric controls stop seeing a large part of the access graph. The practical consequence is that application security, IAM, and IGA have to work as one operating model. Teams that separate them will keep fixing code while missing the accounts that operate the code.

Residual accounts are the real offboarding failure mode in agentic workflows. The article’s offboarding example shows that deactivating the primary employee identity is not equivalent to removing effective access. Shared logins, browser-cached sessions, and external tool accounts can persist after employment ends, which means accountability and access diverge. Practitioners should interpret this as a lifecycle governance break, not an exception path.

Shadow SaaS created by developers is a non-human identity problem with human roots. The governance issue begins with people making fast tool choices, but the risk materialises through machine-managed logins, service accounts, and residual credentials. That is why NHI governance and human IAM cannot be separated in modern engineering environments. The control model has to cover both the person who creates the tool and the identity that survives after the person moves on.

Runtime reasoning in code tools increases the speed of drift, but not the completeness of governance. The article frames AI coding as a productivity gain, yet the identity programme still has to answer who owns the surrounding access, how it is reviewed, and when it is removed. That is the core operating question for security teams now: if development accelerates, identity governance must become continuous rather than periodic.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That gap is one reason to review the Ultimate Guide to NHIs alongside lifecycle controls for externally created accounts.

What this signals

Shadow SaaS drift: as agentic coding makes it easier to stand up support tools on demand, governance teams should expect the identity perimeter to expand faster than procurement can catalogue it. The practical response is to treat developer tool discovery as an access management input, not a hygiene project, and to connect it to lifecycle review before residual accounts accumulate.

The programme signal is clear: if a developer can create an external tool in minutes, the access attached to that tool must be governable at the same speed. That is why lifecycle review, external account visibility, and password elimination now belong in the same control conversation, especially in engineering environments where browser-based access is the default.

For practitioners

• Map developer-spawned SaaS and test tools Build an inventory of browser-based applications, staging tools, and niche developer platforms created outside procurement so access can be reviewed before it fragments the identity perimeter.
• Prioritise federation for non-SAML developer tools Target the tools most likely to fall back to local passwords or shared logins and move them toward central access control, even when vendor integration is limited.
• Extend offboarding beyond the directory Require verification that external accounts, cached browser sessions, and shared credentials tied to the departing user have been identified and disabled.
• Treat shadow SaaS as an IGA control gap Route developer tool discovery into access review, exception management, and entitlement ownership so unmanaged apps do not become permanent blind spots.

Key takeaways

• Agentic coding improves development speed, but it also multiplies unmanaged applications and accounts around the codebase.
• The most material failure mode is not a bad build artifact, but a residual identity that survives offboarding and preserves access.
• Teams need one governance model that covers developer-created SaaS, external credentials, and offboarding verification across IAM and NHI controls.

Key terms

• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.
• Residual Account: A residual account is an external or secondary identity that remains active after the original user, project, or workflow should no longer need it. These accounts are especially risky in modern development environments because they can preserve access long after directory offboarding appears complete.
• Identity Perimeter: The identity perimeter is the access boundary defined by who or what is requesting entry, not by where the request comes from. In zero trust, it is the point where authentication, authorization, and risk context decide whether a caller can proceed.
• Developer-Spawned Access: Developer-spawned access is any account or permission created as a side effect of engineering work rather than a formal access request. It often bypasses standard review because it is created quickly to support delivery, then survives as a blind spot when the project or employee changes.

What's in the full article

Unixi's full article covers the operational detail this post intentionally leaves for the source:

• The mechanics of its browser-based access control approach for non-SAML applications
• How its continuous discovery is intended to surface shadow SaaS created by developers
• The workflow it describes for eliminating passwords from developer authentication
• The lifecycle handling it claims for residual accounts after employee offboarding

👉 Unixi's full post covers shadow SaaS discovery, residual accounts, and its access control approach in more detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.