TL;DR: Malicious and hijacked extensions remain publicly available on OpenVSX even after exposure, while dormant projects and low-reputation publishers can be repurposed as malware distribution paths, according to Knostic. The finding shows that extension marketplaces need runtime trust controls, not just review and takedown workflows, as AI coding assistants increasingly consume them.

NHIMG editorial — based on content published by Knostic: compromised OpenVSX extensions remain active after exposure

Questions worth separating out

Q: What breaks when malicious extensions remain available after exposure?

A: When compromised extensions remain available, security teams lose the assumption that discovery equals containment.

Q: Why do AI coding assistants increase extension marketplace risk?

A: AI coding assistants increase risk because they often operate inside high-trust developer environments and can interact with the same packages, files, and credentials as the human user.

Q: How do security teams know if extension governance is actually working?

A: Measure whether unapproved extensions can be installed, whether dormant packages are being reviewed after sudden updates, and whether malicious listings can be blocked before execution.

Practitioner guidance

• Verify publisher lineage before approving extensions Require documented publisher identity, account history, and package provenance before allowing extensions into developer-approved catalogs, especially where dormant projects have resumed activity.
• Restrict AI coding assistants to approved extension sources Limit what assistants can install, recommend, or execute so they cannot freely pull from public marketplaces without policy checks and workspace controls.
• Add install-time inspection and blocking Inspect extension metadata, signatures, and behaviour at the moment of installation so suspicious packages can be stopped before they execute in the developer environment.

What's in the full article

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

• Step-by-step examples of malicious and hijacked OpenVSX listings that remained live after exposure
• The screenshots and publisher warnings used to distinguish dormant projects from freshly weaponised packages
• How Kirin detects an infected extension at install time and alerts the user before spread
• Operational guidance on stopping risky extensions from reaching developers and AI coding assistants

👉 Read Knostic's analysis of malicious OpenVSX extensions and AI coding risk →

OpenVSX extension abuse: what it means for AI coding security?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Invisible zero-width and bidirectional Unicode characters can hide logic, alter execution flow, and poison AI coding workflows, with real campaigns affecting IDEs, extensions, and rules files used by GitHub Copilot and Cursor. The control problem is no longer just code review; teams need scanning, review, and governance for AI configuration files and developer tooling.

NHIMG editorial — based on content published by Knostic: Invisible Unicode in AI coding agents is a supply-chain risk

Questions worth separating out

Q: What breaks when invisible Unicode characters are not checked in code and AI rules files?

A: Reviewers can approve code that does not match what the compiler or AI agent actually consumes.

Q: Why do AI coding agents make hidden-character attacks more dangerous?

A: AI coding agents can repeatedly apply poisoned instructions from rules files, templates, or shared config, so one hidden payload can influence many future outputs.

Q: How can security teams detect invisible Unicode abuse in development workflows?

A: Run Unicode scanning in pre-commit and CI, render non-printing characters during review, and block files that contain bidirectional overrides or unexpected control ranges.

Practitioner guidance

• Scan for control-character abuse in CI Add Unicode linting to pre-commit hooks and build pipelines, and reject files containing bidirectional overrides or unexpected zero-width ranges.
• Put AI rules files under change control Treat .cursorrules, .mdc, and related agent instructions as executable policy objects.
• Harden developer-tool provenance Allowlist IDE extensions, verify publishers, and remove unused add-ons from developer workstations.

What's in the full article

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

• A concrete walkthrough of the hidden Unicode patterns that evade human review and simple syntax highlighting.
• Step-by-step detection examples for command-line and CI-based scanning of control and zero-width character ranges.
• Operational guidance for hardening IDE extensions, AI rules files, and development templates before they influence code generation.
• A closer look at the Kirin detection example showing how hidden payloads are identified at install time.

👉 Read Knostic's analysis of invisible Unicode attacks in AI coding workflows →

Invisible Unicode in AI coding agents: what teams need to act on?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: AI coding assistants are now used or planned by 84% of developers, while 46% say they do not trust AI-generated results, according to Stack Overflow and ITPro coverage cited by Knostic. Governance is no longer optional because traceability, policy enforcement, and data controls determine whether speed turns into audit failure, leakage, or insecure code.

NHIMG editorial — based on content published by Knostic: Fast Facts on AI Coding Assistant Governance AI coding assistants accelerate development, but without governance, their outputs can bypass security, compliance, and regulatory frameworks

By the numbers:

• 84% of developers use or plan to use AI tools in their development workflows.
• 46% of developers say they do not trust the accuracy of AI-generated results, up from about 31% in 2024.
• 58% of employees admitted they had pasted sensitive data into LLMs, even when their companies had not clearly defined what was allowed.

Questions worth separating out

Q: How should security teams govern AI coding assistants in development workflows?

A: Security teams should govern AI coding assistants by combining approved use cases, model allowlists, prompt filtering, and traceable logging.

Q: Why do AI coding assistants create compliance and audit risk?

A: They create compliance and audit risk because they can generate code and process inputs outside traditional review paths.

Q: What do teams get wrong about monitoring AI-generated code?

A: Teams often focus on the code itself and forget the provenance trail around it.

Practitioner guidance

• Define allowed AI coding use cases Restrict assistants to low-risk tasks such as boilerplate, documentation, and test scaffolding, and explicitly prohibit use in cryptography, authentication flows, or credential handling.
• Enforce model allowlists and prompt controls Approve specific providers centrally, then block or mask prompts that contain secrets, regulated data, or repository content outside policy.
• Tag and trace AI-assisted changes Record when a suggestion was generated, whether it was accepted or modified, and which pull request or commit introduced it.

What's in the full article

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

• Specific policy examples for allowing or blocking AI assistant use in code review and repository workflows.
• Workflow guidance for logging AI-assisted suggestions, edits, and approvals at pull request level.
• Implementation detail on prompt filtering, model whitelisting, and guardrail enforcement in developer environments.
• Practical examples of how governance can be embedded into CI/CD without adding excessive manual review.

👉 Read Knostic's analysis of AI coding assistant governance and DevSecOps controls →

AI coding assistant governance: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: AI-assisted software development is accelerating vulnerability discovery, expanding the attack surface in IDEs and toolchains, and creating governance pressure around dependency use, generated code, and autonomous tool actions, according to Knostic's webinar with CTO Sounil Yu. The critical issue is no longer just what code ships, but whether security teams can constrain agent behaviour, verify outcomes, and recover when non-deterministic workflows go wrong.

NHIMG editorial — based on content published by Knostic: What security leaders need to know from our recent webinar with Knostic CTO Sounil Yu

Questions worth separating out

Q: How should security teams govern coding assistants that can take actions inside the IDE?

A: Treat coding assistants as privileged systems with bounded capabilities, not as neutral productivity tools.

Q: Why do coding assistants create new identity and access risks?

A: Because they operate inside a high-trust environment and can inherit access to files, secrets, tools, and services.

Q: What breaks when teams rely on SBOMs and SCA alone for generated code?

A: They can create false confidence if the code is bespoke but still risky.

Practitioner guidance

• Instrument the IDE as a security endpoint Log assistant actions, file context, tool calls, and destructive commands from the IDE so you can detect unsafe behaviour before code is committed.
• Gate all-three agent states Block or require approval when an assistant has untrusted inputs, access to sensitive data, and external communication in the same workflow.
• Curate MCP servers and extensions Maintain allow-lists for approved extensions and MCP endpoints, then review exceptions like privileged access requests.

What's in the full article

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

• The live walkthrough of the Agent’s Rule of Two and how to operationalise it in developer environments.
• The OODA lens for distinguishing tools, AI agents, and agentic AI in practical workflows.
• The Kirin approach to instrumenting IDE actions, MCP calls, and extension behaviour.
• The specific examples of dangerous actions, prompt injection paths, and control points discussed in the session.

👉 Read Knostic's webinar analysis of agentic development security and AI-assisted vulnerability discovery →

Coding assistants, MCP, and the governance gap teams are missing?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: IDE secrets management is exposed as a hidden control gap because AI tools, extensions, MCP servers, and clipboard workflows can ingest, retain, and leak credentials from development environments, according to Knostic. The practical lesson is that plaintext storage, broad context access, and weak drift monitoring create a much larger secrets risk than most teams assume.

NHIMG editorial — based on content published by Knostic: Key Findings on IDE Secrets Management

By the numbers:

• Stolen or misused credentials were the leading initial access vector, accounting for 30% of all incidents.
• 95% of surveyed organizations had experienced a cloud-related breach in the previous 18 months, and 99% of those cited insecure identities as the primary cause.

Questions worth separating out

Q: What fails when IDE secrets are stored in plaintext or unprotected buffers?

A: Plaintext storage turns a temporary developer convenience into persistent credential exposure.

Q: Why do AI assistants and IDE extensions create extra risk for secrets management?

A: They expand the number of components that can read context, store output, or relay diagnostic data.

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

A: Look for the absence of secrets in local caches, extension storage, clipboard history, and AI assistant logs, not just clean repository scans.

Practitioner guidance

• Constrain IDE context access by default Disable broad workspace scanning, automatic environment-variable ingestion, and full-project context sharing in AI assistants unless a specific use case requires it.
• Move secrets out of plaintext developer storage Require encrypted OS-backed storage such as Keychain, DPAPI, or GNOME Keyring for any local credential material, and block .env or token files from unprotected project directories.
• Standardise IDE baselines across the fleet Package approved settings for IDEs, clipboard behaviour, autosave, and extension installation into workspace templates so developer machines do not drift into insecure defaults.

What's in the full article

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

• How specific IDE components, extensions, and AI assistants store or relay secrets in real workflows.
• The security framework for storage policies, access scope policies, token lifespan policies, and exposure prevention policies.
• Practical controls for configuration baselines, local storage hygiene, and monitoring for drift or misuse.
• Examples of where diagnostic output, clipboard behaviour, and autosave settings create silent leak paths.

👉 Read Knostic's analysis of IDE secrets management and hidden developer exposure paths →

IDE secrets management: are your developer controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: AI coding agents are moving beyond developer workflows into broader knowledge work, with MCP servers, IDE extensions, and skill configurations creating new exposure points for command execution, data access, and supply chain dependence, according to Knostic. The governance gap is now less about whether these tools are useful and more about whether organisations can discover, monitor, and contain them before they touch production systems.

NHIMG editorial — based on content published by Knostic: Open Source Tools for Security Teams and the OpenClaw agent control gap

Questions worth separating out

Q: How should security teams govern AI coding agents that can access tools and services?

A: Security teams should treat AI coding agents as governed software entities with explicit tool permissions, lifecycle logging, and named ownership.

Q: What breaks when AI agents are deployed without discovery controls?

A: Without discovery controls, organisations cannot tell whether an agent is approved, duplicated, or hiding in an unmanaged endpoint path.

Q: How do security teams know whether agent telemetry is actually working?

A: Telemetry is working when it captures tool calls, lifecycle events, and message traces in a way that supports investigation and correlation.

Practitioner guidance

• Inventory all agent entry points Scan managed devices and build environments for CLI binaries, app bundles, gateway services, config files, and container artifacts associated with coding agents and their extensions.
• Govern MCP and extension permissions Review every MCP server definition, IDE extension, rule file, and skill configuration as a policy object with explicit approval, scope, and ownership.
• Require behavioural telemetry for agents Collect tool-call logs, message events, and lifecycle traces with sensitive-data redaction and tamper-resistant storage so security teams can investigate agent actions later.

What's in the full article

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

• OpenClaw-specific detection logic for managed devices, including binaries, bundles, gateway services, and Docker artifacts.
• Telemetry design details for tool calls, lifecycle events, message events, and redaction in JSONL output.
• Implementation notes for forwarding logs into SIEM workflows and existing response playbooks.
• Deployment guidance for MDM platforms such as Intune, Jamf, JumpCloud, Kandji, and Workspace ONE.

👉 Read Knostic's analysis of OpenClaw detection and telemetry for AI coding agents →

AI coding agents and MCP security: what practitioners need now?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: AI-driven vulnerability discovery is compressing the window between discovery and weaponization to hours, while security programmes built on weekly patch cycles and quarterly testing were not designed for that pace, according to the Cloud Security Alliance briefing published by Knostic. Minimum viable resilience, automated assessment, and faster governance become the practical response, not optional hardening.

NHIMG editorial — based on content published by Knostic: "The AI Vulnerability Storm" briefing on building a Mythos-ready security program

Questions worth separating out

Q: What breaks when vulnerability discovery is faster than patch cycles?

A: Patch-centric programmes break because they assume security teams have days or weeks to assess, approve, and deploy fixes.

Q: Why do AI-driven exploits matter for identity and access governance?

A: Because once a flaw is weaponised, the next step is often credential use, privilege escalation, or service account abuse.

Q: How do security teams know whether their vulnerability programme is keeping up?

A: Look for measurable reductions in time from disclosure to validated remediation, fewer exceptions on internet-facing assets, and faster containment when active exploitation appears.

Practitioner guidance

• Rebuild patch prioritisation around exploitability windows Classify vulnerabilities by time to likely weaponization, not only severity score.
• Harden the basic controls that slow AI-assisted attackers Strengthen segmentation, egress filtering, and multifactor authentication on all systems that can reach sensitive data or administrative interfaces.
• Build a continuous VulnOps workflow Treat vulnerability intake, exception approval, remediation, and verification as one governed process with named owners and auditability.

What's in the full report

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

• Prioritised action plan with start dates and time horizons for a Mythos-ready security programme
• Board-facing language for explaining shorter adversary timelines and remediation pressure
• Operational recommendations on automated security assessments and LLM-powered vulnerability finding
• Governance changes needed for faster vendor onboarding and AI-based defence deployment

👉 Read Knostic's analysis of the AI vulnerability storm and Mythos-ready security →

AI vulnerability discovery is outpacing patch cycles: are controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Malicious VS Code and Cursor extensions can steal OAuth refresh tokens, exfiltrate environment variables, and run attacker-controlled code, turning developer tooling into a cloud access and secret-harvesting channel, according to Knostic's threat intelligence report. The pattern reinforces that IDE extensions now need the same governance attention as other software supply chain and identity-bearing endpoints.

NHIMG editorial — based on content published by Knostic: LLMjacking and malicious agentic supply chain findings in IDE extensions

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

Questions worth separating out

Q: What breaks when a malicious IDE extension can read cloud credentials and environment variables?

A: The main failure is that the editor stops being a neutral tool and becomes a credential collection point.

Q: Why do IDE extensions complicate IAM and NHI governance?

A: They complicate governance because they behave like runtime identities with delegated authority, but they are rarely managed like service accounts or applications.

Q: How can security teams tell if a developer extension is behaving like malware?

A: Look for auto-activation, frequent polling to unfamiliar endpoints, browser automation, unexpected token reuse, and attempts to read broad environment state.

Practitioner guidance

• Inventory IDE extensions as identity-bearing software Classify editor extensions by the data and credentials they can touch, then require approval for any extension that can read environment variables, request OAuth scopes, or auto-activate on startup.
• Block broad OAuth grants from developer tooling Restrict cloud and AI OAuth flows used by local developer tools to the minimum scopes required, and revoke refresh tokens immediately when extensions change behaviour.
• Detect extension-driven secret exposure at the endpoint Monitor for outbound polling, suspicious browser automation, unexpected use of eval, and large reads of process.env or equivalent environment state.

What's in the full article

Knostic's full threat-intelligence report covers the operational detail this post intentionally leaves for the source:

• IOC-level indicators for the BCAI Rosetta extension, including package identifiers, hashes, and affected marketplace metadata
• Static validation details showing how the refresh-token theft, OAuth scope abuse, and proxying behaviour were confirmed from the VSIX
• Per-finding breakdowns for the KoltinSmith cluster, sunsetHighlight, and Musa-DSL, including which cases were malicious versus dangerous by design
• Network fingerprints, callback ports, and attacker domains that help defenders build detection and hunting rules

👉 Read Knostic's analysis of malicious IDE extensions hijacking cloud credentials →

AI IDE extensions and secret theft: what security teams should do?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: CrowdStrike says Glassworm has targeted software developers since at least early 2025, using trojanized VS Code extensions, compromised npm and Python packages, and poisoned GitHub repositories to seed a botnet that can steal credentials and push supply-chain compromise downstream. The takedown buys time, but it also shows that developer workstations have become a primary supply-chain attack surface, not just production build pipelines.

NHIMG editorial — based on content published by Knostic covering CrowdStrike's Glassworm takedown: Disrupting Glassworm and the developer-targeting botnet threat

Questions worth separating out

Q: What breaks when malicious code can run inside a developer IDE or package install?

A: Traditional endpoint and supply-chain controls lose time to the same mechanism they are trying to inspect.

Q: Why do developer workstations increase supply-chain risk so quickly?

A: Developer workstations concentrate source code, cloud credentials, CI/CD secrets, SSH keys, and repository permissions in one place.

Q: How should security teams govern IDE extensions and MCP servers?

A: Treat them as executable trust relationships, not convenience features.

Practitioner guidance

• Inventory every developer execution surface Build a live list of IDE extensions, package managers, MCP servers, and assistant-connected tools across engineering endpoints.
• Block install-time code execution by policy Restrict extension activation, postinstall hooks, and setup scripts unless the source is approved and the behavior is explicitly expected.
• Harden developer identity material on endpoints Separate cloud credentials, SSH keys, and password-manager access from everyday editor processes, and enforce scoped access for repository write operations.

What's in the full article

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

• The full attacker tradecraft behind Glassworm's extension, package, and repository infection paths.
• The specific command-and-control infrastructure CrowdStrike disrupted across blockchain, peer-to-peer, and web services.
• The published YARA rules and hunting indicators for the RAT and downloader stages.
• The remediation actions for engineering fleets that matched the 164.92.88210 beacon.

👉 Read Knostic's analysis of Glassworm and developer-targeting botnet risk →

Glassworm and developer IDE risk: what security teams need to do now?

Explore further

View Full Forum →  |  NHI Foundation Course →