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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on SentinelOne's blog post: AI coding assistants and third-party plugins expand the software supply chain trust boundary by letting a benign-looking skill redirect dependency installs and persist risky behaviour across sessions.
Why it matters: IAM and security teams need to treat AI coding assistants as governed actors in the development chain, because their plugin trust, dependency access, and persistent behaviour can reshape supply chain risk.
Context
AI coding assistants are moving from suggestion engines to delegated operators that can change files, install packages, and carry decisions across sessions. That shifts the control problem from prompt hygiene to trust in third-party skills, dependency sources, and the privileges those skills inherit inside the development workflow.
The governance gap is that marketplace plugins can look like productivity add-ons while operating with the reach of a package manager extension. Where AI-driven development already depends on reusable credentials, signed dependencies, and change control, a plugin that rewrites install sources creates a software supply chain risk with a clear identity angle around delegated machine actions.
Key questions
Q: What breaks when AI coding assistant plugins can install dependencies on behalf of developers?
A: The trust model breaks because the assistant becomes part of the software delivery path, not just a drafting aid. If a plugin can redirect dependency sources, the organisation must govern provenance, permission scope, and review of the assistant’s actions. Otherwise, a harmless-looking skill can smuggle untrusted code into builds while everything appears normal.
Q: Why do AI agent skills create supply chain risk in enterprise environments?
A: AI agent skills create supply chain risk because they can look harmless in review while delivering malicious behavior only when executed. If an agent accepts untrusted content and acts on it, attackers can hide instructions, pull payloads from remote servers, or abuse the agent as a dropper. The risk grows when organisations rely on popularity or static checks as proof of safety.
Q: How can security teams reduce the risk of malicious dependency redirection?
A: Teams should limit which assistants can touch package sources, require provenance checks for assistant-driven installs, and log any change to mirrors, indexes, or dependency paths. Review should cover the source of the package as well as the resulting build, because clean execution does not prove the dependency was trustworthy.
Q: Should organisations treat AI coding agents like privileged software identities?
A: Yes. If an AI agent can install code, access secrets, or modify repositories, it is functionally acting as a privileged non-human identity and should be governed that way. That means task-scoped access, explicit boundaries, and monitoring of its downstream actions, especially when it can touch build and release systems.
Technical breakdown
How plugin-driven dependency skills reshape the trust boundary
AI coding assistants become materially different once they can execute multi-step tasks, manage dependencies, and retain state across sessions. A marketplace plugin or skill is not just an extension of the chat interface. It can influence where code is fetched from, what gets installed, and how future actions are steered. That makes the assistant part of the software delivery path, not a separate UI layer. The core security issue is delegated authority: the agent inherits enough privilege to act like a package manager with judgment, but without the visibility or policy controls that normal build tooling usually provides.
Practical implication: Treat AI assistant plugins as supply chain components and govern their permissions, provenance, and allowed actions before enabling them.
Why malicious dependency redirection is hard to spot
The dangerous part of this pattern is that the malicious behaviour can be functionally invisible at install time. A library may import correctly, sample code may run, and no obvious error is raised while the assistant silently points dependency retrieval at an attacker-controlled source. That means traditional validation focused on prompt output or compilation success misses the risk. The problem is not obvious breakage, but trusted substitution inside the dependency path. For defenders, this is a provenance problem as much as an application security problem, because the build receives a package that looks legitimate but was sourced through an untrusted decision chain.
Practical implication: Inspect package provenance and enforce approved source controls for assistant-driven installs, not just for manual developer actions.
Why persistence across sessions changes the control model
Marketplace skills are not one-off prompts. Once enabled, they can keep shaping the assistant’s behaviour across later sessions, which makes them closer to persistent policy than transient user input. That persistence matters because a single compromised skill can continue to influence installs, file edits, and workflow decisions long after the initial approval moment. In practice, this collapses the assumption that AI actions are isolated to one conversation or one task. Governance has to move from session review to lifecycle management, including approval, periodic recertification, and removal when the plugin is no longer needed or trusted.
Practical implication: Build a lifecycle process for AI plugins so persistent skills are reviewed, recertified, and offboarded like other privileged integrations.
Threat narrative
Attacker objective: To smuggle attacker-controlled code into a trusted development environment through an AI assistant’s delegated dependency decisions.
- Entry occurs through a benign-looking marketplace plugin or skill that is enabled inside the coding assistant.
- The skill redirects dependency installation to an attacker-controlled source while the assistant performs the requested task.
- Trojanized code enters the project and can remain available for later execution, secret theft, or traffic monitoring.
- Impact is achieved when the supply chain is trusted enough that malicious code persists inside normal development workflows.
Breaches seen in the wild
- Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Plugin trust is now supply chain governance, not just tool selection. Once AI coding assistants can install packages and carry state across sessions, the trust boundary extends to every skill that can influence those actions. That means the control question is no longer whether the assistant is useful, but whether the organisation can prove provenance, constrain privilege, and revoke risky integrations quickly enough. Practitioners should treat marketplace skills as governed supply chain actors, not optional productivity extras.
Persistent assistant behaviour creates a new class of hidden dependency risk. A plugin that remains active across sessions can keep steering package retrieval long after the original approval decision. That persistence weakens assumptions that code changes are reviewed at the moment they happen, because the real decision may already have been encoded in the assistant’s workflow. Security teams should look for a named concept here: trust boundary inflation, where a narrow coding aid becomes a durable supply chain control point.
The main failure mode is not prompt injection, but delegated execution without source assurance. This article is about automation that looks benign while substituting untrusted software under the hood. That is a different governance problem from model safety or chat abuse: it is a provenance and authorisation issue inside the delivery chain. Teams should respond by narrowing which assistants can touch dependencies, not by assuming output review alone will catch compromise.
Identity governance now has to include non-human development actors. If an AI assistant can fetch code, rewrite files, and persist a skill set, it is functioning like a non-human operator with standing authority. That creates an NHI-style governance problem even in a software supply chain context, because access scope, approval, and offboarding all become relevant to the assistant itself. Practitioners should extend identity controls to these machine actions before they become normalised.
Software supply chain control must shift left into assistant configuration. The article shows that the dangerous decision can occur before a developer ever inspects a diff. Once the assistant chooses the source, the rest of the pipeline may simply process the compromise. That makes plugin approval, dependency source policy, and session-level auditing part of supply chain assurance, not post-build hygiene.
From our research library:
- Developers using GenAI tools like GitHub Copilot are reporting 35% productivity gains, according to IDC’s 2024 Generative AI Study.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: AI Coding Agents Security Guide
What this signals
Trust boundary inflation: AI coding assistants are becoming durable actors inside the delivery chain, so the governance question moves from whether to use them to how far their authority extends. If a plugin can keep steering dependency behaviour across sessions, then approval, recertification, and offboarding become part of software supply chain control, not admin housekeeping.
The practical signal for teams is that assistant configuration is now a control surface. Source allowlisting, plugin provenance, and dependency path restrictions need to sit alongside standard build validation, because output review alone will not catch a trusted substitution upstream.
For practitioners
- Govern assistant plugins as supply chain components Inventory every marketplace skill or plugin that can install code, modify files, or persist behaviour across sessions, then require approval for each one based on provenance and access scope.
- Restrict dependency source redirection Block assistants from changing package indexes, mirrors, or repository targets unless those sources are explicitly approved and logged under change control.
- Audit persistent plugin permissions Review which skills remain enabled between sessions and remove any that no longer have a documented business need or an owned approval record.
- Validate assistant-driven installs separately Require provenance checks for packages fetched by an assistant, including source verification, checksum validation, and review of any unexpected dependency path.
- Extend identity governance to machine actors Map AI coding assistants to an accountable owner, a scoped role, and an offboarding process so plugin access can be revoked like any other privileged integration.
Key takeaways
- AI coding assistants can expand the software supply chain trust boundary by making dependency choices on behalf of developers.
- The main risk is not prompt failure, but delegated automation that can redirect installs, persist behaviour, and hide malicious substitutions.
- Security teams need governance over assistant plugins, dependency sources, and offboarding, because the machine actor now sits inside the trusted path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party plugins and skills create the trust gap the article focuses on. |
| NHI-05 — Overprivileged NHI | The article shows skills operating with more privilege than a narrow task should require. | |
| NHI-09 — NHI Reuse | Persistent skills reuse the same authority across sessions and tasks, expanding blast radius. | |
| Recommendation — Vet third-party assistant plugins as dependent software assets and remove any untrusted source path. Constrain assistant plugin permissions to the minimum actions needed for the workflow. Limit reuse of persistent assistant authority and reauthorise skills before they continue to operate. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The payload can steal secrets and exfiltrate data once malicious code lands in the environment. |
| Recommendation — Map malicious dependency activity to credential access and exfiltration techniques in detection and hunting. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Assistant plugins need explicit entitlement controls and ownership. |
| Recommendation — Apply PR.AA-05 to scope assistant plugin entitlements and review who can approve them. | ||
Key terms
- AI coding assistant: An AI coding assistant is software that helps write, refactor, debug, or navigate code using model-driven suggestions and sometimes command execution. In practice, it can become part of the operational control plane if it has access to files, terminals, and external tools that can change a system.
- Plugin Marketplace: A plugin marketplace is a distribution channel for third-party extensions that add capabilities to an AI assistant or development tool. The governance risk is that the extension may inherit trust and permissions well beyond its original design, especially when it can influence code sourcing, installs, or persistence.
- Software Supply Chain Trust Boundary: The software supply chain trust boundary is the point where an organization decides which software components, build systems, dependencies, and delivery steps it will trust. It defines where verification must occur. Technically, it includes source, build, signing, packaging, distribution, and update paths, plus the identities and controls that govern each stage.
- Persistent Plugin Behaviour: Persistent plugin behaviour is the ability of an installed assistant skill to keep shaping later sessions, not just the current request. That persistence matters because it turns a temporary task helper into a standing influence point, increasing the need for approval, review, and removal controls.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps practitioners extend identity thinking to non-human actors and the controls that govern them.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org