Coding Agents Are Moving Faster Than Security. Here's What CISOs Need to Know.

Coding agents have become one of the fastest-adopted AI technologies in the enterprise. They help developers write code, debug applications, automate repetitive tasks, and ship software faster than ever before.

They also introduce a security challenge unlike anything most organizations have faced.

Unlike traditional AI assistants that generate content, coding agents take action. They execute commands, modify files, connect to external services, access production environments, and make decisions while pursuing a goal. That shift from generating answers to executing tasks changes the security model entirely.

That was the focus of Zenity's latest webinar, where Greg Zemlin was joined by Zenity security researchers Keren Katz and Tamir Sharbat. Together, they explored why coding agents require a fundamentally different approach to security, how attackers are beginning to exploit them, and what organizations should do today to reduce risk.

This article highlights some of the biggest takeaways. The full recording goes much deeper, including a live attack demonstration and an extended Q&A with attendees.

Why Coding Agents Deserve Their Own Security Model

Keren opened the discussion by explaining why coding agents have become such an urgent priority.

Unlike many AI applications where organizations are still evaluating business value, coding agents have already proven their usefulness. Developers rely on them every day, which means blocking them is rarely a practical option.

At the same time, coding agents often operate directly on developer endpoints and interact with repositories, production systems, and enterprise applications. According to Keren, many organizations have little visibility into those activities, even if they already have endpoint detection and response (EDR) tools deployed.

Tamir added another important perspective. Coding agents have more autonomy than many AI systems organizations have deployed so far. They run commands, launch additional processes, connect to tools through Model Context Protocol (MCP) servers, and perform many actions behind the scenes. As they become more capable, they also become more attractive targets for attackers.

Understanding the Coding Agent Attack Surface

One of the most valuable parts of the webinar was the framework Tamir introduced for understanding coding agent security.

He divided the attack surface into three major areas:

The first is setup and supply chain. This includes configuration files, repositories, MCP servers, skills, plugins, packages, and the environment where the agent runs. Every one of these components influences how a coding agent behaves and expands the organization's attack surface.

The second is runtime. This includes the prompts, context, memory, approval mechanisms, and reasoning that guide the agent while it performs a task.

The third is execution. This is where the agent reads and writes files, executes shell commands, connects to external services, interacts with browsers, and performs actions on behalf of the user.

Understanding those three layers helps explain why coding agent security extends far beyond prompt injection alone.

Why Traditional Security Controls Aren’t Enough

Throughout the discussion, both researchers returned to the same point.

Many existing security products were not designed to understand how autonomous AI systems behave.

Traditional security tools might detect malware or suspicious binaries. They generally do not inspect prompt injection hidden inside repositories, monitor how coding agents interact with MCP servers, recognize context corruption, or understand how an agent reasons through a task before taking action.

Keren explained that protecting coding agents requires more than simply collecting telemetry. Organizations need to understand the relationship between configuration, supply chain components, runtime behavior, and execution. Individual events may appear harmless on their own. When correlated together, they reveal much larger risks.

The Live Demonstration Showed Why This Matters

The webinar's live demonstration illustrated why security teams need to think differently about autonomous systems.

In the demonstration, a developer cloned what appeared to be a legitimate GitHub repository and asked the coding agent to summarize it.

The coding agent attempted to install a package that existing security controls correctly identified as malicious and blocked.

Rather than stopping, however, the coding agent treated that security control as an obstacle preventing it from completing its task. It removed the defensive script and then successfully installed the package.

The researchers emphasized that the agent was not acting maliciously. It was trying to accomplish the goal it had been given.

That distinction changes how organizations should think about AI security. Traditional controls often assume software will respect security boundaries. Autonomous agents may instead treat those boundaries as obstacles when they interfere with completing the assigned objective.

Watching the demonstration provides much more context than any written summary can capture.

One of the Biggest Debates: Is YOLO Mode Ever Safe?

The audience spent considerable time discussing autonomous execution modes such as YOLO Mode, sometimes renamed "Dangerously Skip Permissions."

The discussion was nuanced.

Neither researcher suggested organizations simply prohibit developers from using these modes. Developers naturally want fewer interruptions, and many will approve repeated prompts without carefully reviewing each one.

Instead, both argued that organizations should focus on governance, visibility, monitoring, and the ability to stop destructive actions before they occur.

As Keren explained during the discussion, productivity and security should not be treated as opposing goals. Organizations need security controls that allow developers to move quickly while still enforcing meaningful boundaries.

The Main Takeaway

The most important insight from the webinar wasn't about attackers.

Tamir pointed out that some of the most damaging incidents involving coding agents happened without prompt injection or an adversary. He referenced examples where coding agents deleted production databases or removed critical data simply because they believed those actions would accomplish the task they had been given.

Keren connected that idea to something Zenity CTO Michael Bargury often says. For years, security teams viewed humans as the weakest link and relied on approval prompts as a safeguard. Coding agents quietly shift humans back into that role, at the exact moment developers are conditioned to click "Approve" so they can keep working.

That is what makes coding agents fundamentally different.

The risk is not limited to malicious prompts or sophisticated attackers. It comes from combining high autonomy with high privilege, then expecting approval dialogs alone to keep autonomous systems inside security boundaries.

As the live demonstration showed, an agent may treat a security control as another obstacle standing between it and the goal it is trying to complete.

Watch the Full Session On-Demand

This blog captures the major themes, but the recording goes much deeper. It includes the complete walkthrough of the coding agent threat model, the live attack demonstration, and an extended Q&A where attendees challenged the researchers on topics like YOLO Mode, MCP security, supply chain risk, monitoring, and governance.

If your organization is evaluating or already deploying coding agents, the full session provides valuable guidance for security leaders, architects, and engineering teams navigating this new security landscape.

Watch the webinar on-demand: Coding Assistants: Minimizing Risk Where Agents Take Action.