When Data Becomes Direction: The Agentic Attack Surface

The security debt of agent-assisted coding cannot be located only in the lines an agent writes. The specific issue here is the boundary between information an agent reads and actions it is allowed to take: repository text, documentation, tools, shared state, and deployment infrastructure can all influence the next step. Understanding that boundary helps readers distinguish a model mistake from an authorization or architecture failure, and judge how much consequence a coding action can acquire before it reaches a repository, build system, or external service.

Traditional software security relies heavily on separating code from data. A file may contain data that an application processes, while executable code and privileged instructions are supposed to come from a more trusted source. The separation is never perfect, but ordinary programs usually have explicit parsers, interfaces, and control-flow rules that define when data becomes an instruction. Language-model agents weaken that assumption because plaintext prompts shape the model’s control flow, generated text can become a later prompt, and the model receives different kinds of text through one learned sequence rather than a hard authority barrier.

The control boundary moves when data can choose the next action

A coding agent accepts a goal at a higher level than a traditional script. It may decide which files to inspect, whether to search documentation, which tool to call, whether to run a test, and how to respond to an intermediate result. That flexibility is the source of its usefulness. It also means that the security question is no longer limited to whether a user typed a dangerous command. The system must ask whether material encountered during the task can change the agent’s plan.

Consider a repository instruction, issue description, documentation page, dependency note, or tool result. To a person, these may be ordinary project information. To an agent, they are text placed in the same working context as directions about the task. If that text contains language that attempts to redirect the agent—perhaps telling it to reveal a file, ignore a constraint, or use a different tool—the content is no longer passive from a control perspective. It has become a possible input to action selection.

This is the mechanism known as indirect prompt injection. An attacker does not need to send a direct command to the agent. They can place adversarial instructions in content the agent is likely to retrieve, such as a web page, email, or calendar entry. The broader security analysis gives an example in which poisoned web content instructs a browsing agent to read calendar entries and send them to an attacker-controlled server. The same data-to-control mechanism is relevant to coding artifacts: repository text, issue content, documentation, dependency metadata, and tool output may be untrusted even when they are necessary for the task.

That application to coding should be stated carefully. The supplied pull-request study did not measure prompt-injection events, and it does not establish that any particular security smell was caused by an injected repository instruction. The supported conclusion is architectural. If an agent can read content and then select tools or alter files, untrusted content belongs in the threat model. A system that treats every retrieved sentence as an instruction candidate has a weaker control boundary than one that keeps data separate from the policy that authorizes an action.