Skip to content

Security1 publisher2 min readPublished

Coding agents fetch untrusted docs into a session that already holds terminal and repo write access

The exposure in AI coding agents sits in the execution layer that runs commands and edits repositories, according to an explainer on scworld.com, and the same harness is now being pointed at work outside software development.

The Watch · Security desk

Illustration accompanying Coding agents fetch untrusted docs into a session that already holds terminal and repo write access

What happened

  • An explainer on scworld.com puts the security problem for AI coding agents in the harness, the execution layer that coordinates model calls, tool use and workflows, plus the repositories, documentation and skills it draws on.
  • Those agents plan work, invoke tools, run terminal commands, modify repositories and retrieve documentation, finishing complex development tasks with minimal human guidance.
  • Because an agent pulls from trusted and untrusted sources inside one task, an adversary can embed instructions in documentation, code examples or issue comments and wait for the agent to retrieve them.

Compiled by The WatchSomething wrong?How this is made

Why it matters

  • constraint Trimming what the agent reads is off the table by the article's own logic, so the only place left to put a control is on the privileged action, after untrusted text is already in context.
  • exposure Anyone who can edit a README, a documentation page or an issue thread the agent visits gets influence over a session that holds a terminal and repository write access.
  • precedent Permissions teams grant coding agent harnesses now become the starting position for the non-coding agents built on the same execution layer.

A poisoned README is a text file, but inside a coding agent it lands in a session that already holds a terminal and write access to the repository, because the harness handed the model those tools [1]. The attacker does not need the model to malfunction. According to the scworld.com explainer, the models behind coding agents primarily reward helpfulness by following instructions instead of being skeptical of dangerous actions [8], and an adversary can plant those instructions in documentation, code examples or issue comments the agent is likely to retrieve [9].

The article's own example is a routine ticket: fix an API usage bug. The agent consults a code repository, searches public documentation, inspects a GitHub issue, then updates source code, all inside one workflow [5]. Three of those steps are reads, one is a write [13]. Two of those reads, the public documentation and the issue, are the same places the article names as somewhere instructions can be embedded [15].

The obvious control is to feed the agent less, and the piece rules that out, since agent effectiveness depends on the context it collects. "The challenge is enabling agents to reason over information from many sources without allowing untrusted content to influence privileged actions," the article says [10]. That puts the control between retrieval and action, at the moment the harness decides which tool call is permitted after untrusted text is already in the window.

What has to be secured, on the article's account, is an execution environment made of models, context, tools, skills and orchestration logic [3]. Tool allowlists, the credentials the execution environment holds, the scope of repository write access and which skills are installed are all set outside the model [2]. Platform and AppSec teams hold those settings, whatever a model evaluation finds.

The article also extends the trust question to the components that shape how an agent behaves, which it frames as a new AI supply chain problem [12]. Coding agent harnesses are maturing for broader use, and the same execution layer is starting to power agents doing work well beyond software development [4].

It is an explainer, not an incident report: it describes the trust model and cites no CVE, victim or rate of exploitation [14]. The inventory it implies is short and available now, which agents hold repository write and which tools each harness exposes [2].

What to watch

  • A published incident tying an injected documentation page to a committed repository change would turn this from a trust-model argument into a measurable one.
  • Whether skill and plugin ecosystems get provenance or signing requirements before a harness will install them.
  • Whether harness vendors ship default tool allowlists that block write and command actions once untrusted content has entered the context window.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories