Notifications
Clear all
Topic starter
02/08/2026 11:35 am
TL;DR: Claude is moving from a prompt-based assistant into a tool-connected workspace that can access files, shells, Slack, GitHub, and databases, creating shadow AI, connector, and code-security risk across the enterprise according to Akto. The governance gap is no longer adoption, but identity oversight for non-human access, autonomous workflow boundaries, and data handling controls.
NHIMG editorial — based on content published by Akto: Agentic AI Security Top 6 Claude Security Risks
By the numbers:
- Snyk audited nearly 4,000 agent skills and found over a third had at least one security flaw.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory every Claude entry point Map usage across claude.ai, desktop, Code, and any embedded workflows.
- Review connector scopes as privileged access Audit all MCP connectors, OAuth grants, and integration tokens tied to Claude.
- Classify Claude projects as persistent data stores Apply data governance and DLP rules to projects that hold documents, shared prompts, or external data.
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
👉 Read Akto's analysis of Claude security risks and identity governance gaps →
Claude security risks: what identity teams need to govern now?
Explore further
02/08/2026 12:49 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Claude security risks are now an IAM and NHI problem
