Your Security Stack Was Built for a Different Attacker: The Coding Agent Blind Spot

Every tool in the enterprise security stack was designed to answer a specific question about a specific threat model.

Endpoint Detection and Response (EDR): is this process behaving maliciously?

Data Loss Prevention (DLP): is data moving through unauthorized channels or in an unauthorized way?

Identity and Access Management (IAM): is this identity authorized to access this resource?

These are the appropriate questions to ask for the system and threat models these tools were originally built to defend, but when it comes to coding agents, the story is much more complex than any one of these tools can tackle on their own.

Coding agents like Claude Code, Cursor, GitHub Copilot, and Gemini CLI are autonomous systems. They plan multi-step tasks, invoke tools, execute commands, browse the web, read and write to the filesystem, and call external APIs under the developer's identity, all without a human approving each action. A developer launches the agent with a goal and the agent decides how to pursue it.

Tools that came before this new autonomy paradigm were not built to address and maneuver to attack the needs of the attack surface today.

What Each Layer Sees

EDR: process behavior, not agent intent

Endpoint detection and response tools watch for malicious process behavior: code that exploits vulnerabilities, processes that inject into other processes, files that match known-bad signatures, and command sequences that match documented attack patterns.

Coding agent attacks extend the parameters of these existing vectors. The agent is a legitimate process. The commands it executes, including npm install, curl, and cat .env, are commands developers run constantly. There is no malware signature to match. What EDR fundamentally can't see is the relationship between what the agent was told to do and what it subsequently did. A curl request that exfiltrates credentials is identical at the process level to a curl request that fetches documentation. EDR monitors the action. The threat lives in the intent behind it.

DLP: file transfers, not contextual data access

Data loss prevention tools were designed for a world where sensitive data leaves the organization via email attachments, USB drives, or unsanctioned cloud storage. Agent exfiltration bypasses this model entirely.

When a coding agent reads a .env file and embeds its contents in an HTTP request to an attacker-controlled URL, that's not a file transfer. It's a web request. When an agent sends credentials through a Slack integration it's already authorized to use, DLP sees authorized SaaS traffic. Gradual exfiltration, retrieving small amounts of data across many sessions to stay below per-session thresholds, is only visible when behavioral monitoring correlates data access patterns against agent identity and task context across time. DLP doesn't do that correlation.

IAM: permission scope, not behavioral appropriateness

Identity and access management tracks which identities are authorized to have access to which resources. Coding agents act under the developer's identity. Every action they take, every file read, every API call, every commit, is attributed to the developer. From IAM's perspective, a developer's agent being manipulated through prompt injection and a developer manually performing a legitimate task are identical events: the same identity, the same authorized action, the same clean credential chain.

IAM programs were designed to manage static credentials and provisioned service accounts. They don't see session tokens minted at runtime. They don't see permissions inherited through Model Context Protocol (MCP) server tool calls. And they don't see a developer's stored credentials being discovered and used by an agent that was never intended to have them.

SIEM: events, not decision chains

Security information and event management platforms correlate logs across systems to detect anomalies and known attack patterns. These attack patterns are based in human activity, which are structurally different from Agent execution.

An agent's workflow is a connected chain of decisions, tool invocations, API calls, and data accesses that collectively constitute a task. Understanding whether that workflow was appropriate requires evaluating the sequence and the relationship between steps, not just whether each individual step looks normal. A SIEM receiving individual log events from a compromised coding agent session will see: an authorized process called an authorized MCP server, then executed npm install (normal), then issued a curl request (normal). No individual event crosses a detection threshold. The threat is only visible in the aggregate.

The Partial Coverage Trap

Many security teams today are hoping that the existing tool stack will provide the coverage they need to secure this new threat, but unfortunately the gaps presented don’t allow for that to be the case.

Identity and data monitoring together, the most common partial-coverage configuration, catches credential misuse and flags unusual data volumes. It misses the attack that uses legitimate credentials to access data at a volume just below thresholds, directed by a model successfully injected through a malicious document processed mid-workflow. The reasoning chain that shifted mid-execution in response to the injected payload is simply not present in the logs.

Agent posture management catches misconfigured agents before or between deployments. It doesn't catch an agent that was correctly configured at scan time and then manipulated at runtime. A clean posture assessment provides no protection against a runtime attack that occurs after the scan.

When a breach occurs, and an incident response team needs to reconstruct what an agent did, the answer is frequently that they can't. The identity layer shows the agent had access. The data layer may show that something moved. The decisions, tool calls, and the reasoning behind them are a gap.

What the Gap Requires

The coverage gap isn't a matter of configuration, and it isn't going to be closed by applying more of the same tooling. What's missing is purpose-built observability at the agent layer.

Two types of observability are required. Execution observability captures what the agent did at sufficient granularity: tool invocations, MCP server interactions, file access sequences, and outbound network activity. Intent observability captures why the agent did it: the reasoning chain, goal state, and decision context behind each action.

Most organizations have some version of execution observability, however it typically sits at too high a level of abstraction. Intent observability, the capability that enables you to detect a mid-session goal shift caused by prompt injection, is rare. It's also what makes the difference between a log that reads clean and detection that actually works.

The 47% of security and IT professionals who have already experienced an AI agent security incident largely saw it surface through the existing stack. Most of them couldn't reconstruct exactly what happened, because the middle of the attack chain, the decisions and the reasoning behind them, wasn't in any log they had.

We've built sophisticated security tooling over decades by asking the right questions about the threats we understood at the time. Coding agents are a threat model those tools don't understand, and asking the same questions will produce blind spots. Closing the gap means asking a new question beyond just what was the agent allowed to do. Instead the question is: what was it trying to do, and how do you know?

Dig into the full threat landscape, tooling gap analysis, and what securing coding agents actually requires.