Why do coding agents with source-code and internet access increase security risk?

Why coding agents become a higher-risk delegated identity

Coding agents are risky because they are not just readers or autocomplete tools. They can inspect source, reason over it, and then act outward through terminals, package managers, APIs, browsers or git remotes. That combination turns a single compromise point into a bridge between sensitive code and real-world action, which is why the question is less about “AI quality” and more about delegated authority.

The key security change is that the agent’s context often includes secrets, internal architecture, and developer intent at the same time. A malicious prompt, a poisoned dependency, or a deceptive tool response can steer the agent to reveal data, propose unsafe code, or execute requests that look legitimate because they originate from a trusted workflow.

When you want a practical baseline for this topic, AI Coding Agents Security Guide frames the main control problem: keep the agent useful while limiting what it can read, what it can modify, and what it can send outside the environment.

Where source-code access changes the blast radius

Source-code access matters because code repositories rarely contain code alone. They often carry tokens, connection strings, deployment metadata, internal URLs, comments, and workflow hints that reveal how systems are wired together. Once an agent can search and correlate those details at speed, it can surface material that a human reviewer might miss or not have time to connect.

That creates two failure modes. First, the agent may expose secrets directly from the codebase or surrounding files. Second, it may use that code-derived context to generate more dangerous follow-on actions, such as targeted exploit proofs, mass enumeration of services, or unauthorized repository changes that blend in with normal developer activity.

Examples from recent breaches show the same pattern in a human-driven form. EmeraldWhale Git config credential theft and New York Times GitHub breach 2024 both illustrate how repository exposure can become credential exposure, which then becomes broader environment access.

Why internet access makes the same agent harder to trust

Internet access adds a second trust boundary. An agent that can read external pages, pull dependencies, query public endpoints, or consume model output from outside the repository is vulnerable to influence from untrusted content. That content can be intentionally crafted to redirect the agent, alter its plan, or embed instructions inside seemingly harmless text.

This is where the risk changes from accidental leakage to active abuse. The agent may treat external content as evidence, but a malicious source can behave like a social engineer with direct access to the agent’s reasoning loop. In practice, that can lead to credential harvesting, package sabotage, data exfiltration, or tool calls that were never intended by the human operator.

The problem is not just internet access by itself, it is internet access combined with a workflow that can execute. If the agent can browse, fetch, install, commit, and post outbound requests under one delegated identity, then a single bad instruction can traverse from information gathering to action without a clear human checkpoint.

Risk and Threat Considerations

Coding agents expand risk because they compress multiple trust decisions into one runtime identity: read, reason, retrieve, and act. That makes prompt injection, poisoned tool output, malicious packages, and over-broad credentials especially dangerous, because any one of them can redirect a trusted development workflow into exfiltration or unauthorized execution.

Failure mechanism: The agent ingests untrusted text or code, treats it as operational context, and then uses its own permissions to disclose secrets, generate exploit code, modify repositories, or call external systems in ways the operator did not intend.

Impact: The likely consequence is not only bad code, but compromised credentials, unauthorized network activity, supply chain contamination, and faster attacker movement from a development environment into production-adjacent systems.

Practitioner Guidance

What to prioritise: Treat the agent’s permission set as the primary control surface. The most important question is not whether the model is “smart enough”, but whether the delegated identity can reach secrets, source, and external actions without tight scoping.

What to verify: Confirm that the agent cannot read more repository data than the task requires, cannot reuse long-lived credentials across tasks, and cannot make outbound requests without a bounded allowlist or human approval step.

Decision rule: If the agent can both inspect sensitive code and execute external actions, assume compromise of either prompt or tool output is enough to create material risk. In that case, reduce scope first, then add review gates, rather than trying to monitor everything after the fact.

Common mistake: Teams often sandbox the model but leave the workflow identity powerful. That is backwards for this use case, because the harmful action usually comes from the surrounding tooling and credentials, not from the model alone.

Practitioner takeaway: Safe use of coding agents depends on bounding delegated authority, not on trusting the model to “behave”. The more the agent can see and do in one session, the more a single poisoned input can become a real compromise path.

Related resources from NHI Mgmt Group

• How should security teams limit the risk from AI agents that have access to production systems?
• Why do AI coding agents increase code security risk if they are not verified?
• Why do coding agents increase supply chain risk even when source code is unchanged?
• Why do AI agents increase non-human identity risk in existing IAM programmes?