How to Secure Agentic Coding Tools: Cursor and Claude Code

Cursor and Claude Code now read source code, install packages, and push commits with much of the access a senior engineer has, and often with less oversight. Give an agent a prompt to fix a bug, and it may pull a private API key from a config file, pass a customer record into its context window, or send a snippet of proprietary logic to a third-party model provider to reason about the fix. Security teams built policy for developers typing code by hand. Few have built controls for a tool that reads an entire repository, remembers what it saw, and acts on that access without a human reviewing each step.

What Are Agentic Coding Tools

Agentic coding tools are AI systems, such as Cursor, Claude Code, and Codex, that read, write, and execute code with certain levels of autonomy, including opening files, installing packages, running terminal commands, and pushing commits, often with minimal human review at each step, rather than just suggesting code for a developer to accept.

According to Cyberhaven Labs, 60.5% of organizations have adopted and are utilizing AI coding assistants. While there is still variety among the kinds of coding tools used by individuals, Claude Code saw 6.45 daily launches per machine in 2026, versus Codex, which saw only 2.15 daily launches.

That autonomy is what makes these tools productive. It is also what turns them into a new path for source code, credentials, and customer data to leave the organization, often before a security team knows the data moved.

What Data Cursor and Claude Code Can Access on a Developer's Machine

When a developer opens Cursor or Claude Code against a repository, the agent can see nearly everything a human developer at that machine could see. That includes source code, but it also includes .env files, SSH keys, cloud credentials cached in the shell, and any customer data checked into fixtures or test files.

Agentic coding tools also connect to Model Context Protocol (MCP) servers to reach outside the local file system, such as ticketing systems, internal wikis, databases, and third-party APIs. Each MCP connection is a new data path the agent can read from and write to, often configured once by a developer and never reviewed again. A security team that has never inventoried which MCP servers are connected to which agents has no way to know what data an agent can reach.

None of this requires a compromise. It is the normal operating mode of the tool. The risk shows up when that access combines with the agent's other job: sending context to a hosted model to reason about the task. A prompt like "fix the failing test in the billing module" can pull a real customer record into the context window and, depending on configuration, into a request sent to a third-party model provider.

Why Agentic Coding Tools Create New Insider Risk and Exfiltration Paths

Most of the risk from agentic coding tools is not malicious. It is the same convenience-driven pattern already documented with shadow AI, moving faster and staying harder to see.

According to Verizon's 2026 Data Breach Investigations Report, source code is the number one data type submitted to unauthorized AI models, at 28%, nearly double the next category. The same report found that 45% of employees are regular AI users on corporate devices, up from 15% the year before, and that 67% of those users connect through non-corporate accounts a security team cannot monitor. Shadow AI is now the third most common non-malicious insider action detected in DLP data, a fourfold increase in a single year.

Agentic coding tools compress that pattern into a single workflow. A developer no longer has to copy code into a chat window to expose it. The agent reads the repository directly, and depending on the tool's configuration and model provider, that context can leave the corporate environment as part of normal operation, not a policy violation the developer even notices.

For security teams, this reframes agentic coding tools as an insider risk problem as much as a supply chain one. The exposure rarely comes from an attacker breaking in. It comes from a sanctioned tool doing exactly what it was installed to do, without the visibility to know which repositories, secrets, or customer data passed through it.

How to Monitor and Control What Agentic Coding Tools Send to AI Models

Static analysis, software composition analysis, and CI/CD monitoring tools all watch what an agent does to a codebase or a pipeline. None of them answer the question a data security practitioner actually needs answered: what sensitive data did this agent touch, and where did it go? Legacy DLP does not close that gap either, since it is built to pattern-match on fixed formats like Social Security numbers, not to classify source code or internal documentation by where the data came from.

Three controls close most of the remaining gap:

1. Inventory every agentic coding tool and MCP server connected to developer machines and CI/CD pipelines. A connection you do not know exists is a policy you cannot enforce.
   
2. Apply data-aware policy at the endpoint, not only at the network perimeter. Policy should follow the file, the credential, or the customer record, whichever tool or agent is touching it, rather than relying on an approved-app list that agentic tools route around.
   
3. Monitor agent activity by data sensitivity, not only by process or destination. An agent reading a public marketing repository is a different risk than one reading a repository with production credentials or unreleased financial data, even though both look identical to a tool that only tracks process behavior.

None of this requires blocking Cursor or Claude Code outright. Security teams that try to ban agentic coding tools typically push developers toward personal accounts and unapproved extensions, recreating the exact shadow AI pattern, with less visibility than before. The more durable approach is to make the sanctioned path the path of least resistance. Give developers approved agents with policy already applied, so the secure option is also the fast one.

How Cyberhaven Secures Agentic Coding Tools

Cyberhaven applies Data Lineage at the endpoint, tracing a file, a credential, or a customer record from the moment it is created through every copy, transformation, and transmission, including the moment an agentic coding tool like Cursor or Claude Code touches it. Linea AI, Cyberhaven's classification engine, ties that lineage to context in real time, so security teams see not just that an agent read a file, but what the file was, where it came from, and whether the specific data inside it justifies a block, a warning, or no action at all.

This is the difference between endpoint-native DLP and legacy, pattern-matching DLP. Because Cyberhaven classifies data by lineage and context rather than by matching a fixed pattern, it can distinguish a request that includes a public code sample from one that includes an unreleased product's proprietary logic, a customer's personal data, or an API key, and apply policy accordingly, without an analyst writing a new rule for every agent and every repository.

Cyberhaven also extends AI Security visibility to Model Context Protocol connections and agentic AI activity more broadly: which MCP servers are in use, what data they expose, and where shadow AI agents are running without security team approval. Instead of choosing between blocking agentic coding tools and flying blind, security teams get the visibility to set policy once and have it hold as new tools, models, and agents get adopted.

Better understand how to secure AI systems, coding or otherwise, across the enterprise with “Securing AI Systems: An Enterprise Defense Framework.”