Agentic coding tools expand code and secret exposure paths

At a glance

What this is: Agentic coding tools can access repository content, credentials, and connected MCP sources with far more runtime reach than traditional developer tooling, expanding the exposure surface for code and secrets.

Why it matters: IAM, PAM, and data governance teams need to treat coding agents as non-human identities whose access, context, and downstream data movement must be inventoried and controlled.

By the numbers:

• 60.5% of organizations have adopted and are utilizing AI coding assistants.
• Claude Code saw 6.45 daily launches per machine in 2026, versus Codex, which saw only 2.15 daily launches.
• source code is the number one data type submitted to unauthorized AI models, at 28%, nearly double the next category.
• 45% of employees are regular AI users on corporate devices, up from 15% the year before.

👉 Read Cyberhaven's analysis of how to secure agentic coding tools

Context

Agentic coding tools are AI systems that can read, write, and execute code with partial autonomy. In practice, that means they can open files, run terminal commands, install packages, and push commits while seeing whatever the developer can see on the machine, including secrets and sensitive data.

The governance gap is that security programmes were built for people typing code by hand, not for tools that ingest whole repositories and connected data sources in one session. For identity teams, this is an NHI governance problem first, and a code security problem second.

Key questions

Q: How should security teams govern coding agents that can execute repository instructions?

A: Treat repository instruction files as executable input, not documentation. Review AGENTS.md and similar artefacts before unsupervised execution, scan them for shell commands and credential-path access, and enforce allow or block decisions outside the model. The control objective is to prevent untrusted repository content from becoming trusted pre-task execution.

Q: Why do agentic coding tools create a different risk profile from standard developer tools?

A: They collapse reading, reasoning, and execution into one workflow. That means secrets, source code, and customer data can move into prompts or outbound requests without a visible copy-paste event. The risk is not only malicious use. It is sanctioned access operating faster and with less review than the identity programme assumes.

Q: What breaks when MCP connections are added to coding assistants without review?

A: The trust boundary expands beyond the repository into ticketing systems, databases, wikis, and external APIs. If those connections are not inventoried and owned, security teams lose visibility into what data the agent can reach and where it can send it. That makes access review incomplete and offboarding unreliable.

Q: How do organisations reduce data leakage from agentic coding tools without banning them?

A: Use approved agents with endpoint data policy, repository scoping, and monitored MCP access so the secure path is also the easiest path. Blocking the tools outright usually pushes developers toward unmanaged accounts and extensions. The better control is to make access specific, observable, and revocable.

Technical breakdown

Repository access, local secrets, and customer data

When an agentic coding tool is pointed at a repository, it inherits the file-system reach of the developer session. That often includes source code, .env files, cached cloud credentials, SSH keys, and customer data embedded in test fixtures or logs. The tool does not need to exploit a vulnerability to expose that material. It simply reads what the session can already see, then uses the context to complete the task. The result is a normal operating path that can still move sensitive data into prompts, logs, or downstream model calls.

Practical implication: Inventory which repositories and local credential stores each agent can reach, then restrict repository scope and secret exposure per developer context.

MCP connections turn tools into broader access paths

Model Context Protocol servers extend an agent beyond the local workstation into ticketing systems, internal wikis, databases, and third-party APIs. Each connection expands the agent's effective trust boundary because a developer may configure it once and never revisit the permission set. The technical issue is not just connectivity, but durable access paths that outlive the original task. If the agent can query and write across multiple systems, the repository is no longer the full attack or exposure surface.

Practical implication: Maintain a living inventory of every MCP connection, map each one to an owner, and review whether the agent actually needs read-write access.

Context windows and hosted model calls create exfiltration paths

Agentic coding tools often send task context to a hosted model provider so the system can reason about the fix. That means a prompt about a bug in billing can pull a real customer record, proprietary logic, or an API key into the context window and potentially into a remote request. The key technical point is that exposure can occur without a user copy-pasting data or violating policy. The tool is acting within its designed workflow, which is why visibility has to track data lineage rather than only process execution.

Practical implication: Classify data at the endpoint and inspect what an agent actually touches before it leaves the workstation or reaches a hosted model.

Threat narrative

Attacker objective: The attacker objective is to obtain source code, credentials, or customer data by abusing legitimate agentic access paths rather than breaking in directly.

1. Entry occurs when a developer authorises an agentic coding tool against a repository, giving it access to code, secrets, and connected systems within the normal session.
2. Credential and data access follow when the agent reads .env files, cached keys, customer records, or MCP-connected sources as part of task execution.
3. Impact occurs when sensitive code or credentials are sent into prompts, logs, or third-party model requests, creating unintended data exposure without a traditional compromise.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic coding tools are non-human identities with developer-grade reach, not just productivity features. Once a tool can open files, inspect repositories, call external services, and push commits, it becomes part of the identity plane. That means IAM, PAM, and data security controls must evaluate the agent's effective reach, not the user's intent alone. Practitioners should treat these tools as governed executors, not as passive copilots.

Repository-centric controls fail when the agent's trust boundary extends into MCP and hosted model calls. Security teams may know what lives in a repo, but they often do not know which connected systems an agent can query or write to. That creates an identity blast radius across code, tickets, wikis, databases, and third-party APIs. The implication is that access governance now has to follow the agent across every connected system it can reach.

Data lineage becomes the decisive control when code assistants can see more than they should send. The governance problem is not simply whether an agent can read sensitive material, but whether the organisation can trace where that material went after the agent touched it. Lineage-aware controls expose the path from file to prompt to outbound request. Practitioners should prioritise visibility into data movement, not only developer action logs.

Standing privilege in developer tooling is now an exposure multiplier. Many agent configurations are effectively permanent because they are set once and left in place. That mirrors the broader NHI problem of access that outlives the original business need. The conclusion for identity programmes is clear: developer agents need lifecycle control, ownership, and review just like any other privileged non-human account.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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.
• For a broader control lens, see OWASP NHI Top 10 for agentic application risk patterns that map directly to coding assistants.

What this signals

Agentic coding now belongs in the NHI governance backlog. Once a tool can read code, query connected systems, and submit prompts to external models, it is no longer just a developer convenience. The programme implication is that ownership, offboarding, and review must extend to agents and their MCP links, not stop at the human developer account.

Identity blast radius is the right concept for these tools. One developer session can now expose code, keys, and customer data across multiple systems, which means the practical question is not only what the tool can do, but how far its access propagates. Teams should align this with OWASP Agentic AI Top 10 and the internal inventory of every agent connection.

With 52% of companies able to track and audit the data their AI agents access, the other half are operating without evidence when something leaks. That makes endpoint lineage, data sensitivity classification, and MCP ownership the controls that decide whether agent adoption can scale safely.

For practitioners

• Inventory every coding agent and MCP connection Build a live register of Cursor, Claude Code, and any connected MCP servers on developer endpoints and CI/CD systems. A connection you cannot inventory is a connection you cannot govern.
• Restrict agent reach to the minimum repository scope Limit which repositories, branches, and local files each agent can inspect, especially .env files, cached cloud credentials, and fixtures that contain customer data.
• Apply endpoint data policy before model submission Use data-aware policy at the endpoint so the file, credential, or customer record is classified before it can be included in a prompt or transmitted to a hosted model.
• Review MCP write access as privileged access Treat write-enabled MCP connections to ticketing, databases, and internal systems as privileged paths requiring explicit ownership, review, and offboarding.
• Tie agent use to data sensitivity, not just process name Monitor which data classes an agent reads and where that data moves, because two identical process events can carry very different risk depending on the repository contents.

Key takeaways

• Agentic coding tools are governed non-human identities because they can access code, secrets, and external systems within a single working session.
• The biggest risk is not a breach of the tool itself, but unsanctioned data movement through normal agent behaviour and connected MCP paths.
• Identity teams should shift from tool approval to reach, lineage, and revocation control across every agentic coding workflow.

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.
• Data Lineage: The record of how data moves across systems, applications, and workflows. In security operations, lineage shows where sensitive data propagates, which identities touch it, and how a compromise could spread across connected environments.
• 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.

What's in the full article

Cyberhaven's full blog covers the operational detail this post intentionally leaves for the source:

• Endpoint-native Data Lineage implementation details for tracing files, credentials, and customer records through agent interactions
• How Linea AI classifies data in context and decides whether to block, warn, or allow an agent action
• Visibility into MCP servers and shadow AI agents across developer machines and CI/CD pipelines
• How policy follows sensitive data instead of relying on process-name allowlists

👉 The full Cyberhaven post covers endpoint controls, MCP visibility, and data lineage details for agentic coding tools.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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, PAM, or identity governance programme, it is worth exploring.