Notifications
Clear all
Topic starter
09/07/2026 12:35 pm
TL;DR: Prompt injection in IDEs can hide malicious instructions in code comments, README files, and MCP server responses, causing AI assistants to alter code, leak data, or execute unsafe actions when their outputs are trusted or auto-applied, according to Knostic. The real governance failure is assuming developer tools are safe read-only surfaces when they are now active execution paths.
NHIMG editorial — based on content published by Knostic: Key Insights on Prompt Injection in IDEs
By the numbers:
- 2024 research published by Cornell University found 8.5% of VS Code extensions expose risks, including credential theft.
Questions worth separating out
Q: How should security teams prevent prompt injection in AI-enabled IDEs?
A: Start by treating every AI-generated suggestion as untrusted until a human reviews the diff.
Q: Why do prompt injections in code and documentation matter so much to IAM teams?
A: Because they turn text into an access path.
Q: What breaks when AI assistants are allowed to trust repository content by default?
A: The boundary between source material and instruction breaks down.
Practitioner guidance
- Mandate human review for all AI-generated edits Require diff-based review before any assistant-produced change is merged, especially when the edit touches authentication, secrets handling, or build logic.
- Restrict IDE extension and MCP permissions Limit file read scope, command execution, and network access to the minimum each extension or MCP server needs.
- Reset assistant context after sensitive tasks Purge cached prompts, memory, and conversation history after working on secrets, production code, or incident-related material.
What's in the full article
Knostic's full article covers the operational detail this post intentionally leaves for the source:
- Specific examples of how in-code comments, READMEs, and metadata blocks are used to smuggle prompt instructions into IDE workflows
- The vendor's explanation of how MCP server responses can be manipulated to influence an assistant's interpretation of trusted context
- Hands-on mitigation guidance for diff review workflows, extension permissions, and context purging in developer environments
- Kirin monitoring and policy enforcement details for teams that want to inspect AI-enabled IDE activity in real time
👉 Read Knostic's analysis of prompt injection risks in AI-enabled IDEs →
Prompt injection in IDEs: are your AI-assisted coding controls keeping up?
Explore further
09/07/2026 12:40 pm
AI-enabled IDEs have become a prompt-to-execution pipeline, not a passive drafting aid. The hidden assumption in most development controls is that text is inert until a human acts on it. That assumption fails when an assistant can read untrusted content and immediately turn it into edits, commands, or data movement. The implication is that development governance must separate readable context from executable authority.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should own governance for IDE prompt injection risk?
A: Ownership should sit across application security, IAM, and platform engineering, because the risk spans code review, extension privileges, and tool access. If any one team owns only part of the chain, injected instructions can move from text to action without a complete control path.
👉 Read our full editorial: Prompt injection in IDEs exposes a wider AI code attack surface
