Claude security risks are now an IAM and NHI problem

At a glance

What this is: Akto argues that Claude has become an enterprise identity and governance problem because it now operates across employee tools and data sources with access that often lacks approval, visibility, or controls.

Why it matters: IAM, NHI, and AI governance teams need to treat tool-connected AI as an access layer, not just an assistant, because unmanaged permissions and data paths widen enterprise blast radius.

Context

Claude is no longer just a chat interface. According to Akto, it now reaches into local files, shells, web sessions, Slack, GitHub, and production databases, which means the security question is no longer only what users type into prompts but what the system can access on their behalf.

That shift turns Claude into an IAM and NHI governance problem. Once access is embedded in connectors, projects, and autonomous collaboration patterns, identity teams need visibility into who approved what, which permissions are active, and how data moves through the environment.

Key questions

Q: What breaks when Claude usage is not centrally discovered and governed?

A: Security teams lose the ability to see which employees, projects, and connectors are moving data through Claude. That creates shadow AI, hidden permission paths, and unreviewed data exposure. Once usage is invisible, access review, policy enforcement, and DLP all become partial controls because the real identity boundary has already been crossed.

Q: Why do Claude connectors increase enterprise risk so quickly?

A: Because connectors turn Claude from a text interface into a delegated access path to Slack, GitHub, Google Drive, and other systems. The risk comes from granted permissions, OAuth scope, and token handling, not from the model alone. If those trust relationships are not reviewed, the blast radius of one compromised workflow expands across multiple services.

Q: How should teams govern AI agent skills in production?

A: Treat skills as controlled runtime assets, not informal text. Assign ownership, version them, restrict when they can load, and require evaluation before release. The right question is whether a skill improves a specific model-harness pair under real task conditions, because that is where hidden regressions and overbroad instructions show up.

Q: How do identity teams account for autonomous collaboration in AI tools?

A: By extending governance to actions taken by the system, not only by the employee who enabled it. That means defining which tasks Claude may perform, what data it may access, and how those actions are audited. Without that layer, accountability sits with the human while the operational behaviour belongs to the machine.

Technical breakdown

Shadow AI becomes an access discovery problem

Shadow AI is not just undiscovered usage of a model. In this context it is undisclosed access to corporate systems through a tool-connected AI surface. Akto describes employees using Claude across teams without IT requests, SSO enforcement, or meaningful guardrails. The technical issue is not only model use, but unsanctioned identity paths that bypass normal application onboarding, access review, and data classification controls. If security cannot inventory where Claude is active, it cannot evaluate the entitlements attached to those sessions or the data they touch.

Practical implication: build an inventory of AI entry points, connectors, and project spaces before trying to enforce policy.

MCP connectors expand the privilege boundary

Model Context Protocol, or MCP, changes the control plane because Claude can act through connected systems instead of only ingesting copied text. When connectors reach Slack, GitHub, Google Drive, Jira, or Notion, the security boundary shifts from prompt content to authentication method, OAuth scope, token usage, and downstream object permissions. That means a compromise, misconfiguration, or over-permissioned integration can widen blast radius beyond the original user. Akto's concern is not the connector idea itself, but the lack of governance around who granted it, how it is authenticated, and what it can reach.

Practical implication: review every active connector as a governed identity relationship, not a convenience feature.

Claude Code turns AI-assisted development into code and execution risk

Claude Code introduces two linked problems. First, AI-generated code can embed insecure patterns because the model optimises for functional output, not secure implementation. Second, repository-triggered execution flaws can expose developers to hidden command execution when a malicious project is opened. Akto also notes that reusable skills and prompts can function like plain-language malware if they instruct the agent to exfiltrate data or misuse shell access. That combination makes the development surface both a code-quality issue and an execution-path issue.

Practical implication: subject AI-generated code, third-party skills, and repo-opening workflows to the same review gates as other high-risk software paths.

Threat narrative

Attacker objective: The objective is to reach enterprise data, credentials, and execution paths through AI-mediated access that security teams do not govern.

1. Entry begins with unsanctioned Claude use, connector enablement, or malicious code repositories that bring the AI surface into the enterprise workflow.
2. Credential and token access follows when connectors, employee session cookies, OAuth grants, or shell permissions allow Claude to reach files, chats, or data systems.
3. Escalation occurs as Claude projects, Cowork collaboration, or skills extend the same access across tasks, tools, and environments with little identity review.
4. Impact is exposure of source code, confidential documents, database content, secrets, and insecure code paths that can persist inside production workflows.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Claude has become an IAM problem because its real risk is delegated access, not prompt quality. Akto's core point is that Claude now operates through files, shells, Slack, GitHub, and databases with the same privileges as the user. That makes identity the control surface, because the security question is who granted access, what it can touch, and whether anyone can still govern it. Practitioners should treat tool-connected AI as a privilege-bearing identity class.

Shadow Claude usage is really shadow access. The article shows that many teams are not merely unaware of where Claude is used, they are unaware of which enterprise systems it can reach. That is a governance failure, not just an inventory gap. The named concept here is AI access drift: the gradual expansion of machine-mediated access without a corresponding approval trail or entitlement review. The implication is that governance must follow the connector and project boundary, not the chat interface.

MCP changes the security model by moving control from content to connectivity. Once Claude connects to Slack, GitHub, or Google Drive, the enterprise is no longer reviewing text output alone. It is reviewing authentication methods, OAuth scope, and token use across systems that were designed for human workflows but are now being consumed by an AI intermediary. That is where blast radius expands, and practitioners should stop treating connectors as peripheral integrations.

Claude Code exposes the weakness of assuming AI-generated output is just another developer productivity layer. Akto ties insecure code generation, malicious skills, and repository-triggered execution into a single operational risk. The governance assumption that breaks is that software review happens before code reaches production. AI-assisted development can compress that window, which means review, provenance, and execution boundaries need to move earlier in the workflow. Practitioners should reclassify AI-assisted development paths as high-risk identity and supply-chain surfaces.

Autonomous collaboration forces identity teams to govern machine action, not just machine access. Akto raises accountability, auditing, and policy questions that do not fit employee monitoring models. The result is a hybrid governance problem where NHI controls, application permissions, and AI behaviour all intersect. The practical conclusion is straightforward: identity programmes must extend to autonomous workflows before those workflows become the default operating model.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Security Guide

What this signals

Claude's spread across files, shells, and enterprise apps shows why identity teams can no longer treat AI as a separate innovation track. The control problem is access scope, because the same workflow that improves productivity can also inherit broad entitlements without a fresh review. AI access drift: when AI tools accumulate permissions across projects and connectors faster than governance can track them, the programme loses sight of the real blast radius.

Access review cadence is the wrong lens for agentic workflows. Access review assumes privilege remains stable long enough to be certified, but AI-connected workflows often gain, use, and propagate access inside a single task. Practitioners need to move governance attention to issuance, connector approval, and data-handling boundaries before those sessions begin. 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.

For practitioners

• Map every Claude entry point Inventory claude.ai, desktop usage, Claude Projects, Code, Cowork, and connected systems so you can see where access already exists. Include business teams, not only engineering, because the article shows shadow usage across functions.
• Review connector permissions and authentication Check which Slack, GitHub, Google Drive, Jira, and Notion integrations are active, what OAuth scopes they hold, and whether any connector was enabled without security review. Treat each active connector as a managed identity relationship.
• Treat Claude Projects as persistent data stores Classify uploaded documents, shared project spaces, and linked data sources as durable enterprise repositories, then apply data handling controls to them. Do not assume project content is ephemeral just because the interface looks conversational.
• Gate AI-generated code and skills through security review Apply code review, provenance checks, and content inspection to AI-assisted code, reusable skills, and repository-based workflows before they reach production or developer shells. A prompt or skill that instructs shell access should be handled as a code path with execution risk.

Key takeaways

• Claude has shifted from a productivity assistant to a governed access surface that can reach files, code, and production systems.
• The biggest exposure comes from hidden permissions, unreviewed connectors, and AI-generated code paths that bypass normal oversight.
• Identity teams need inventory, connector governance, and workflow-level review before Claude-style tools become the de facto operating layer.

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.
• Autonomous Collaboration: An operating pattern where an AI system can take actions across tasks and tools with limited human gating. The governance issue is not only what the system sees, but what it can initiate, persist, or chain together inside enterprise workflows.
• AI Access Boundary Drift: AI access boundary drift is the gap between the access a system is supposed to have and the data it can actually reach once runtime behaviour, search paths, metadata, or retention come into play. It is a governance failure, not just a technical bug.

Deepen your knowledge

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