Understanding the Injection Risk
Coding agents now have access to shell commands, git credentials, package-manager permissions, and cloud tokens. A successful prompt injection can escalate from a simple error to serious issues like code execution, data exposure, and unapproved commits. The model can't reliably distinguish between instructions and data when both are text, so relying solely on model-level defenses won't prevent these attacks.
Simon Willison, who coined "prompt injection," warns: "We're due a Challenger disaster with respect to coding agent security... so many people, myself included, are running these coding agents practically as root."
The main threat isn't what developers type. It's the untrusted context agents pull from repositories, issues, fetched pages, and tool endpoints. This inbound path is where most defenses fail.
Key Findings
Finding 1: Indirect injection is the primary threat
Indirect injection hides malicious instructions in data the agent reads, like a poisoned code comment or a README. Developers don't see the payload; the agent encounters it in routine work material. Since coding agents read untrusted repositories and issues as part of their job, this is the dominant risk.
Finding 2: Tool endpoints expand the attack surface
Tool integrations can return attacker-controlled content or change their definitions after approval. A tool safe on Monday might reroute calls by Friday, turning a trusted integration into a threat. Malicious text seeded into a code-search index or documentation can be retrieved and misused later.
Finding 3: Model-level guardrails are bypassable
Teams use delimiters around untrusted text and harden system prompts, but these measures only reduce injection rates. Attackers adapt with nested payloads and encoding tricks. The model can't reliably separate instruction from data when both are text.
Finding 4: Runtime enforcement must inspect both request and response paths
Pre-LLM guardrails screen inbound context for injection payloads. Post-execution guardrails inspect outputs before they're returned or executed. Coding agents need both because threats enter on the way in and damage occurs on the way out. Guardrails decide: Allow, Block, or Redact.
Finding 5: Observability is essential for automation
You can't give an agent more autonomy than you can observe. Span-level telemetry should capture every tool call and output. Key signals include anomalous tool sequences, sudden token spikes, and drift toward unsafe outputs.
Implications for Your Team
Your coding agents read untrusted content by design. Every GitHub issue, fetched dependency README, and code snippet is a potential injection vector. If your defense strategy stops at prompt engineering and input filtering, you're using controls attackers already bypass.
The shift needed is architectural. Prevention must move from the prompt to the system around the model. Rethink how you structure agent inputs, scope credentials, contain blast radius, and enforce policies at action execution.
The Fiddler AI Control Plane provides inline enforcement on the agent's request and response path, powered by Fiddler Centor Models that run in-environment with no external API calls and under 100ms response time. Models only process approved inputs, and developers only receive approved outputs.
Action Items by Priority
Priority 1: Map your untrusted input surface
Inventory every source of external content your agents consume: repositories, issue feeds, fetched pages, tool returns, and retrieval indexes. Document which sources can be modified by outsiders. This is your injection attack surface.
Priority 2: Separate trusted instructions from untrusted context
Structure prompts so system instructions, developer intent, and untrusted content are in distinct, labeled channels. Retrieved content should enter as data only, not as a command channel. Strip known injection patterns from comments, docs, and fetched pages before the agent processes them.
Priority 3: Implement least-privilege tool scoping
Grant the narrowest tool set and fewest permissions each task requires. A test-fixing session doesn't need force-push rights or production database access. Redact secrets, PII, and credentials by default. Keep credentials out of model context entirely, and inject short-lived tokens through a proxy at call time.
Priority 4: Add runtime enforcement on both request and response paths
Deploy guardrails that inspect inputs before they reach the model and outputs before they execute. Use verdict types that match the threat: Block for full-request injection attempts, Redact for secrets or PII in otherwise valid requests, and Allow for clean actions. Enforcement must happen inline, before data leaves the environment or an action executes.
Priority 5: Deploy span-level observability across the agentic hierarchy
Capture every tool call, sub-agent output, and decision branch. Build decision lineage that traces an instruction from the inbound source, through the tool calls it triggered, to the action it produced. When an injection slips through, this lineage turns a mystery incident into a root-cause analysis.
Priority 6: Re-verify tool definitions on a schedule
Don't trust a one-time approval. MCP tools and other integrations can mutate after approval. Implement periodic re-verification of tool definitions and monitor for changes in behavior patterns.
