Notifications
Clear all
Topic starter
11/08/2026 3:17 pm
TL;DR: Claude’s footprint now spans developer laptops, employee desktops, mobile-triggered tasks and always-on managed agents, widening the identity and policy surface around MCP servers, connectors and data access, according to Noma Security. The governance problem is no longer just shadow AI; it is the collapse of static review models when runtime access, tool use and execution shift across multiple actor types.
NHIMG editorial — based on content published by Noma Security: Claude agent coverage across Chat, Code, Cowork, Dispatch and managed agents
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should teams govern AI agents that use MCP?
A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle.
Q: Why do AI agents complicate access governance more than ordinary automation?
A: AI agents complicate access governance because they can branch at runtime, wait on external services, and continue later with the same operational context.
Q: What breaks when remote task triggers are allowed for AI agents?
A: The problem is not the trigger alone, but the thinning of the approval chain.
Practitioner guidance
- Inventory every Claude-connected identity path Map Claude Chat, Claude Code, desktop AI, Dispatch and managed agents to the identities, connectors and data sources they can reach.
- Approve MCP servers before connection time Treat each MCP server as a delegated access point.
- Instrument full agent session telemetry Capture prompts, model responses, tool calls, file operations and downstream impacts in a single session timeline.
What's in the full article
Noma Security's full research covers the operational detail this post intentionally leaves for the source:
- Per-product coverage of Claude Chat, Claude Code, Cowork, Dispatch and managed agents across the Claude ecosystem
- Detection and response workflow detail for AI-DR profiles, including prompt injection, tool poisoning and sensitive data leakage
- Implementation specifics for AI-SPM discovery through MDM, local configuration files and endpoint telemetry
- Gateway integration details for Kong, Apigee, Azure, Portkey and LiteLLM deployments
👉 Read Noma Security's analysis of Claude agent governance and runtime risk →
Claude agent sprawl: what it means for IAM and NHI teams?
Explore further
11/08/2026 3:29 pm
Claude’s expansion from developer tool to enterprise workforce utility turns agent governance into an identity programme problem. Once non-technical employees can launch workflows, every approval, connector and data path becomes part of access governance rather than productivity enablement. The control question is no longer who can use the tool, but which identities can delegate actions to it and under what scope. That is a classic IAM boundary shift, and practitioners should treat it as one.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Our research also found that 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.
A question worth separating out:
Q: What should security teams do before deploying managed agents?
A: Assign each managed agent an owner, a purpose and a narrow permission set before it goes live. Then verify the task flow, the downstream systems it can reach and the data it can touch. If a background agent can act continuously without a bounded scope, it should be treated as an identity risk, not a feature.
👉 Read our full editorial: Anthropic Claude’s expanding agent surface changes identity governance
