When prompt injection is not controlled, the agent can be steered into unsafe commands, incorrect code changes, or unintended data disclosure. Poisoned context can also persist across tasks, so a bad instruction in a file or comment may influence future outputs. That turns small local mistakes into repeatable security problems across projects and teams.
Why This Matters for Security Teams
AI-assisted development changes the trust boundary. The model is no longer reading only source code and tickets, but also project docs, comments, dependency notes, terminal output, and retrieved context that may be incomplete or adversarial. That makes prompt injection and poisoned context a governance problem, not just a code quality issue. The OWASP Agentic AI Top 10 is a useful lens because it treats instruction hijacking, tool misuse, and unsafe autonomy as operational risks, not theoretical ones.
What practitioners often miss is that the model can act on text that looks ordinary to humans but is functionally executable guidance to the assistant. A poisoned README, a malicious issue comment, or a hidden instruction in a design note can redirect code generation, leak secrets into output, or shape a commit in a way that looks legitimate at review time. This is especially dangerous when assistants are allowed to suggest changes across repositories or automate repetitive tasks. In practice, many security teams encounter the impact only after a bad instruction has already been copied into multiple branches or workflows, rather than through intentional review of context sources.
How It Works in Practice
Prompt injection succeeds when the assistant cannot distinguish authoritative developer intent from untrusted text. In AI-assisted development, the attack surface includes prompts, retrieved documents, issue trackers, pull request comments, build logs, and artifacts generated by earlier tasks. Poisoned project context is similar, except the harmful instruction is embedded persistently in a file, template, or repository asset that the assistant reuses over time. The result can be unsafe code edits, tool calls against the wrong target, disclosure of credentials, or subtle changes that weaken validation and authorization logic.
Current guidance suggests treating all retrieved content as untrusted until it is classified, scoped, and constrained. Security teams should align this with control thinking from NIST SP 800-53 Rev 5 Security and Privacy Controls, especially for access control, system integrity, and monitoring.
- Separate system instructions, developer instructions, and retrieved project text so the assistant can be constrained by precedence.
- Restrict which files, branches, and tickets may be ingested into the model context.
- Validate proposed code changes against policy before merge, not only at review.
- Block secret material, token values, and environment details from being echoed back into prompts or outputs.
- Log context sources used for each task so suspicious instructions can be traced and removed.
For agentic workflows, the risk extends beyond text generation. If the assistant can run tests, open tickets, change code, or invoke deployment tools, an injected instruction can become an execution path. That is why teams increasingly pair guardrails with least privilege, scoped tool access, and human approval for destructive actions. These controls tend to break down when the assistant is allowed to ingest broad repository history or issue archives because malicious instructions can hide in trusted-looking legacy content.
Common Variations and Edge Cases
Tighter context control often increases workflow friction, requiring organisations to balance developer speed against confidence that the assistant is not being steered by hostile text. The tradeoff is real: too much filtering can reduce usefulness, while too little creates a durable attack path.
Best practice is evolving for several edge cases. There is no universal standard yet for how much repository history an assistant should see, how to score trust for retrieved snippets, or when a model should ignore conflicting instructions from nearby context. Projects with regulated data, shared monorepos, or many contributors are more exposed because stale comments, copied templates, and cross-team artifacts accumulate quickly. Multimodal assistants can be even harder to govern when screenshots, pasted logs, or embedded documentation carry instructions that are not obvious in plain-text review.
Security teams should treat poisoned context as a lifecycle issue. Clean prompt design alone is not enough if the retrieval layer, documentation process, or issue workflow keeps reintroducing unsafe instructions. For higher-risk environments, combining allowlisted sources, content signing, and periodic context hygiene reviews is usually more effective than relying on prompt wording alone. This is also where agent governance intersects with the broader agentic AI control set described in the OWASP guidance, because the real failure mode is not one bad prompt but repeated reuse of untrusted context across tasks and teams.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Prompt Injection | Directly addresses instruction hijacking and unsafe agent behavior in AI-assisted development. |
| NIST AI RMF | GOVERN | Governance covers ownership, policy, and oversight for AI systems exposed to poisoned context. |
| NIST CSF 2.0 | PR.AC, PR.DS, DE.CM | Access, data protection, and monitoring controls help limit and detect poisoned context abuse. |
| NIST AI 600-1 | GenAI-specific guidance is relevant where assistants consume untrusted prompts and retrieved text. | |
| MITRE ATLAS | AML.TA0001 | ATLAS maps adversarial techniques that poison model inputs or manipulate model behavior. |
Classify all retrieved context as untrusted and block instructions that try to override system intent.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
