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.
How the Delivery Path Changes When a Plugin Can Install Dependencies
Once an ai coding assistant can install dependencies, it is no longer just generating text or proposing code. It can influence what enters the build, what gets trusted by default, and which sources are treated as acceptable. That shifts the control question from “Is the suggestion good?” to “Who is allowed to act on supply-chain inputs, and under what review and provenance rules?”
The practical break is that dependency installation is a privileged delivery action. If the assistant can choose packages, registries, versions, or install commands, it can affect integrity even when the developer believes they are merely accepting help. That is why the security boundary must extend into the assistant’s execution path, not stop at the editor prompt.
A related concern is AI Coding Agents Security Guide, which treats coding assistants as part of the software delivery pipeline and not just a convenience layer.
What New Trust Decisions Appear in the Build Chain?
Dependency installation introduces three decisions that teams often leave implicit: provenance, permission scope, and human approval. Provenance asks where the package came from and whether it was expected. Permission scope asks what the plugin can reach, modify, or invoke. Human approval asks which actions need review before they become part of the repository, lockfile, or build artifact.
If those decisions are not explicit, the assistant can become a silent policy bypass. A prompt, a plugin, or a tool call may route a dependency through an alternate registry, introduce a transitive package, or refresh a lockfile in ways that are hard to spot in normal code review. This is especially dangerous when the installed component later inherits the project’s build-time or runtime trust.
The broader identity and delegation model matters here because the assistant is acting on behalf of a developer, which is why Agentic AI Identity Guide is useful for understanding delegated authority, lifecycle, and agent ownership. For the delegation mechanism itself, RFC 8693: OAuth 2.0 Token Exchange is the cleanest model for on-behalf-of flows.
What Breaks Operationally if the Assistant Can Act Unchecked?
The immediate failure mode is supply-chain compromise through a trusted workflow. An assistant that can install dependencies may be tricked into pulling a typo-squatted package, a poisoned version, or an unexpected source that still looks normal in logs. The developer sees a successful install, but the build has already accepted an unreviewed trust decision.
The second failure mode is review drift. Teams may still review code changes, yet miss tool-driven changes to dependency manifests, lockfiles, installer flags, or cache state. That creates a gap between visible source code review and invisible build-time behavior. The larger the organisation and the more automated the workflow, the more that gap behaves like an approval bypass rather than a convenience feature.
That is why dependency actions should be governed like any other software supply-chain event, especially where package sources, install scripts, and token scope can change the outcome. Internal guidance such as JetBrains Marketplace AI Plugin Campaign and Amazon Q MCP config vulnerability 2026 show how plugin trust and workspace trust can be abused when tool actions inherit more authority than intended.
Risk and Threat Considerations
When a coding assistant can install dependencies, the main risk is not only malicious code, but unaudited code path expansion. Attackers do not need to defeat the whole development environment if they can influence package selection, dependency resolution, or the assistant’s tool permissions. That turns the assistant into a high-value abuse point for supply-chain insertion, privilege overreach, and hidden execution.
Failure mechanism: The assistant is granted enough authority to modify the build path, then is steered toward untrusted sources, unexpected versions, or installer behavior that escapes normal review.
Impact: Untrusted code can enter builds, transitive dependencies can widen blast radius, and a seemingly routine productivity feature can become a trusted path for persistence or compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V13 — Configuration | Plugin-driven installs change build and dependency configuration. |
| Recommendation — Require review and approval for changes to dependency sources and install behavior. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Controls who may alter software delivery inputs and build settings. |
| SA-10 — Developer Configuration Management | Covers provenance and integrity of software components entering builds. | |
| Recommendation — Restrict and approve assistant-driven changes to build inputs and registries. Verify dependency provenance before allowing automated installation. | ||
| SLSA | Supply Chain Integrity | The subject is dependency trust in the software supply chain. |
| Recommendation — Adopt supply-chain controls that preserve provenance across automated installs. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | Assistant plugins consume package and registry interfaces that can be abused. |
| Recommendation — Treat dependency and registry calls as unsafe until authenticated and bounded. | ||
Practitioner Guidance
What to prioritise: Treat dependency installation as a controlled action, not a background convenience. The first question is whether the assistant can change package sources, execute install hooks, or rewrite lockfiles without a separate approval step.
What to verify: Confirm that provenance checks, source allowlists, and review gates still apply when the action is initiated by a plugin rather than a person. If the assistant can reach production-scoped credentials or trusted registries, assume the workflow is over-permissioned until proven otherwise.
What good looks like: The assistant may suggest dependencies, but it cannot silently promote them into the build chain. The resulting state should be observable, attributable, and bounded by the same controls you would require for any other automated change to software supply inputs.
Practitioner takeaway: The key decision is whether the plugin is allowed to influence trust, not just productivity. If it can install dependencies, you are governing a delivery actor, so restrict its authority to the smallest reviewable slice of the build path.
Related resources from NHI Mgmt Group
- What breaks when AI coding agents automatically install poisoned npm packages?
- What breaks when developers paste AI provider keys into IDE plugins?
- What breaks when an AI coding assistant is allowed to read files but not inspect data sensitivity?
- What breaks when an AI coding assistant executes project content before trust is confirmed?