IDE extension security exposes a new attack surface for AI coding agents

At a glance

What this is: This blog post argues that IDE extensions have become a live execution surface for AI-assisted development, with AI-powered plugins, MCP connectors, and shell access creating a new class of workspace risk.

Why it matters: It matters because developer tools now sit on the boundary between code, credentials, and automation, so IAM, secrets, and NHI governance must extend into the IDE itself.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Knostic's analysis of IDE extension security and AI coding agent risk

Context

IDE extensions are no longer simple productivity add-ons. In practice, they operate inside the developer's trusted workspace, where they can read files, trigger shells, call external APIs, and influence what AI assistants do next. That makes IDE extension security a governance problem for code, credentials, and machine actions at the same time.

The core failure is trust without verification. Once an extension can run commands, cache secrets, or interact with MCP connectors, traditional endpoint controls see only part of the picture. For IAM and NHI teams, the question is whether the IDE is being treated as a controlled execution environment or as an unreviewed extension marketplace.

The article's starting position is typical for modern development teams: lots of extensions, limited review, and growing reliance on AI-assisted workflows. That combination creates a broad attack surface before a single malicious package is installed.

Key questions

Q: How should security teams govern IDE extensions that can execute commands and access secrets?

A: Security teams should govern IDE extensions like privileged software inside a trusted execution environment. Approve only the capabilities an extension actually needs, block unrestricted shell and network access by default, and review updates as if they were entitlement changes. The most important control is to tie approval to observed behaviour, not to the marketplace listing alone.

Q: Why do AI-powered IDE extensions increase developer credential risk?

A: They increase credential risk because they can read local caches, environment variables, and workspace files while operating under the developer's authority. If an extension stores tokens or API keys, those secrets become reachable through the plugin path rather than only through the host system. That makes secret handling, not just malware scanning, a core control issue.

Q: What breaks when IDE extensions are allowed broad workspace and shell permissions?

A: Broad permissions break least privilege at the point where code, secrets, and execution meet. A compromised or malicious extension can edit files, run commands, alter Git history, and exfiltrate credentials without needing a separate OS exploit. In practice, broad permissions turn routine developer tooling into a high-blast-radius access path.

Q: How do teams know if IDE extension controls are actually working?

A: Controls are working only if you can detect capability changes, unexpected shell invocations, abnormal file writes, and network calls from extensions before damage spreads. If those signals are not visible in logs or alerts, then policy exists on paper but not in practice. The right test is whether a compromised plugin would be caught before it can modify code or leak secrets.

Technical breakdown

Why IDE extensions become a trusted execution surface

Modern IDE extensions inherit the developer's authority and often operate with access to source code, local files, environment variables, and repo workflows. When extensions also include AI assistants or MCP connectors, they can trigger commands, modify files, and interact with external systems from inside the workspace. That moves the security problem from the browser-like plugin model into a live execution environment. The technical risk is not only malicious code, but also over-broad capability design that gives ordinary utility plugins access they do not need.

Practical implication: treat the IDE as an execution tier that needs explicit policy, not as a low-risk user interface.

How prompt injection and MCP connector abuse change the threat model

AI-enabled extensions parse prompts, repository content, and connector responses, which means attacker-controlled text can steer agent behaviour without exploiting the operating system. Prompt injection works by shaping instructions the model treats as legitimate context, while MCP connector abuse extends that influence into tools and data sources. In this model, a poisoned response can cause file edits, history rewrites, or secret exfiltration even when the underlying IDE and endpoint are otherwise healthy. The security boundary is therefore the data-to-action path, not just the host machine.

Practical implication: validate external inputs, constrain tool scope, and inspect connector provenance before any write action occurs.

Why permissioning and sandboxing matter more than marketplace trust

Marketplace verification alone does not remove the risk of over-permissioned or silently updated extensions. Many plugins request broad workspace, shell, or network access even when their functional need is narrow, and auto-updates can expand those permissions without a fresh human review. Sandbox controls reduce the blast radius by separating risky extension behaviour from the main editor session, while policy enforcement pins what each extension can touch. This is the same least-privilege principle used in IAM, but applied to developer tooling and AI execution paths.

Practical implication: require capability-scoped approval, isolate high-risk plugins, and re-review permissions whenever an extension changes.

Threat narrative

Attacker objective: The attacker aims to turn the developer workspace into a trusted launch point for credential theft, code tampering, and downstream compromise.

1. Entry occurs when an attacker lands a malicious extension, hijacks a publisher account, or abuses an auto-update channel to place hostile logic into the IDE.
2. Escalation follows when the extension inherits workspace trust, reads secrets or environment variables, and uses shell or network permissions to operate beyond its original purpose.
3. Impact comes when the compromised extension rewrites code, alters Git history, exfiltrates credentials, or pushes destructive commands through AI-assisted workflows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IDE extension security is now an identity problem, not just an application security problem. Extensions and AI assistants inherit developer authority, and that authority often includes code access, secrets, and the ability to execute commands. Once those capabilities exist inside the workspace, governance has to cover entitlement scope, update trust, and runtime behaviour, not only software provenance. Practitioners should treat the IDE as a governed control plane for developer identity.

Secret handling inside extensions creates a hidden NHI trust boundary. The article correctly highlights that plugins can cache tokens, API keys, and session material locally. That is an NHI issue because the extension often acts as an unreviewed intermediary for machine credentials, and those credentials can outlive the user session that created them. Practitioners should assume plugin caches are part of the credential surface until proven otherwise.

Real-time policy enforcement inside the workspace is a named control gap in traditional endpoint coverage. Endpoint tools can see processes and network traffic, but not the intent and context of IDE-native actions well enough to govern them. The missing concept here is workspace execution visibility: the ability to see whether an extension is making safe, expected actions before those actions modify code or disclose secrets. Practitioners should map that visibility gap explicitly in their control design.

Auto-update trust is a lifecycle failure mode for developer tooling. The article shows that updates can ship new behaviour into trusted environments without a fresh approval decision. That is a governance lifecycle problem because the installed state no longer matches the reviewed state. Practitioners should re-evaluate how often approved extensions are re-certified after publisher, permission, or release changes.

AI-assisted development collapses the distance between tool use and data exfiltration. When an extension can read context, call tools, and write back into repositories, the distinction between code assistance and action execution becomes thin. That raises the value of policy-based guardrails around shell access, connector provenance, and monitored writes. Practitioners should align IDE governance with NHI and agentic access models rather than classic desktop software assumptions.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• A separate finding from the same research shows that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone.
• For a broader view of how these trust failures connect to breach patterns, see The 52 NHI breaches Report.

What this signals

Workspace execution visibility is becoming a practical control category for teams running AI-assisted development. If you cannot observe what an extension is allowed to do, what it actually does, and when an update changes that behaviour, then your governance model is still anchored outside the place where risk is emerging.

The most important programme change is to link developer tooling approval to identity governance, secrets handling, and runtime monitoring in one review path. That means extension permissions, publisher trust, and secret storage all need the same governance discipline that IAM teams already apply to privileged non-human access.

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, the problem is no longer isolated to a few unsafe plugins; it is structural. Teams should assume that AI-augmented developer workflows will keep expanding the trust boundary until policy, sandboxing, and telemetry are enforced together.

For practitioners

• Classify every IDE extension by capability, not by category Map each plugin to the exact rights it needs, including shell, network, file-system, and repo-write access. Deny broad defaults and require explicit justification when an update expands permissions beyond the original approval.
• Isolate AI-assisted extensions from the main editor session Run high-risk extensions and MCP connectors in constrained sandboxes with limited file access and tightly scoped outbound traffic. Keep task-specific state ephemeral so one plugin cannot influence unrelated projects or sessions.
• Treat extension updates as security events Log installs, version changes, publisher changes, and manifest changes in the same monitoring pipeline you use for other privileged software. Revoke or quarantine extensions automatically when a release adds shell execution, broad workspace access, or suspicious network behaviour.
• Build a fast revoke path for compromised developer tooling Prepare a process to remove a malicious extension across workspaces, rotate any credentials it may have touched, and inspect Git history for unauthorised edits. The goal is containment before the compromised plugin completes its next execution cycle.

Key takeaways

• IDE extensions have evolved into a governed execution surface where code, secrets, and AI actions intersect.
• The risk is measurable: over-permissioned plugins, hard-coded credentials, and update channels create a durable exposure path.
• Security teams need workspace-level visibility, least-privilege approval, and fast revocation to keep developer tooling from becoming an attack platform.

Key terms

• IDE Extension Security: IDE extension security is the practice of governing add-ons that run inside developer environments and can influence code, files, tools, and secrets. It combines permission control, provenance checks, runtime monitoring, and update review so productivity features do not become privileged execution paths.
• Workspace Execution Surface: A workspace execution surface is the part of the developer environment where extensions, assistants, and connectors can take action, not just display information. In practice, it is where file access, shell execution, API calls, and secret exposure converge and therefore needs its own policy and monitoring model.
• MCP Connector: An MCP connector is a tool integration that lets an AI system or extension reach data sources and external actions through Model Context Protocol. In IDEs, connectors can extend agent capability quickly, but they also widen the trust boundary because tool responses can influence code and workflow decisions.
• Workspace Execution Visibility: Workspace execution visibility is the ability to observe what an IDE extension or AI assistant is allowed to do, what it actually does, and when that behaviour changes. It is the missing layer between endpoint telemetry and code governance when trusted developer tools become action-capable.

What's in the full article

Knostic's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for validating extensions, including publisher checks, manifest review, and baseline comparison before install.
• Practical examples of sandboxing risky plugins and monitoring IDE behaviour without relying only on endpoint telemetry.
• A five-layer defence framework for validation, permission control, sandboxing, monitoring, and incident response.
• Knostic's runtime policy and visibility approach for IDE-native extension and MCP risk.

👉 The full Knostic post covers the attack scenarios, defence layers, and workspace monitoring details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, PAM, or NHI programme, it is worth exploring.