TL;DR: Cursor and Claude Code can read repositories, install packages, run commands, and push commits with access that often matches a senior engineer, creating new paths for source code, secrets, and customer data to leave the organisation, according to Cyberhaven. The core issue is not the model alone but the governance assumption that code assistants stay inside human-paced review loops.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Cyberhaven's blog post: Agentic coding tools are extending developer access into repositories, terminal actions, and MCP-connected systems, creating new exposure paths for source code, secrets, and customer data.
Why it matters: IAM, PAM, and NHI teams need to govern these tools as active non-human actors because their effective access can exceed what static developer controls were designed to contain.
By the numbers:
- 60.5% of organisations have adopted and are utilising AI coding assistants, according to Cyberhaven.
- Claude Code saw 6.45 daily launches per machine in 2026, versus Codex at 2.15 daily launches, according to Cyberhaven.
Context
Agentic coding tools are AI systems that can read, write, and execute code rather than only suggesting edits. In practice, that means they can open files, install packages, run commands, and push commits while touching the same developer workspace that often contains source code, environment files, cached credentials, and customer data.
The governance gap is that most security programs still assume code access is exercised by a human at a keyboard, with review between each step. Once the tool can traverse repositories and Model Context Protocol connections on its own, the access model is no longer just developer IAM, it becomes non-human identity governance for a tool that can move data as part of normal operation.
The primary issue is not compromise. It is sanctioned access expanding beyond the visibility and review model that teams built for manual development workflows.
Key questions
Q: What breaks when agentic coding tools can read entire repositories and act on that access?
A: The review model breaks first. These tools can inspect broad workspace context, pull secrets or customer records into the task, and continue operating before a human reviews each step. Security teams should assume the control gap is at access scope and data reach, not only at code execution.
Q: Why do agentic coding tools increase exfiltration risk even when employees are authorised?
A: Because authorisation to use the tool is not the same as governance over what it can see or send. A sanctioned agent can expose source code, credentials, or customer data as part of normal operation, especially when it calls hosted models or MCP-connected services to finish a task.
Q: How should security teams enforce policy when coding agents use MCP servers?
A: Security teams should treat MCP server access as a governed control surface, not an informal developer convenience. Define which servers are allowed, who can approve them, and what policy checks run before use. Visibility into active servers matters because agentic coding can otherwise expand trust faster than review processes can track. Governance should be consistent, lightweight, and enforced automatically.
Q: Should organisations separate coding agents from repositories with secrets and production data?
A: Yes, where possible. Coding agents are most dangerous when they can see everything a developer can see, including .env files, cached credentials, and production-adjacent data. Segmentation reduces the blast radius when the tool needs broad context to complete its task.
Technical breakdown
How agentic coding tools turn repository access into data exposure
Agentic coding tools operate inside the developer trust zone, so they inherit everything the local environment can reach. That typically includes source code, .env files, SSH keys, cloud credentials cached in shells, and test or fixture data that may contain customer records. Because the tool can read across an entire repository, a single prompt can surface more sensitive material than a human would inspect manually. The exposure is not limited to what the developer intends to change, because the agent often needs surrounding context to complete the task. That makes the access path broader than traditional editor or IDE assistance and harder to reason about through file-level permissions alone.
Practical implication: Treat the agent as a reader of the whole workspace, not just the file under edit, and scope its access accordingly.
Why MCP connections expand the attack surface for coding agents
Model Context Protocol lets coding agents reach beyond the local file system into ticketing systems, internal wikis, databases, and third-party APIs. Each MCP server effectively becomes another data source and action surface that the agent can read from or write to. The security problem is not the protocol itself, but the accumulation of unmanaged connections that are configured once and rarely reviewed again. If teams cannot inventory which MCP servers are attached to which agents, they cannot tell what data the agent can reach or where that data can move. In identity terms, this is delegated access without durable governance over the downstream tools the delegation can touch.
Practical implication: Inventory every MCP connection and map it to the specific agent instance before allowing broader rollout.
Why human review loops fail for agentic code operations
Traditional developer controls assume a human evaluates each meaningful step before action continues. Agentic coding tools collapse that assumption because they can read context, decide what to inspect next, and execute the next command without waiting for a separate approval event. That changes the control problem from one of reviewing discrete human actions to governing a tool that can chain actions inside a single task. The result is an access path that can pull proprietary logic, customer data, or credentials into model context and outward to hosted services as part of ordinary operation. The issue is not just speed. It is that the review boundary no longer matches the decision boundary.
Practical implication: Move controls to issuance and data-access boundaries instead of relying on step-by-step human review.
Threat narrative
Attacker objective: The objective is to obtain sensitive development data or reusable credentials without needing to break into the environment.
- Entry begins when a developer authorises an agentic coding tool on a workstation or repository with broad local access.
- Credential and data exposure follow when the agent reads files, cached secrets, and repository context to complete a task.
- Escalation occurs when the agent uses MCP connections or hosted model requests to move that context into additional systems and services.
- Impact is the unintended movement of source code, credentials, or customer data outside the organisation through normal tool operation.
Breaches seen in the wild
- Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
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
Agentic coding tools create an identity problem before they create a data problem: these tools are not passive software helpers, they are delegated actors with the ability to read, decide, and act inside development environments. That means the security question is no longer whether a developer can be trusted to use the tool, but whether the tool's delegated access is governed as a non-human identity. The practitioner implication is that coding assistants need their own access boundaries, inventory, and review model.
The assumption that access is reviewed before it is operationalised is breaking: human-paced review loops were designed for actions that remain visible long enough to be checked. Agentic coding tools can read, reason, and transmit data within the same session, so there may be no durable artefact for a later review to catch. The implication is not that teams need another policy, but that the review premise itself no longer holds for this class of actor.
Model Context Protocol has become an identity routing layer as much as a connectivity layer: every MCP server expands what the agent can touch, and unmanaged connections turn delegated access into latent data reach. In governance terms, the issue is third-party exposure without lifecycle control over which agent can reach which system. The practitioner implication is to treat MCP inventories as part of NHI governance, not as a developer convenience list.
Identity blast radius now depends on repository content, not only account privilege: a tool with broad read access can surface secrets, customer records, and proprietary logic that were never meant to sit inside a single execution context. That turns the repository itself into a source of privilege amplification. The practitioner implication is to reduce the data that any agent can see by default, especially where secret material and production credentials co-exist.
Shadow AI and agentic coding tools are converging into the same governance failure mode: sanctioned tools can still become unmanaged data pathways when security teams lack visibility into who uses them, which accounts they run under, and what they can reach. The problem is not only unsanctioned use, but sanctioned use without policy at the point of access. The practitioner implication is to govern the tool path before developers route around it.
From our research library:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Identity blast radius: the practical control variable is no longer just who can log in, but what the agent can read and route during a task. When a coding assistant can traverse repositories and model connections in one session, the exposed surface is shaped by data proximity as much as by account privilege.
Agentic coding tools should be governed as delegated non-human identities, not as lightweight productivity features. That shift matters because lifecycle, inventory, and access review become the only durable ways to understand what the tool can reach before sensitive code or credentials leave the environment.
For practitioners
- Inventory agentic coding tools and MCP servers Build a current register of every coding agent, extension, and MCP server used on developer endpoints and CI/CD systems. Include which repositories, ticketing systems, wikis, databases, and APIs each connection can reach.
- Apply data-aware policy at the endpoint Enforce controls based on the sensitivity of the file, credential, or customer record the agent touches, not just on the application or network path. Keep policy attached to the data as it moves through the workspace and into model requests.
- Limit agent visibility to least necessary repositories Separate high-risk repositories that contain production credentials, proprietary logic, or customer records from general development workspaces. Reduce the amount of sensitive material an agent can read in one session.
- Review MCP server authorisations as delegated access Treat each MCP connection as a standing delegation that needs ownership, review, and revocation criteria. Unused or unowned connections should be removed before they become shadow access paths.
- Monitor agent activity by data sensitivity Correlate agent actions with the sensitivity of the data accessed, not only with process names or command execution. A task touching billing code or production secrets deserves different scrutiny from a task touching public samples.
Key takeaways
- Agentic coding tools expand the exposure surface by combining repository access, terminal action, and model context in a single workflow.
- The main failure is not malicious compromise but sanctioned access that exceeds the review model built for human-paced development.
- Governance needs to move toward inventory, delegated access control, and data-aware policy at the endpoint.
Key terms
- Agentic coding assistant: An AI-assisted development tool that can decompose tasks, choose actions, and execute parts of a workflow inside the editor. In security terms, it behaves like a non-human identity when it can access code, tools, and terminals on behalf of a developer, so governance must cover its runtime behaviour.
- 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.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- 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.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 11, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org