Prompt injection: what changes when agents trust poisoned context?

TL;DR: Opus 5 now resists prompt injection, according to Silmaril, yet its own test path still showed a poisoned Sentry error steering an AI coding agent into unsafe recovery actions and host-level installation. The real boundary is not model compliance but whether agents can treat external context as untrusted until policy, provenance, and runtime controls verify it.

Editorial analysis by NHI Mgmt Group, based on content published by Silmaril: “The Race Is Never Over”.

Key questions

Q: What breaks when AI coding assistants ingest poisoned repository context?

A: What breaks is the assumption that project text is passive and trustworthy.

Q: Why do coding agents create higher risk than chatbots or copilots?

A: Coding agents create higher risk because they do work, not just answer questions.

Q: What are the signs that prompt injection defenses are missing the real problem?

A: The clearest sign is a strong detector score on obvious override phrasing but poor coverage of plain requests that still trigger tool use.

Practitioner guidance

• Gate external context before agent consumption Classify error logs, issue text, and retrieved documents as untrusted until they pass provenance and content checks.
• Remove standing ability to change shared runtimes Block unattended package installation, file modification, and environment changes from agent workflows unless a human or policy engine explicitly approves the action.
• Separate diagnosis from remediation Allow agents to inspect, summarise, and propose fixes, but require explicit approval before they can apply a fix that writes to disk, changes dependencies, or reaches production-like systems.

Bottom line: The core issue is not only whether the model can resist prompt injection, but whether the surrounding agent workflow can stop untrusted context from becoming privileged action.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →