Runtime trust layer for enterprise VS Code fleets that blocks malicious extensions and auto-rotates exposed CI and cloud secrets.

1. Verified marketplace status no longer reassures buyers because Nx Console's badge and 2.2 million installs did not stop a malicious update from compromising GitHub.
2. An 18-minute exposure window was enough to infect thousands of developers and exfiltrate 3,800 internal repositories, so point-in-time extension audits are not enough.
3. The extension harvested cloud, vault, GitHub, Kubernetes, Docker, and password-manager secrets from the workstation, making IDE compromise equivalent to machine-identity compromise.
4. The same campaign also pushed malicious workflow YAML into 5,500+ repositories, creating urgency for products that connect laptop compromise to downstream CI containment.

Catalyst. The TeamPCP incident proved that a verified VS Code extension can breach GitHub itself in under 18 minutes and steal both workstation and CI credentials, turning IDE runtime trust into an urgent board-level control gap.

IDE Extension Trust Firewall plugs into the enterprise extension baseline, endpoint agent, and secret systems already used by engineering. It scores every installed extension against observed behaviors such as credential-file access, shell execution, workspace-open callbacks, outbound network patterns, and unauthorized mutation of workflow or config files. When it detects a high-risk extension, it can isolate that workstation, revoke or rotate the specific GitHub, cloud, and vault credentials in reach, and generate a blast-radius report showing which repos, workflows, and environments may have been touched. The first release is deliberately narrow: protect managed VS Code fleets without forcing security teams to ban extensions outright or run a full laptop-forensics program after every scare.

What's different. Most developer-security tools stop at package provenance, secret detection, or generic endpoint telemetry. This company would own the missing runtime layer where approved IDE extensions actually execute, touch secrets, and alter repository state before code reaches CI. Its moat can compound through an extension-behavior graph tied to enterprise-specific credential inventories, repo topologies, and incident-response playbooks that get sharper with every containment event.

Jobs to be done

flowchart LR
  Buyer[Platform security lead] --> Pain[Trusted IDE extensions can exfiltrate secrets]
  Pain --> Product[IDE extension trust firewall]
  Product --> Outcome[Safe developer workflows with instant credential containment]

Executive takeaways

• Verified publisher badges and marketplace scanning reduce risk but do not remove it: extensions run with VS Code-level permissions, and a short-lived poisoned Nx Console release still led to GitHub repository exfiltration.
• Target buyers already have allowlists, secret scanning, and GitHub Actions hardening, but they lack a product that links extension runtime behavior to immediate credential quarantine and repo-blast-radius analysis.
• The market is pulled by structural sprawl in non-human credentials: a compromised developer workstation can bridge into cloud, vault, password-manager, and CI identities before code review sees anything.
• Competition is intense in adjacent categories, but the exact gap remains extension-specific runtime containment rather than dependency scanning or downstream CI hardening alone.

Market definition

This market sits at the intersection of developer workstation security, software supply chain security, and machine identity governance. The near-term wedge is monitoring and containing risky IDE extension behavior inside managed VS Code or Cursor fleets before that behavior spills into repositories, CI, and cloud credentials.

Customer and buyer

Primary users are platform security and developer-platform engineers at software companies with 300-1,500 engineers, standardized VS Code or Cursor environments, and GitHub Actions delivery. Economic buyers are directors or VPs of platform engineering, heads of product security, and CISOs who already own developer tooling policy and incident response.

Buying triggers

• A concrete extension incident or executive review of approved-tooling trust turns marketplace verification from a comfort signal into a board-level control gap. [21][23][36]
• Workflow compromise stories like Megalodon make platform teams care about how a single developer-side foothold can spill into CI, cloud, and repo secrets. [10][16]
• Machine-identity sprawl raises the cost of manual response because compromised workstations can expose many more non-human credentials than a security team can quickly enumerate by hand. [9][7][2]
• AI coding and agent rollouts increase willingness to buy extra guardrails because local tools are now expected to read repos, run commands, and touch secrets more autonomously. [14][5]

Willingness to pay

Comparable AppSec and supply-chain vendors already sell priced seats or enterprise plans, which supports budget for a narrower extension-runtime control if it clearly reduces incident-response time and credential rotation scope. [27][30][6]

Category dynamics

Growth signal 25% year-over-year increase in leaked credentials in public GitHub repositories

Validation signals

• Microsoft added organization-level allowed extensions and version controls in VS Code 1.96, showing enterprise buyers are already asking for central extension governance.
• Microsoft reported reviewing 136 extensions and removing 110 for malicious code in 2025, demonstrating that extension marketplace abuse is active enough to generate meaningful remediation volume.
• Wiz found 550 validated secrets across 500+ extensions, including over 100 leaked VS Code Marketplace PATs, proving the extension update channel itself can become an attack vector.
• StepSecurity documented 5,500+ repositories hit by malicious workflow injection in a six-hour window, reinforcing the downstream value of connecting endpoint detections to CI containment.

Regulatory & technical constraints

• VS Code extensions inherit VS Code-level permissions, so any credible control must observe activity locally and in real time rather than rely on repo scanning alone.
• Enterprise extension allowlists and version pinning already exist, so a new product must complement those controls instead of forcing customers to replace them.
• GitHub Actions and cloud auth patterns use short-lived and workflow-minted identities, so containment has to cover more than long-lived static secrets.
• Developer workstations commonly expose credentials through environment variables, config files, kubeconfig, service accounts, and local secret tooling, which expands the blast radius an extension can reach.

Endor is the closest strategic rival because it now frames AI coding agents and workstations as a new control plane. Aikido is the closest endpoint-style substitute with on-device blocking and minimum-age controls. Socket, Snyk, and GitHub own dependency and repo-native budgets, while StepSecurity is strongest on downstream GitHub Actions hardening rather than the IDE foothold.

Why incumbents do not win by default

• Microsoft and GitHub native controls. Microsoft and GitHub already offer publisher trust, allowlists, secret scanning, and workflow hardening, but they do not inspect extension behavior at runtime or automatically quarantine the specific credentials a rogue extension touched.
• Repo and dependency security platforms. GitHub Advanced Security, Socket, and Snyk own repo-native and package-intelligence workflows, but they focus on dependencies, pull requests, and pushed code more than extension process behavior on developer machines.
• Agent governance and workstation security vendors. Endor and Aikido validate demand for workstation and agent controls, but their current framing is broader than extension-specific quarantine and repo-impact mapping, leaving room for a sharper beachhead product.
• CI hardening specialists. StepSecurity is strongest once malicious workflow code reaches GitHub Actions, but it does not stop the initial extension-borne credential theft on the developer workstation.

TeamPCP's poisoned Nx Console release showed that a verified VS Code extension can bridge from a developer laptop into repository theft and CI credential exposure in minutes, which creates a concrete control gap for software companies that standardize on VS Code or Cursor and GitHub Actions. The company should start with Series B-D software businesses that already manage extension policy for 300-1,500 engineers, because those buyers feel the pain acutely and can deploy one managed-fleet pilot without re-architecting their whole security stack. The product wedge is an audit-first extension trust firewall that observes runtime behaviors on workspace open, flags anomalous secret access or workflow mutation, and maps the likely blast radius across GitHub, cloud, vault, and password-manager identities. The first proof point is not broad prevention; it is cutting alert-to-containment time and reducing how many credentials and repositories have to be rotated after a suspicious extension event. The most important strategic choice is to stay narrowly focused on managed VS Code fleets and downstream credential containment before expanding into JetBrains, browser IDEs, or generalized AI agent governance. Research supports the urgency, the buyer profile, and the adjacent budget, but it does not yet prove how many target accounts centrally manage extension baselines tightly enough for fast rollout. The main disconfirming risk is that Microsoft, GitHub, or broader workstation-security vendors close the gap before the startup earns a behavioral data moat and trusted response workflows. This is investable as a pre-seed design-partner company if early pilots show low false-positive rates, credible integrations with AWS, GitHub, 1Password, and Vault, and at least one paid conversion triggered by an incident review or audit deadline.

Problem

• Platform-security teams already use allowlists, secret scanning, and EDR, but those controls do not tell them what an approved IDE extension actually did at runtime before code reached review or CI.
• When a workstation-side developer-tool compromise happens, responders often rotate too many credentials too slowly because they cannot quickly determine which repos, workflows, and machine identities the extension touched.

Solution

• Deploy an audit-first trust firewall for managed VS Code fleets that profiles extension behavior at activation and workspace open, including secret-file access, shell execution, file mutation, and outbound network activity.
• Pair detections with a credential and repository blast-radius graph plus scoped quarantine workflows for GitHub, AWS, Vault, Kubernetes, and 1Password so customers can contain only the assets likely exposed.

Why we win

• The wedge is narrower than broad AppSec or endpoint security, so the product can reach proof faster by solving one urgent workflow where native controls are visibly incomplete.
• A compounding moat can form from proprietary baselines of legitimate extension behavior and from incident data linking endpoint events to real credentials, repositories, and response playbooks.

Milestones

flowchart LR
  Wedge[Managed VS Code fleet pilot] --> MVP[Runtime profiling and blast-radius graph]
  MVP --> Proof[Faster scoped containment with low false positives]
  Proof --> Expansion[More business units then adjacent editors and AI tools]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least half of interviewed target accounts already manage extension policies centrally enough to support a one-fleet pilot.
• Buyers value scoped credential quarantine enough to pay beyond existing GitHub, AppSec, and EDR tooling.
• Audit-mode detection can stay below the false-positive threshold that would cause developers to demand blanket allowlisting instead.
• GitHub plus AWS, Vault, and 1Password integrations cover the majority of exposed secrets in the first beachhead accounts.
• Microsoft and adjacent vendors do not ship equivalent runtime containment fast enough to commoditize the wedge in the next 18 months.

Open diligence questions

• How many target accounts can export current extension policy and version data on day one of a pilot?
• Which buyer actually signs the first contract when platform security, endpoint engineering, and AppSec all touch the problem?
• What incident-response time savings matter enough for a customer to convert from pilot to production?
• Which secret stores and CI identities are mandatory in the first release versus nice to have?
• How differentiated is the product if Microsoft improves attestation and admin defaults but not containment workflows?

Model sanity

• Revenue engine. Base-case revenue comes from converting three paid pilots into a modest enterprise logo base and then lifting ACV from roughly $144K to $200K through seat expansion and quarantine workflows.
• Must go right. The company must keep pilot-to-production conversion near the modeled 90-day path while proving low false positives on one managed fleet.
• Model breaks if. If fewer target accounts can centrally manage extension policy than the business plan assumes, both deployment speed and Q4Y3 customer count fall toward the downside case.
• Next-round proof. Reaching 8 paying accounts by Q4Y2 with at least 2 production conversions and credible GitHub-plus-secrets containment should justify the next financing.

Scenarios

Sensitivity

flowchart LR
  Leads --> PaidPilots
  PaidPilots --> ProductionAccounts
  ProductionAccounts --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

Flags: The base case still depends on landing 3 paid pilots by month 10 and then converting enterprise buyers without discounting below the planned minimum platform fee. · The source material does not prove how many 300-1,500 engineer targets can centrally manage extension baselines today, so deployment readiness is the main forecast risk. · Q4Y3 assumes 32 customers before broad editor expansion, so bundling by Microsoft, GitHub, Endor, or Aikido could compress both ACV and logo growth faster than the model allows.

• Native platform catch-up. Microsoft, GitHub, or large endpoint vendors could add stronger extension attestation and policy controls that shrink the category. Mitigation: Focus on cross-tool runtime behavior, credential blast-radius mapping, and automated containment workflows that go beyond marketplace attestation.
• Endpoint deployment friction. Security teams may resist another workstation agent if installation or false positives disrupt developer workflows. Mitigation: Start with managed-fleet telemetry and monitor mode, then phase in enforcement only for high-confidence secret-access and file-mutation patterns.
• Budget ambiguity. Buyers may split ownership across endpoint, AppSec, and platform engineering teams, slowing initial sales cycles. Mitigation: Sell through a concrete incident-response ROI story around reduced rotation time and avoided repo or CI shutdowns, then package integrations that satisfy each team.