Weekly Security Roundup: Supply Chain, Identity, and Agent Controls

by TechHub

Welcome to this week's Security roundup, where supply chain attacks kept pushing left into developer tools, dependencies, and CI defaults, including a poisoned VS Code extension incident and large-scale malicious npm package infections. Incident reporting also reinforced how quickly attackers can chain identity compromise, edge appliance exposure, and trusted tooling into broad access across on-prem and cloud control planes. On the defense side, the theme was making security more enforceable and testable: new npm release controls, tighter GitHub Actions guidance, practical KQL hunting playbooks, and concrete frameworks for agent security governance and red-teaming. We close with operational updates that reduce patching and change-management friction, plus developer-facing improvements that make audits and unsafe-code boundaries easier to reason about.

This Week's Overview

Supply chain attacks keep shifting left (npm, extensions, and CI)

Building on last week's focus on supply chain and runtime hardening (and the idea that “foundation work” like safer artifact paths can prevent real incidents), this week had multiple reminders that the easiest path into an organization is often through developer tooling and dependency pipelines, not a front-door exploit. Incidents ranged from poisoned editor extensions to malicious npm packages that execute during install, with follow-on access that can include repo exfiltration, credential theft, and CI runner compromise.

A key pattern across these writeups is “trusted execution by default”: install scripts, GitHub Actions workflows, and editor extensions run with more access than most teams realize. Practical mitigations keep repeating too - rotate secrets fast, restrict what PRs can execute in CI (especially when using pull_request_target), pin GitHub Actions by commit SHA, and reduce reliance on long-lived credentials by moving to OIDC wherever possible.

GitHub confirms internal repo exfiltration via poisoned VS Code extension

GitHub disclosed and GitHub later expanded on an investigation into unauthorized access that started from a compromised employee device, where a poisoned VS Code extension was used as the initial foothold. The current assessment is that GitHub-internal repositories were exfiltrated, and GitHub responded with containment, critical secret rotation, log analysis, and monitoring for follow-on activity while a fuller report is prepared.

For developers and security teams, the takeaway is that extension supply chain risk is now incident-response-grade risk, not a theoretical concern. Treat extension allowlisting, managed workstation baselines, and tighter egress controls as part of source code protection, and assume that an endpoint compromise can translate directly into repo access if tokens and credentials are reachable.

Shai-Hulud returns with large-scale npm infections and CI credential theft

DevClass reported a Shai-Hulud campaign where a compromised npm account pushed malware into 314 packages, attempted to suppress reporting by closing GitHub issues, and used GitHub as part of its exfiltration/C2 behavior. The recommended response includes rotating secrets, checking for unauthorized repositories, and looking for persistence (including suspicious systemd services), since the payload focused on credential theft and follow-on access.

Microsoft Defender Security Research also documented a related supply-chain compromise affecting @antv npm packages, with code that executed during installation to steal CI/CD secrets, particularly targeting GitHub Actions runners on Linux. The writeup includes indicators of compromise (IOCs), mitigations, and Microsoft Defender XDR hunting guidance, highlighting how “install-time execution” can become a straight line to CI credentials and then to cloud and source control.

npm hardens releases with staged publishing GA and install-time allowlists (npm 11.15.0)

Following last week's attention on safer container distribution and supply chain hygiene, npm shipped two security-focused updates: staged publishing is now generally available, and npm CLI 11.15.0 adds install-time allowlist flags for dependencies that come from non-registry sources. Staged publishing changes the release workflow so maintainers can validate what will ship before it goes fully live, which helps catch account-takeover or automation mistakes before downstream users consume a compromised release.

The new install-time controls matter if your org depends on Git URLs, local paths, tarballs, or other non-registry sources that can bypass the usual registry trust and scanning assumptions. npm also recommends pairing staged publishing with OIDC trusted publishing and maintainer approval with 2FA, which fits the broader shift away from long-lived credentials toward identity-based release pipelines.

TanStack incident follow-up: GitHub Actions pull_request_target and cache poisoning risks

TanStack's follow-up described how a malicious pull request abused pull_request_target and shared caches, and the team outlined mitigations like removing pull_request_target, disabling caches, and pinning actions to commit SHAs. They are also weighing invitation-only pull requests to reduce exposure from unsolicited contributions, which shows how governance choices and CI configuration can be security boundaries.

If you maintain popular OSS, this is another reminder that CI and caching are part of your attack surface. Review where secrets are available, ensure forks cannot influence workflows that run with write permissions, and treat caches as potentially attacker-controlled unless you scope and harden them carefully.

Incident reports show attackers chaining identity, edge, and trusted tooling into full compromise

As a continuation of last week's “post-initial-access decides the outcome” theme (LPE, token theft, and user-mediated execution), two Microsoft incident analyses this week map out how attackers turn a single weak point into broad access by chaining identity theft, edge appliance compromise, and lateral movement through trusted internal systems. Both reports are heavy on practical detections (including KQL hunting) and mitigation guidance, which makes them useful as playbooks for your own environment reviews.

The common thread is that “initial access” is no longer the story - it is the pivot and escalation path that determines blast radius. Hardening identity and tier-0 systems, reducing credential exposure, and instrumenting for relay and lateral movement patterns are what decide whether an intrusion becomes a contained event or a cloud-wide breach.

Multi-stage Linux intrusion via F5 BIG-IP and Confluence (CVE-2025-33073)

Microsoft Defender Security Research described an intrusion that began with an Azure-hosted F5 BIG-IP edge appliance, then pivoted into an internal Atlassian Confluence server, followed by credential theft and Kerberos/NTLM relay attempts against Active Directory. The report includes Defender detections, Advanced Hunting (KQL) queries, and mitigations, and it references CVE-2025-33073 as part of the exploit chain.

For defenders, this is a clear reminder to treat internet-facing appliances and internal collaboration tools as a combined attack surface, not separate silos. Patch and inventory edge devices, restrict management plane exposure, and add detections for relay behavior and suspicious authentication flows, because the endpoint compromise can quickly become an identity compromise.

Storm-2949: from Entra ID credential theft to Azure control-plane compromise and data exfiltration

This follows directly from last week's passkeys and account-recovery discussion by showing what attackers can do when recovery and credential-reset paths stay permissive: Microsoft detailed how Storm-2949 escalated from Microsoft Entra ID credential theft and abuse of self-service password reset (SSPR) and MFA into Azure control-plane compromise. The attack path included Azure Key Vault secret theft and large-scale data exfiltration, with concrete hardening steps across identity, App Service (including publish profiles), Key Vault, Storage (keys and SAS), SQL, and VMs (including Azure VM Run Command).

The report is especially useful for teams that still rely heavily on long-lived secrets and permissive recovery flows, since it shows how attackers “live off the cloud” once they have identity footholds. Review SSPR and MFA reset policies, tighten conditional access and privileged workflows, and validate monitoring coverage for high-risk control-plane actions, not only for resource-plane telemetry.

Third-party compromise and “trusted relationship” intrusion patterns (T1199)

Microsoft Incident Response documented a stealthy intrusion that abused a compromised third-party IT provider and trusted management tooling to deploy web shells and intercept credentials on domain controllers. The attackers used lateral movement via RDP and ngrok, and the report calls out detections for malicious password filter DLLs in LSASS and network provider credential interception, backed by Microsoft Defender XDR hunting queries.

For many orgs, this is the uncomfortable but actionable reality of managed services and vendor tooling: the trust boundary often sits outside your tenant. Treat third-party tooling as privileged, monitor it like you monitor admin accounts, and reduce implicit trust by separating admin planes and requiring strong identity signals for remote management operations.

Microsoft targets signed-malware services and documents the infrastructure behind Fox Tempest

Microsoft published both a disruption update and a deeper threat intelligence analysis on Fox Tempest, a “malware-signing-as-a-service” operation that helped criminals make malware look legitimate to evade defenses and support ransomware campaigns. The legal and technical action focused on disrupting infrastructure and reducing the service's ability to issue signed payloads at scale.

The more technical report details how Fox Tempest abused Microsoft Artifact Signing to issue short-lived certificates used to distribute signed malware, including infrastructure insights, a Vanilla Tempest case study, Defender detections, indicators of compromise (IOCs), and mitigation guidance. For defenders, this is a reminder that signed binaries are not automatically safe, so policy and telemetry should treat “signed” as a signal to evaluate, not a bypass.

AI agent security moves from theory into frameworks, tests, and governance packages

Building on last week's agent-security thread (least-privilege tokens, landing-zone governance, and safer PR review), several releases and guides this week focused on making agent security and safety practices concrete: deterministic controls against prompt injection, CI-friendly red-teaming, and reusable governance building blocks for agent toolchains. The broader shift is toward treating agent behavior like any other production system: define policies, enforce them at runtime, test failure modes continuously, and audit what tools and data an agent can touch.

This matters because agents tend to combine three risky things: untrusted input (prompts), privileged tools (APIs, file systems, tickets, deployments), and memory/state that can be poisoned over time. The new tooling aims to make those risks testable and enforceable rather than relying on “be careful with prompts.”

Agent Framework adds FIDES information-flow controls (GA)

Microsoft Agent Framework introduced FIDES, which applies deterministic information-flow control to block prompt injection and data exfiltration. The model uses labels and per-tool policies that are enforced before a tool executes, and it can route uncertain content through a “quarantined LLM” path rather than letting potentially tainted input drive privileged actions.

For developers building agents, this is a more practical guardrail than prompt-only patterns because it gives you an explicit policy boundary around tool use. Expect to spend time modeling what data is allowed to flow into which tools (and what must be blocked or sanitized), then wiring it through configurations like SecureAgentConfig.

RAMPART and Clarity open-sourced for CI red-teaming and safety documentation

This complements last week's advice on reviewing agent-generated pull requests by giving teams a way to automate “reviewable safety” as tests and repo artifacts: Microsoft open-sourced RAMPART and Clarity to bring agent safety into day-to-day engineering workflows. RAMPART integrates red-teaming scenarios into CI using pytest-based tests (building on ideas from PyRIT), while Clarity captures design intent, failure analysis, and decisions as versioned repo artifacts (via a .clarity-protocol approach).

This pushes teams toward treating agent risk like regression risk: you can gate releases on known bad behaviors (cross-prompt injection paths, unsafe tool use, sensitive data leakage) the same way you gate on unit tests. It also helps when you need to explain why an agent behaves the way it does, since policy and design decisions become reviewable artifacts rather than tribal knowledge.

Agent Governance Toolkit MCP Extensions for .NET (public preview)

Following last week's MCP governance and “agent sprawl” coverage, Microsoft released Microsoft.AgentGovernance.Extensions.ModelContextProtocol in public preview as a companion for the MCP (Model Context Protocol) C# SDK, targeting .NET 8+. The package adds startup tool scanning, identity-aware policy enforcement, response sanitization, plus audit/metrics wiring through a single WithGovernance(...) builder extension.

For .NET teams standardizing how agents connect to tools (via MCP servers), this is a step toward consistent governance without rewriting the same policy hooks in every service. The most immediate win is centralizing auditing and enforcement so security reviews can focus on policy definitions and tool exposure, not ad-hoc per-agent implementations.

Defensive guidance for LLM apps: memory poisoning, jailbreaks, and evasion

A defender-focused guide laid out common threats against LLM-based apps and agents, including memory poisoning, cross-prompt injection, jailbreaks, and evasion techniques, then mapped them to a defense-in-depth stack. It highlights Microsoft defenses like Azure AI Content Safety Prompt Shields and Spotlighting in Azure AI Foundry as practical layers you can apply around prompting and tool use.

This is useful context if you are building agents with long-term memory or retrieval-augmented generation (RAG), where “what the model knows” can be influenced by untrusted inputs. Treat memory and retrieved documents as hostile until verified, and combine runtime controls (like policy enforcement and sanitization) with continuous testing (like red-team suites) to catch regressions.

Identity and privacy: workforce identity platforms and zero-knowledge credentials

Continuing last week's identity focus on phishing-resistant sign-in and tightening recovery paths, identity security remained a core theme this week, spanning enterprise platform positioning and new privacy-preserving identity research. The practical thread for builders is that identity is expanding beyond employees to include AI agents and other non-human identities, which raises questions about authentication strength, policy enforcement, and auditability.

Teams should expect more pressure to standardize on phishing-resistant authentication and to build governance around how identities (human or agent) request access, rotate credentials, and prove eligibility. At the same time, privacy-preserving proofs may become a building block for higher-trust workflows where you need verification without oversharing personal data.

Microsoft Entra positioned as a Leader in workforce identity security (Forrester Wave Q2 2026)

Microsoft shared that it was recognized as a Leader in Forrester's Workforce Identity Security Platforms Wave (Q2 2026), and used the announcement to emphasize Entra's approach to unified identity signals, policy enforcement, and response. The post highlights Identity Threat Detection and Response (ITDR) and phishing-resistant authentication, and explicitly calls out the need to extend identity governance to AI agents and other non-human identities.

For developers, the non-human identity point is the most actionable: if your systems will run agents, service principals, or workload identities at scale, you need lifecycle controls and monitoring that look more like workforce IAM than “just another secret in CI.” Start by inventorying identities, reducing secret usage, and tightening policy for high-risk actions.

Vega: low-latency zero-knowledge proofs for privacy-preserving identity

Microsoft Research introduced Vega, a low-latency zero-knowledge proof (ZKP) system designed to let users prove facts from government-issued credentials without revealing the credential itself. The design targets mobile performance and supports repeated, unlinkable presentations, which matters for real-world identity checks that should not create a trackable trail.

The post also frames this as relevant to AI-agent workflows and decentralized or on-chain systems, where you may need “prove you are eligible” without copying sensitive identity documents into every workflow. For builders, this signals where privacy and identity may go next: more cryptographic proofs, less data replication.

Platform and tooling changes that reduce operational security friction

This fits with last week's emphasis on making controls operational (patching LPEs quickly and tightening recovery paths) because security work is often won or lost on operational details: can teams patch without downtime, can admins install trusted shells on macOS without workarounds, and can network teams preview rule changes before breaking production flows. Several updates this week focused on those “reduce friction, increase compliance” mechanics.

Taken together, these changes help teams move from “security as exception” to “security as default workflow.” That includes easier patching (hotpatch), better packaging trust on macOS, and more predictable network enforcement changes through simulation.

Azure Arc hotpatching for Windows Server 2025 is now no additional cost

Hotpatch enabled by Azure Arc is now available at no additional cost for Windows Server 2025, with onboarding via the Azure Connected Machine agent and orchestration through Azure Update Manager and APIs. The post outlines eligibility and rollout considerations, and it mentions virtualization-based security (VBS) as part of the broader hardening story.

For ops teams, the practical implication is fewer excuses for patch latency, especially for fleets that are hard to schedule for reboots. Review which servers can be onboarded, then update patch runbooks to use Update Manager orchestration so hotpatch becomes a routine control, not a special case.

PowerShell on macOS: notarized and hardened runtime

PowerShell for macOS is now Apple-notarized and built with hardened runtime settings, reducing Gatekeeper warnings and the need for installation workarounds. The change is landing in upcoming maintenance releases for PowerShell 7.4 and later, and it includes a tarball permissions fix.

If you manage developer workstations, this helps standardize shell tooling without weakening macOS security posture. Update internal install docs and MDM scripts to remove any legacy xattr or bypass steps that were only needed because of earlier notarization gaps.

Azure Virtual Network Manager Rule Impact Analyzer simulates rule changes

Azure Virtual Network Manager added Rule Impact Analyzer, which simulates proposed security admin rules against observed VNet traffic. It uses Network Watcher Traffic Analytics and Log Analytics (KQL) to preview which flows would be affected before you enforce changes.

This is especially useful for security teams that want to tighten segmentation but fear breaking production connectivity. Bake the analyzer into change management so rule proposals come with evidence of expected impact and a list of potentially broken flows.

Secure-by-default development: fewer false positives and safer unsafe code

Two .NET updates this week targeted common pain points: vulnerability noise from platform-provided packages and the difficulty of reasoning about unsafe code boundaries. Both aim to make secure development more maintainable by improving defaults and making risk easier to spot during reviews.

For teams, these changes reduce “alert fatigue” and improve the quality of security signals that reach developers. They also encourage more explicit contracts in code where undefined behavior and memory corruption risk exist.

NuGet package pruning in .NET 10 and NuGetAuditMode=all default

NuGet package pruning becomes a default in .NET 10, removing platform-provided packages from the restore graph to reduce false-positive vulnerability findings. The post also notes that NuGetAuditMode=all becomes the default, affecting how transitive dependency auditing works and how warnings like NU1510 and NU1903 show up.

Practically, this should make vulnerability reports more actionable because developers will spend less time triaging packages that are effectively provided by the platform. If you have CI policies around NuGet audit warnings, test .NET 10 upgrades early so you understand how pruning changes the dependency graph and how to tune baselines.

C# 16 “caller-unsafe” model (preview planned for .NET 11, release in .NET 12)

This echoes last week's hardware and memory-safety thread (CHERI and verifiable protection) by pushing clearer safety boundaries up into mainstream language tooling: Microsoft outlined a C# 16 “caller-unsafe” model that turns unsafe into an explicit caller contract rather than a hidden implementation detail. The proposal requires inner unsafe { } blocks at unsafe operations and encourages standardized safety documentation, with preview planned in .NET 11 and production release targeted for .NET 12.

For security reviews, this can make unsafe boundaries clearer across methods and assemblies, which helps teams reason about where undefined behavior (UB) can be introduced. Start identifying hotspots where unsafe code is used today and plan how you will document and propagate unsafe requirements once the feature lands.

Other Security News

Microsoft's May 2026 security roundup included Microsoft Purview DSPM going GA, Purview Data Security Investigations enhancements (including OCR and custom examinations), Microsoft Entra ID account recovery, and Windows 365 for Agents in public preview alongside Microsoft Agent 365. For teams rolling out AI tooling, the recurring theme is governance and investigation capabilities catching up to where data is actually moving.

GitHub shipped several security-adjacent admin updates: expanded OIDC support for Dependabot and code scanning to more private registries (Cloudsmith and Google Artifact Registry), a Python 3.9 deprecation date for Dependabot (June 23, 2026), and a simpler path to start GitHub Advanced Security trials directly from risk assessments. There was also a small but breaking API change with removal of code_scanning_upload from the /rate_limit endpoint response, which integrations may need to adjust for.