Prompt injection reaches ops AI agents through logs, alerts, PRs and MCP tools

Agents built on text they don't control

An article published on dev.to, titled "Your Agent Reads What Attackers Write," makes a simple but uncomfortable point about operational AI agents: almost everything they consume is text, and much of that text is writable by outsiders.

An incident-triage agent queries Loki for error signatures, but log content originates from applications that log whatever users send them — user-agent strings, request paths, customer-supplied form fields. A Terraform review agent reads pull request titles, bodies and diffs, where the description is filled in by whoever opened the PR. Alert labels inherit metadata from scrape targets the operator may not control. The author's core argument is that an agent's entire picture of reality is assembled from strings strangers can influence, and the underlying model has no reliable mechanism for telling data apart from instructions.

Five channels, all writable from outside

The post enumerates five injection surfaces for a typical ops agent:

1. Log lines, where a planted instruction sits in the same context window as the runbook and is treated as ground truth.
2. Alert labels and annotations, populated through relabeling rules applied to scraped targets.
3. PR bodies and diffs, which the reviewer ingests as a statement of intent — the author notes that "this change is safe" is a claim, not evidence, and the agent is primed to agree with it.
4. Runbooks and RAG-retrieved documentation, editable by anyone with wiki access, a much larger group than the agent's own authors.
5. MCP tool descriptions, which agents trust by construction because they come from third-party servers.

On that last channel, the article cites a February 2026 finding that the Context7 MCP documentation server was serving attacker-registered "Custom AI Instructions" to connected coding agents (CVE-2026-75130, CVSS 9.0), and August 2026 disclosures that MCP's response cache could turn a single poisoned server response into a cross-user injection channel. It also reports that researchers have fragmented malicious instructions across many benign-looking tools so that no individual tool appears suspicious.

Why hardening the prompt doesn't work

The reflexive fix — telling the model in the system prompt to ignore instructions found in tool output — barely helps, according to the author, because there is no structural firewall between instructions and data, only a context window full of text the model tries to make sense of.

The post points to supporting evidence: a joint OpenAI, Anthropic and Google DeepMind evaluation from October 2025 that subjected twelve published prompt-injection defenses to adaptive attackers, with most reportedly failing at attack success rates above 90%. Keyword-based detectors are described as failing in both directions, with the same phrases appearing in blocked and successful requests. The article also notes that OWASP's LLM Top 10 (2025) ranks prompt injection as LLM01 and explicitly covers the indirect variant, where instructions arrive through retrieved content rather than the user. Delimiter wrappers around untrusted content are good practice but are a signal, not a cryptographic boundary — a determined payload can forge the markers or phrase itself to survive them.

Containment as the working strategy

The article's operating assumption is pessimistic by design: assume the injection succeeds and the model wants to comply, then shrink what compliance can accomplish. Its recommendations include:

• Wrapping every tool result in explicit markers named in the system prompt, which won't stop targeted attacks but makes trust zones visible in later log analysis.
• Scoping the agent's tools to the minimum, which the author calls the highest-leverage change: a triage agent with read-only credentials and no write tools can at worst produce a misleading note, while one holding kubectl delete privileges is a far riskier proposition.
• Simon Willison's dual-LLM pattern, in which a quarantined model with no tools or permissions reads untrusted content and passes structured summaries to a privileged model that holds the tools but never sees raw external text.
• Deterministic output validation: schema-constrained outputs, redaction filters before anything reaches shared channels, and allow-lists on proposed actions.
• Keeping a human on every write path — agents recommend a next step with a confidence level but never execute it.
• Red-teaming the agent's own loop with a payload battery covering direct overrides, fake authority, marker forgery and injections hidden in log fields and PR comments.

Why it matters

As AI agents move from answering questions to reading production telemetry and touching real infrastructure, the security boundary shifts from what the model reads to what it can do. The dev.to article's practical takeaway is that indirect prompt injection cannot be reliably prevented at the prompt layer — the controllable variable is the blast radius an injected agent can reach. Teams deploying triage, review or coding agents should treat every retrieved document, log line and tool description as hostile input, provision credentials on that assumption, and test their agents the way attackers actually use them.