AI coding assistants expand the software supply chain trust boundary

At a glance

What this is: SentinelOne argues that AI coding assistants are now part of the software supply chain, and a compromised plugin skill can silently redirect dependency installs to attacker-controlled sources.

Why it matters: For IAM, PAM, and NHI practitioners, the key issue is that agentic tools inherit trust boundaries, privilege, and persistence that conventional application controls do not model well.

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.

👉 Read SentinelOne's analysis of AI coding assistant plugin risk and dependency redirection

Context

AI coding assistants are no longer just text completion tools. They can plan changes, install dependencies, and modify code with enough autonomy that the security boundary shifts from the developer’s prompt to the assistant’s runtime trust chain. That matters because the article’s core issue is not only code generation, but the security implications of allowing third-party plugins to influence what the assistant fetches and executes.

In identity terms, these assistants behave like high-privilege non-human identities with persistent access across sessions. Once a marketplace skill can direct dependency resolution, it sits inside the same governance problem space as service accounts, API keys, and other NHI patterns that outlive a single task. That makes plugin trust, provenance, and access scoping a governance issue rather than a productivity feature. The starting position described in the article is increasingly common, not exceptional.

Key questions

Q: How should security teams govern AI coding assistants that can install dependencies?

A: Treat them as delegated execution systems, not just productivity tools. Put approval gates around package installation, enforce trusted source lists, log every tool call, and revoke plugin authority when a task ends. If the assistant can fetch and run code, it belongs inside your supply chain and privilege governance model.

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. A compromised plugin can redirect installs, introduce malicious code, and still look successful from a functional perspective. That makes provenance and source control as important as code review.

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. In reality, a plugin can persist across sessions, influence future actions, and act like standing privilege. That means plugin lifecycle, review, and revocation need the same discipline as other non-human identities.

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.

Technical breakdown

How marketplace skills reshape the trust boundary in coding assistants

A coding assistant that can read projects, modify files, and install packages is not just suggesting text. It is executing work inside a delegated trust boundary. Marketplace skills extend that boundary by adding third-party logic that can influence decision paths, dependency selection, and tool invocation. The risk is not only that the plugin is malicious, but that it can behave as trusted infrastructure while hiding its true provenance. In effect, the assistant becomes a software supply chain actor with its own access pattern, execution context, and persistence model.

Practical implication: treat every enabled skill as a governed dependency with approval, inventory, and revocation controls.

Dependency redirection as a compromised automation pattern

The attack described in the article is closer to package manager compromise than prompt injection. When a skill redirects an install request to an attacker-controlled source, the assistant still appears to complete the task successfully, but the environment now contains trojanized code. That means the compromise can survive normal functional checks because imports still work and demo code still runs. This is a supply chain problem at the point of dependency resolution, where trust is assigned to the automation path rather than to the package origin or signing chain.

Practical implication: verify dependency provenance and block unapproved sources before any assistant is allowed to install code.

Persistence across sessions turns plugins into long-lived access paths

The article’s persistence point matters because marketplace skills do not behave like one-time prompts. Once enabled, they remain available across sessions and can continue shaping behaviour long after the initial install. That makes them more like standing privilege than ephemeral assistance. From a governance perspective, the assistant accumulates operational memory and execution influence without the same review cadence applied to human-administered change processes. This is where AI governance and NHI governance converge: long-lived delegated capability needs lifecycle control, not just content filtering.

Practical implication: build offboarding, rotation, and session-bound approval steps for AI tools that retain execution authority.

Threat narrative

Attacker objective: The attacker wants to seed trusted development environments with malicious code while preserving the appearance of normal package installation and assistant behaviour.

1. Entry occurs when a benign-looking marketplace plugin is enabled inside the coding assistant, giving the attacker a trusted execution path through third-party automation.
2. Escalation happens when the dependency management skill redirects a normal install request to an attacker-controlled package source, replacing legitimate code with a trojanized version.
3. Impact follows when the malicious package lands in the development environment and can exfiltrate secrets, monitor traffic, or remain dormant until triggered.

NHI Mgmt Group analysis

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.

Dependency redirection is a control failure, not a prompt-safety issue. The article is valuable because it shifts the risk model away from social engineering and toward compromised automation. A skill that silently routes installation to an attacker source exploits blind trust in tool orchestration, not developer intent. That makes code signing, source allowlisting, and package provenance part of the AI security conversation. The practical conclusion is that assistant workflows need source validation before autonomy expands.

Persistence is the real governance gap in plugin-enabled assistants. The article shows that once a skill is enabled, it can continue influencing behaviour across sessions, which is functionally closer to standing privilege than ephemeral assistance. That is the same class of problem identity teams see with service accounts that outlive the task they were created for. Persistent assistant authority: when a tool retains execution influence beyond a single task, lifecycle control becomes the primary defence. Teams should manage these plugins as durable identities with offboarding, review, and revocation paths.

The security boundary has moved from the code editor to the assistant’s decision layer. Developers may think they are approving an install, but the assistant is choosing sources, dependencies, and in some cases execution timing. That makes governance dependent on visibility into tool calls, not just source code review. For IAM and PAM teams, the lesson is that delegated machine actions need least privilege and auditable approval paths. Practitioners should redesign controls around the assistant’s runtime authority, not the developer’s keyboard.

What this signals

Persistent assistant authority is the operational concept teams should watch. Once a plugin can survive beyond a single task, it starts to resemble a long-lived machine identity, which means offboarding and revocation matter as much as approval. That is why the move to task-scoped governance belongs alongside least privilege, provenance checks, and auditable tool calls.

The next programme maturity test is whether security teams can see which assistant plugin selected a dependency, which source it used, and whether that choice was policy-compliant. If they cannot, they lack the evidence needed to govern autonomous development safely. Teams should align controls to the runtime behaviour of the assistant, not the apparent safety of the prompt.

As AI-assisted development expands, organisations will need to connect code supply chain controls with identity controls around delegated execution. The strongest control set will combine package provenance, plugin inventory, and lifecycle management for persistent automation. That is where NHI governance begins to overlap with software delivery governance in a practical way.

For practitioners

• 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. Require formal approval before any skill can influence dependency installation or infrastructure changes.
• Block unapproved dependency sources Force assistant workflows to resolve packages only from trusted repositories and signed artefact stores. If a skill attempts to redirect an install request, quarantine the action and require manual review before the package enters the build environment.
• 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. Persistent plugins should not retain unrestricted access across projects or sessions.
• Add telemetry for assistant-driven tool calls Log which plugin initiated each dependency request, which source was selected, and whether the install path deviated from policy. Feed those events into SIEM or SOC workflows so anomalous package routing is detectable.

Key takeaways

• AI coding assistants now influence code supply chain decisions, so plugin governance has become an identity and privilege problem as much as a developer productivity issue.
• A malicious marketplace skill can redirect dependency installs while preserving normal-looking behaviour, which makes provenance controls and source allowlisting essential.
• Persistent assistant authority needs lifecycle management, task scoping, and revocation controls, or the tool becomes standing privilege with a friendlier interface.

Key terms

• Compromised Automation: A failure mode where a trusted tool path is altered so that normal-looking actions execute attacker-controlled logic. In AI coding assistants, this means the system appears to complete a routine task while silently changing where code or dependencies come from.
• Persistent Assistant Authority: The ability of an AI tool or plugin to retain influence beyond a single interaction or task. This is important because long-lived authority behaves like standing privilege, creating lifecycle and revocation requirements that look more like identity governance than simple application security.
• Dependency Redirection: The act of steering a package install or build process away from the intended trusted source to an attacker-controlled one. It is dangerous because the resulting code may still function normally, letting malicious content enter the environment without immediate detection.

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.

👉 SentinelOne's full blog post covers the attack mechanics, persistence model, and dependency-hijack path in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners design lifecycle controls for delegated systems that retain access beyond a single task.