Notifications
Clear all
Topic starter
11/07/2026 2:00 pm
TL;DR: AI coding assistants can install dependencies, modify files, and persist plugin-driven behaviours across sessions, which means a benign-looking marketplace skill can redirect package installs to attacker-controlled sources and embed trojanized code, according to SentinelOne. That shifts the core question from prompt safety to supply chain trust, where unchecked automation becomes the attack surface.
NHIMG editorial — based on content published by SentinelOne: AI coding assistants and the hidden risk in marketplace plugins
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, meaning organisations failing to scope AI access properly are 4.5x more likely to experience a security incident.
Questions worth separating out
Q: How should security teams govern AI coding assistants that can install dependencies?
A: Treat them as delegated execution systems, not just productivity tools.
Q: Why do AI coding assistants create new supply chain risk?
A: Because they can select and execute dependencies on behalf of a human, which moves trust from the developer to the automation layer.
Q: What do teams get wrong about marketplace plugins for AI tools?
A: They often treat plugins as optional productivity add-ons rather than durable access paths.
Practitioner guidance
- Inventory every enabled assistant skill and plugin Maintain a live register of all marketplace skills connected to coding assistants, including publisher, source, privilege scope, and last review date.
- Block unapproved dependency sources Force assistant workflows to resolve packages only from trusted repositories and signed artefact stores.
- Bind assistant actions to task-scoped approvals Apply the same control logic used for high-risk NHI or PAM workflows: short-lived authority, explicit scope, and revocation at task completion.
What's in the full article
SentinelOne's full blog post covers the operational detail this post intentionally leaves for the source:
- A step-by-step walkthrough of how a dependency management skill redirects package installation to an attacker-controlled source.
- The attack sequence showing how a trojanized library can still import cleanly while hiding malicious behaviour in the environment.
- The persistence model for marketplace skills and why enabled plugins continue to influence future assistant actions.
- The specific risk indicators teams can use to detect assistant-driven source switching before malicious code lands in the build path.
👉 Read SentinelOne's analysis of AI coding assistant plugin risk and dependency redirection →
AI coding assistants and plugin trust: what security teams need to know?
Explore further
11/07/2026 2:10 pm
AI coding assistants are becoming software supply chain actors, not just developer productivity tools. Once an assistant can fetch, install, and execute code, it inherits a trust boundary that used to belong to package managers and build systems. That means plugin governance, provenance checks, and execution scoping now sit inside the same control problem as NHI governance. Practitioners should treat assistant-mediated dependency handling as a governed supply chain path, not a convenience feature.
A question worth separating out:
Q: What is the difference between prompt injection and compromised automation in AI tools?
A: Prompt injection manipulates what the model says or does through crafted input, while compromised automation alters the tool path itself. In this article, the risk is the latter: a plugin quietly changes where dependencies are pulled from. That is a governance problem around trusted execution, not just unsafe prompts.
👉 Read our full editorial: AI coding assistants expand the software supply chain trust boundary
