Prompt injection is not a bug you can patch; it is a fundamental limitation of how Large Language Models process text. As defined by a recent DEV.to deep dive, it occurs when attacker-controlled text ends up in a model's context window, causing the model to execute the attacker's instructions rather than the developer's original intent. For builders deploying AI agents, this means every input sourceβ€”web pages, emails, GitHub issues, or tool responsesβ€”is a potential vector for hijacking.

The Shift from Direct to Indirect Attacks

While direct injection involves a user typing malicious commands into a chat interface to bypass system prompts, indirect injection is the primary concern for autonomous agents. In this scenario, the attacker never interacts with the model directly. Instead, they plant instructions in data the agent will read later. A concrete example provided by Invariant Labs demonstrated this against the GitHub MCP server: an attacker opened a public issue with hidden instructions, and when a developer asked their agent to review open issues, the agent inadvertently pulled private repo data and opened a pull request. The developer’s routine request served as the delivery mechanism for the attack.

Why There Is No Syntax Fix

Unlike SQL injection, which was solved by parameterized queries that separate code from data, LLMs lack a formal syntax to distinguish between instructions and content. Simon Willison, who coined the term following a 2022 GPT-3 demo by Riley Goodside, noted that there is no formal syntax for AI instructions. Current mitigations like delimiters or explicit 'ignore previous commands' tags are fragile; determined attackers can bypass them with minor textual rewrites. Consequently, OWASP ranks prompt injection as the top risk in its 2025 list for LLM applications, highlighting that better models simply move the goalposts rather than removing the threat.

Mitigation Through Access Control

Since preventing the model from being fooled is currently impossible, the practical defense lies in limiting what a fooled agent can actually do. The most effective strategy is narrowing tool access and maintaining rigorous audit logs. If an agent reading GitHub issues does not have permission to access private repositories or create pull requests, the injected instruction has no actionable path. Gateways like Statio implement this by granting tools per agent and scanning tool responses for injected instructions before they reach the model. This approach shifts the focus from trying to make the model un-foolable to making the consequences of being fooled manageable.

Key Takeaways

  • Indirect injection allows attackers to hijack agents via public data sources like GitHub issues without direct user interaction.
  • There is no technical equivalent to parameterized queries for LLMs, making prompt injection an architectural reality rather than a fixable bug.
  • The primary defense is restricting agent permissions (least privilege) and logging all tool calls to contain the blast radius of an attack.

The Bottom Line

Stop trying to teach your agent to distrust input; instead, strip it of the permissions it doesn't strictly need for its specific task. If your agent can merge code, assume it will eventually be tricked into doing so.