The Workspace Is the Attack Surface
Why any content an agent reads — repo files, error messages, tickets, tool output — is a prompt-injection channel, and why that matters most when the agent can run commands
The Conventional Framing
Coding agents are useful because they read the whole project: the README, the config files, the dependency manifests, the error output from a failed command. The more context they ingest, the better their suggestions. So we point them at repositories, error trackers, and issue queues and let them work.
The mental model is that this context is data — reference material the model consults, not commands it obeys. A README describes a project. An error message reports a fact. A ticket asks a question.
Why 'It's Just Context' Is Dangerously Naive
An LLM does not have a boundary between data and instructions. Everything in its context window is text it may act on. A README that says "if setup fails, run this initialization command" is not described to the model as data — it is read as guidance, and an agent that can run shell commands will follow it. The distinction between "content the agent read" and "instructions the user gave" exists in our heads, not in the model.
This is indirect prompt injection: the attacker never talks to the model directly. They poison something the model will later ingest — a file, an error event, a config — and wait for a developer to point their agent at it. In June 2026, Mozilla's 0Din team demonstrated a GitHub repository containing no malicious code at all that talks Claude Code into opening a reverse shell: a README with plausible setup steps, a package rigged to fail on first use, and an "init" command that fetches its payload from an attacker-controlled DNS TXT record and pipes it to bash. The reverse shell is three indirection steps away from anything the agent actually evaluated.
The lethal combination:
Untrusted context (anyone can write a README) + tool execution (the agent runs shell commands) + ambient credentials (the developer's machine holds ANTHROPIC_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN). Each is fine alone. Together they turn "the agent read a file" into "the attacker runs code as you." Prompt hardening does not close this, because the injection isn't malformed — it's a perfectly reasonable-looking instruction the model has every reason to trust.
Architecture
Components:
- Poisoned artifact— repo file, error event, ticket, or config the agent will read
- Ingestion— agent pulls the artifact into its context window
- Instruction blur— model treats embedded text as guidance, not data
- Tool execution— agent runs shell commands / calls tools on the guidance
- Ambient credentials— dev machine secrets available to any process the agent spawns
Trust Boundaries
- Attacker → Artifact — anyone can author a repo, file a ticket, or POST an error event
- Artifact → Context — agent ingests the artifact as reference material
- Context → Action — model acts on embedded instructions it can't distinguish from yours
- Action → Credentials — spawned process inherits the developer's ambient secrets
Threat Surface
| Threat | Vector | Impact |
|---|---|---|
| Poisoned repository (0Din / Claude Code) | README + failing package + runtime-fetched payload (DNS TXT → bash) | Reverse shell as the developer; payload never stored in the repo |
| Poisoned agent config (TrapDoor) | Malicious package plants CLAUDE.md / .cursorrules with zero-width Unicode instructions | Every future clone-and-open of the repo infects a new developer |
| Poisoned telemetry (Agentjacking) | Fake Sentry error event via a public DSN — one HTTP POST, no auth | Agent debugging the 'error' runs attacker shell commands (85% success across Claude Code, Cursor, Codex) |
| Poisoned tool / web output | Injection in a fetched page, API response, or MCP tool result the agent consumes | Same execution path through any channel the agent trusts as data |
The ZIVIS Position
- •Treat an unfamiliar repo like an unknown executable.Cloning is not neutral. The moment an agent reads a repo you didn't write, its setup instructions are untrusted code — regardless of what the agent recommends. Review before you point an autonomous agent at it, or run it somewhere that can't hurt you.
- •Sandbox the agent when the context is untrusted.If the workspace can contain adversarial content, the agent needs a container, a VM, or a network- and credential-restricted environment. The blast radius of a poisoned instruction is whatever the agent's process can reach.
- •Keep a human on the trigger for execution.The dangerous step isn't reading — it's running. Require explicit approval before an agent executes shell commands or irreversible tool calls, and surface what a command actually does at runtime, not just the literal string. A command that pipes a fetched value to bash should read as alarming, not routine.
- •Don't leave production secrets lying in the agent's reach.Ambient credentials on the dev machine are what turn a prompt injection into a breach. Scope developer credentials down, keep long-lived cloud and production keys out of the shell the agent inherits, and assume anything in the environment is exfiltratable.
- •Prompt hardening is not a control here.The injection isn't malformed input a filter can catch — it's a reasonable-looking instruction. 'Tell the model to ignore instructions in files' fails because the model can't reliably tell a legitimate setup step from a planted one. Architecture (isolation, least privilege, human approval) is the control; prompt text is not.
What We Tell Clients
Your developers are already running agentic coding tools against repositories, error trackers, and tickets you don't control. Every one of those is a channel an attacker can write to, and the agent reads all of them as trustworthy context. This is not a Claude Code bug — 0Din, Agentjacking, and TrapDoor all exploit the same shape through different doors, and the same risk applies to Cursor, Codex, and Gemini CLI.
Treat unfamiliar codebases as untrusted, sandbox agents that process them, require human approval before command execution, and strip long-lived secrets out of the environment the agent runs in. The goal is simple: when a poisoned instruction does slip through — and it will — the agent shouldn't be holding the keys to production.
Related Patterns
- Sandboxing— bounds the blast radius when a poisoned instruction executes
- Context Isolation— keeps untrusted content out of the same context as trusted actions
- Dual-LLM (Privileged/Sandboxed)— the privileged model never sees the untrusted content directly
- Human-in-the-Loop— approval gate on the execution step, where poisoning becomes damage
- Indirect Effects— the general case — outputs and inputs crossing trust boundaries
- Supply Chain Attacks— poisoned config files (CLAUDE.md, .cursorrules) ride in via dependencies