Claude security risks are now an IAM and NHI problem

At a glance

What this is: Akto argues that Claude’s expansion into connected enterprise workflows turns it into an identity and governance problem, not just an AI productivity issue.

Why it matters: IAM, IGA, PAM, and security teams need to govern who or what can connect Claude to data and tools before hidden access becomes unreviewable NHI exposure.

By the numbers:

• Snyk audited nearly 4,000 agent skills and found over a third had at least one security flaw.
• Veracode's testing found that in 52% of coding tasks, Claude's latest Opus model produced code containing a vulnerability.

👉 Read Akto's analysis of Claude security risks and identity governance gaps

Context

Claude security is increasingly an identity governance issue because the platform is no longer limited to text generation. Once it can read local files, run shell commands, browse with session cookies, and connect to enterprise systems, the control question shifts to which identities, secrets, and permissions are being extended into AI workflows.

The primary gap is visibility. Organisations may not know where Claude is in use, which projects store sensitive information, which connectors are active, or whether those access paths were ever approved. For IAM, NHI, and PAM teams, that creates unmanaged access across both human and non-human workflows.

For agentic AI programs, the risk is compounded because connector-enabled assistants can operate across tools that were never designed for autonomous coordination. That is why Claude governance must sit at the intersection of identity, data control, and execution monitoring rather than inside an isolated AI policy silo.

Key questions

Q: How should security teams govern Claude deployments that can act through tools and APIs?

A: Treat Claude as a governed identity surface, not just a model endpoint. Define the approved owner, the exact tools it may call, the data it may touch, and the downstream systems that must enforce authorisation. Without those boundaries, the model can inherit access that was never intended for autonomous execution.

Q: Why do connected AI assistants increase IAM and NHI risk?

A: Because they turn a single user-facing tool into a delegated access path across multiple systems. OAuth scopes, session cookies, and connector tokens can outlive the immediate task, which expands blast radius and creates unmanaged non-human access that traditional app controls rarely track well.

Q: What breaks when AI projects are treated like disposable chats?

A: Retention, access review, and data-loss controls fail because project workspaces often hold persistent documents, connectors, and shared context. If teams assume the content disappears like a prompt, they miss the fact that sensitive material may remain accessible through connected enterprise identities.

Q: How should security teams govern AI-generated code in production environments?

A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.

Technical breakdown

Shadow Claude usage creates ungoverned identity paths

Shadow usage appears when employees adopt Claude outside formal IT review, often by connecting it to local files, browser sessions, or enterprise tools with their own credentials. The security issue is not the model itself but the identity chain behind it: user sessions, OAuth grants, and token-bearing integrations can all become invisible access paths. Once those paths exist, standard approval workflows lose coverage because the organisation never established an authoritative inventory of where the AI was connected or what it could reach.

Practical implication: Treat AI adoption as an identity discovery problem and inventory Claude usage before you can govern it.

MCP connectors extend blast radius across enterprise tools

Model Context Protocol connectors let Claude act across systems such as Slack, GitHub, Jira, and cloud storage by using authenticated integrations. That changes the trust model from isolated prompt input to delegated tool access, which means OAuth scopes, connector permissions, and token lifecycle now matter as much as model behaviour. If those boundaries are not tightly reviewed, a compromised workflow or over-permissioned connector can expose multiple systems through a single AI session.

Practical implication: Review every enabled connector as a privileged integration and tie it to explicit approval and scope control.

AI-generated code and skills introduce supply-chain exposure

Claude Code skills and generated code create a delivery path where plain-language instructions, reusable workflow bundles, and machine-produced source all enter the development chain. The problem is that hidden instructions can be embedded in skills, and insecure code can be produced at scale without sufficient human review. This is a supply-chain issue because the output can move directly into repositories, pipelines, or production systems with the same trust as human-authored work unless security gates intervene.

Practical implication: Apply secure development controls to AI output and third-party skills before they enter repositories or pipelines.

Threat narrative

Attacker objective: The attacker aims to turn trusted AI usage into a multi-system access path that exposes sensitive data, secrets, or production-changing actions.

1. Entry occurs when employees use Claude outside sanctioned governance and connect it to files, sessions, or enterprise systems with existing credentials. Escalation happens when MCP connectors and reusable skills inherit permissions that were never designed for AI-mediated tool use. Impact follows when compromised workflows, vulnerable code, or hidden instructions expose data, execute commands, or propagate insecure changes into production paths.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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 security has crossed from application risk into identity governance risk. Once the system can open files, use shell commands, and connect to enterprise tools, the real control question becomes who authorised the underlying access and whether that access was ever inventoried. Traditional app governance is too shallow for this problem because the exposure sits in user sessions, OAuth scopes, and connected identities. Practitioners should treat Claude as part of the enterprise identity plane, not a standalone productivity app.

Shadow AI in connected assistants is really shadow NHI growth. When employees bind AI tools to Slack, GitHub, databases, or cloud data, each connection creates a non-human access path that may persist beyond the original use case. That is not a policy problem alone, it is an access-lifecycle problem. Connector trust debt: the organisation accumulates delegated access that no one continuously reviews, so the blast radius expands quietly across the environment. Security teams need to see these connectors as governed identities with ownership, scope, and offboarding.

Autonomous collaboration changes the governance model even when the model is not fully autonomous. Claude may still be constrained, but the moment it begins chaining tools and workflows across tasks, the security conversation moves from monitoring user prompts to controlling execution boundaries. That is why agentic AI governance frameworks matter here: they help teams reason about tool selection, delegated action, and accountability when the human is no longer the only actor in the workflow. The implication is that IAM controls must extend into runtime behaviour, not stop at login.

AI-generated code makes identity risk operationally visible in the software supply chain. If a model can write vulnerable code in more than half of tasks, as cited in the source article, then code review alone is not enough unless the organisation also controls which identities can introduce AI output into pipelines. The governance failure is not simply insecure code, but the absence of a gate that treats AI-generated changes as privileged material. Practitioners should reclassify AI coding paths as controlled delivery channels, with the same scrutiny applied to sensitive admin workflows.

From our research:

• While 71% of IT teams have been advised on AI agent data access, only 47% of compliance teams, 39% of legal teams, and 34% of executives have the same visibility, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• For a practical control lens, see OWASP Agentic AI Top 10 for the risk patterns that emerge when AI systems chain tools and actions without sufficient governance.

What this signals

Connector trust debt: organisations will keep accumulating delegated AI access unless they formalise connector ownership, review cycles, and offboarding for each integration. The governance pattern is familiar from NHI sprawl, but the operational trigger is now employee-led AI adoption rather than infrastructure rollout. Teams that already map secrets and service accounts should extend that discipline to AI connectors and linked workspaces.

The next control failure will be assuming that user approval for a tool equals governance approval for the connected systems behind it. That assumption does not hold once Claude can touch production-adjacent data, source repositories, and browser-authenticated sessions. IAM leaders should expect audit requests to shift from login events to delegated-action evidence and connector inventories.

For agentic AI programmes, the immediate priority is deciding which use cases are allowed to carry enterprise context at all. The more Claude behaves like an operating layer for work, the more its access patterns resemble governed NHI behaviour, which means identity, monitoring, and data controls must be designed together rather than bolted on after adoption.

For practitioners

• Inventory every Claude entry point Map usage across claude.ai, desktop, Code, and any embedded workflows. Record which business units, user groups, and service identities can invoke the tool so you can establish ownership before access sprawl becomes permanent.
• Review connector scopes as privileged access Audit all MCP connectors, OAuth grants, and integration tokens tied to Claude. Disable any connector without an owner, a documented purpose, and a current security review, and require reapproval when scopes change.
• Classify Claude projects as persistent data stores Apply data governance and DLP rules to projects that hold documents, shared prompts, or external data. Treat uploaded content as retained enterprise data, with access review and retention controls instead of assuming chat-style ephemerality.
• Extend secure development gates to AI output Require review of AI-generated code, reusable skills, and agent instructions before they can reach repositories or pipelines. Use the same approval discipline for AI-authored changes that you already apply to privileged code paths.
• Establish audit trails for AI-mediated actions Log connector use, document access, token activity, and downstream actions taken by Claude across enterprise systems. Without auditability, investigations cannot reconstruct which identity, permission, or session created the exposure.

Key takeaways

• Claude usage is no longer just a productivity choice because connectors, sessions, and projects can create governed identity exposure across enterprise tools.
• The source article’s data shows a real visibility gap, with AI access and auditability lagging behind adoption across compliance, legal, and executive teams.
• Practitioners should inventory Claude, control connector scopes, and apply secure development gates to AI output before the access model becomes irreversible.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Connector scope: The exact permissions and environmental reach granted to an integration that links a workflow to another system. For chat-driven automation, connector scope defines what the workflow can read, change, publish, or deploy, and it should be treated like privileged access rather than a convenience setting.
• AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

• Specific examples of how Claude is being used across employee workflows and team functions
• Stepwise governance guidance for shadow AI discovery, connector review, and project oversight
• Practical controls for reviewing AI-generated code before it enters development pipelines
• Additional discussion of the new AI agent identity security maturity model mentioned in the article

👉 Akto's full post covers shadow AI discovery, connector risk, and AI-generated code controls 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 responsible for identity security strategy or operational governance, it is worth exploring.