Weekly Security Roundup: OAuth abuse, npm compromise, passkeys

by TechHub

This week's Security roundup connects active threat intel with the platform controls teams can use to reduce exposure. Microsoft detailed ACR Stealer intrusion chains and ShinyHunters-linked OAuth abuse against Salesforce, while a real @asyncapi npm compromise showed how CI misconfigurations and trusted publishing can turn PRs into malware delivery. On the platform side, GitHub shipped more in-PR security signals (AI detections, agentic autofix, and Copilot security review) plus safer supply-chain defaults like Dependabot cooldowns and stronger secret scanning automation. Rounding it out, Entra ID moves to passkeys by default and new guidance focuses on governing AI agents and tool access with least privilege, gateways, and auditable authorization.

This Week's Overview

Active threat intel: stealers, OAuth abuse, and a real npm compromise

ACR Stealer intrusion chains using ClickFix lures

Microsoft Security Research documented two observed intrusion chains for ACR Stealer that rely on ClickFix-style social engineering to get users to run malicious steps. The write-up walks through multiple execution paths (including WebDAV + rundll32 and MSHTA + PowerShell) and calls out common tradecraft like PowerShell obfuscation, steganography, and credential theft via DPAPI.

For defenders, the practical value is the operational detail: Defender coverage notes, MITRE ATT&CK mapping, indicators of compromise (IOCs), and Advanced Hunting queries in KQL you can adapt to your own environment. If you operate endpoints where MSHTA is still viable or WebDAV access is common, this is a good moment to review application control, script logging, and suspicious rundll32 invocation patterns.

ShinyHunters-linked OAuth abuse targeting Salesforce environments

Another Microsoft Security Research post focused on ShinyHunters-linked campaigns abusing OAuth trust and common SaaS misconfigurations to access and exfiltrate data from Salesforce. The techniques described include vishing-driven consent flows, connected-app abuse, SaaS supply-chain angles, and risky guest access configurations that widen the blast radius once a foothold exists.

On the mitigation side, the post highlights improvements in Microsoft Defender for Cloud Apps for Salesforce, including added visibility and posture controls for connected apps, plus hunting guidance (KQL) and IOCs. If your org has heavy SaaS usage, this reinforces a simple checklist: tighten connected-app policies, audit OAuth grants, and treat guest access as production risk that needs continuous review.

AsyncAPI npm supply chain compromise via GitHub Actions and trusted publishing

Building on last week's CI hardening thread (read-only cache tokens and reduced PAT use), Microsoft Threat Intelligence analyzed a coordinated compromise of the @asyncapi npm organization that is especially relevant to teams publishing packages. Attackers abused a misconfigured GitHub Actions pull_request_target workflow and GitHub OIDC trusted publishing, then delivered malware at import time, including a second-stage delivery mechanism via IPFS.

The remediation guidance is practical for engineering teams: lock down pull_request_target usage, scrutinize workflow permissions, and review trusted publishing configurations so PR-controlled code cannot influence release pipelines. The post also includes defender detections, hunting queries, and IOCs that help you validate whether your environment pulled compromised versions and to hunt for import-time payload behavior in build and runtime logs.

Black Hat USA 2026 focus areas: supply chain and AI-era detection

Ahead of Black Hat USA 2026, Microsoft previewed sessions and research themes centered on supply chain attacks (including ongoing npm campaigns), SOC response, and detection research spanning Azure Automation and GitHub-focused scenarios. The post also points readers to hands-on skilling resources across Microsoft Defender, Microsoft Sentinel, and Microsoft Security Copilot.

If you are planning conference coverage, the useful takeaway is which defensive areas Microsoft is emphasizing: package ecosystem threats, operational response workflows, and detections that bridge cloud automation and developer platforms. It is a good time to validate your telemetry coverage for CI/CD, GitHub org security events, and automation accounts, since those are recurring pivots in incident response.

GitHub security platform updates: AI-assisted findings, agentic fixes, and tighter supply-chain defaults

This week's GitHub changes are about pushing more security signals earlier into PRs and automating parts of remediation, while adding guardrails around how automation runs and how quickly new dependencies turn into update PRs.

AI security detections now surface directly in pull requests (public preview)

GitHub code scanning can now show AI-powered security detections directly on pull requests, expanding beyond what CodeQL-supported languages and frameworks typically cover. It is in public preview for GitHub Advanced Security customers and uses AI credits tied to a GitHub Copilot license.

For teams, the workflow change is that security review becomes more “in-flight”: developers see findings where they already work (the PR), rather than discovering them after merge or in a separate alerts view, which complements last week's push toward more operational auditability around Copilot usage. Because billing depends on AI credits, it is worth setting expectations about when to enable it broadly versus targeting higher-risk repositories first.

Agentic autofix for code scanning alerts (public preview)

GitHub also introduced agentic autofix for code scanning alerts in public preview, where Copilot explores the repo, proposes a fix, validates by rerunning CodeQL, and then opens a draft pull request. You can trigger it in the UI and via the REST API, and it consumes both AI Credits and GitHub Actions minutes.

The important practical detail is that this is not a simple text rewrite: it is a repo-aware loop that depends on your CI configuration and CodeQL setup to validate fixes. Teams should treat it like any other automated change generator by requiring review, ensuring tests are representative, and watching spend since it couples security remediation with Actions runtime usage.

Copilot security reviews inside the Copilot app (public preview)

A smaller but useful addition is the /security-review slash command in the GitHub Copilot app, which runs an on-demand review of in-flight code changes and returns prioritized findings with suggested fixes. GitHub positions it as a lightweight check that complements deeper scanning from code scanning, Dependabot, and secret scanning.

This is most useful for early feedback loops (for example, before pushing a PR or when iterating on a fix branch), but teams should still treat it as advisory output. Pair it with repository policy so the authoritative gate remains deterministic checks (CodeQL, tests, dependency review) rather than conversational tooling.

Copilot code review adds stronger controls (instructions, setup, and firewall)

GitHub Copilot code review gained several configurability upgrades: custom instructions are now read from the PR head branch, more instruction filenames are supported, and repos can define setup steps via copilot-code-review.yml. Reviews also run behind a configurable default-on firewall, and org runner settings are now split from the Copilot cloud agent so you can pick runner types independently.

The net effect is more predictable reviews for complex repos where linting, builds, or generation steps are required to produce meaningful feedback. From a security standpoint, the firewall and runner separation build directly on last week's theme of making agent behavior more governable and auditable by constraining where execution happens and what it can reach on the network.

Dependabot adds a default 3-day cooldown for version updates

Dependabot version updates now wait three days before opening PRs by default, aiming to reduce risk from newly published compromised or broken releases. Security updates are not delayed, and you can configure the cooldown in .github/dependabot.yml.

This change aligns with what many security teams already recommend operationally: do not auto-adopt brand-new releases until the ecosystem has had time to detect problems. If your org depends on fast-moving dependencies, you may want to tune cooldowns by package ecosystem or criticality rather than turning the feature off globally.

Secret scanning expands detectors and adds automation hooks

Following last week's theme of secret scanning becoming more operational (public monitoring plus playbooks), GitHub secret scanning and public monitoring gained new partner detectors (APIclub and Resend), expanded push protection defaults for VolcEngine secrets, and new UI insight cards in the public monitoring alert list. Webhook consumers also get a new secret_category field on the secret_scanning_alert webhook, which makes it easier to route alerts by type downstream.

Secret scanning custom patterns are also now manageable via generally available REST API endpoints across repo, org, and enterprise scopes (create/list/update/delete). Dry runs and publishing still happen in the UI, but the API unlocks repeatable administration workflows and reduces the friction of scaling custom detectors across many repos.

Identity shifts: Entra ID defaults to passkeys and sunsets SMS/voice delivery

Microsoft Entra ID will roll out passkeys as the default authentication experience starting September 1, 2026, signaling a bigger push toward phishing-resistant authentication (for example, FIDO2-based credentials). Microsoft-provided SMS and voice delivery will be retired on February 1, 2027, with third-party telecom providers available via the Microsoft Security Store for organizations that still need those factors.

For admins, the immediate work is change management: validate device and platform readiness for passkeys, update onboarding docs, and ensure helpdesk procedures cover recovery flows. For developers building Entra-integrated apps, this is a good time to review sign-in UX assumptions and conditional access policies so “default” aligns with your security posture rather than legacy MFA expectations.

Securing AI agents and tool access: authorization, gateways, and least privilege patterns

MCP Enterprise-Managed Authorization (EMA) reaches stable

Building on last week's MCP hardening focus (trust checks, untrusted server connections, and concrete mitigations like allowlists and audit trails), the Model Context Protocol (MCP) Enterprise-Managed Authorization (EMA) extension is now stable, and Microsoft contrasted it with a centrally governed OAuth approach using Entra ID preauthorization plus Azure App Service Authentication. The companion repo includes a deployable App Service FastAPI MCP server and a local lab demonstrating the ID-JAG exchange using RFC 8693 (token exchange) and RFC 7523 (JWT bearer assertions).

For teams building agent toolchains, this is a concrete path to move from ad-hoc tool tokens to auditable, enterprise-managed flows. The practical takeaway is that you can combine Entra-governed consent, App Service authentication, and standardized token exchange to reduce secret sprawl while keeping authorization decisions centralized.

Least privilege guidance for agent identities and tool binding

Microsoft published a dedicated least-privilege model for AI agents that focuses on dedicated agent identities, task-scoped RBAC, safe tool allowlists, and end-to-end audit logging. It explicitly frames tool binding (what tools an agent is allowed to call and under what identity) as a core control for reducing blast radius and for investigating incidents like prompt injection or unintended data access.

This guidance is actionable if you are moving agents from demos to production: define per-agent managed identities, constrain permissions to the minimum needed per task, and log tool calls in a way security teams can query. It pairs well with gateway patterns (APIM) where you can enforce quotas and policy while preserving identity context.

Foundry adds an AI Gateway control plane tied to Azure API Management

Microsoft Foundry can now create or associate an Azure API Management (APIM) AI Gateway from the Foundry admin console. This enables project-level token limits and governance while keeping the data path in APIM, and the post clarifies what Foundry manages versus what still requires direct APIM configuration.

For App Service-hosted agent architectures, the key design point is separation of concerns: Foundry becomes the governance entry point for projects and limits, while APIM remains the enforcement and routing layer for traffic. Teams that already standardized on APIM policies can adopt this without rebuilding the gateway, but should review policy ownership boundaries so changes remain auditable.

APIM-based governed AI gateways for cost controls and chargeback

This continues last week's push toward “explicit mediation” at tool and egress boundaries by showing how APIM can enforce quotas and capture proof: two posts dug deeper into APIM as the hub for model governance. One described moving from “multi-model chaos” to a governed AI gateway with per-consumer entitlements, token limits, and budget-based model downgrades, plus streaming token metrics to Application Insights. Another focused on APIM in front of Azure AI Foundry to emit per-model token metrics (for chargeback and alerts) without changing client code, positioning Azure Front Door + WAF as the public edge for defense in depth.

These patterns matter because they treat governance as runtime policy, not documentation: you can enforce quotas, route to different models based on budget, and capture usage telemetry centrally. If you are routing GitHub Copilot Chat/Copilot CLI or internal apps through a gateway, you get a single place to apply private endpoints, managed identity, and consistent logging for incident response.

Responsible browser-capable agents and production tool discovery discussions

Microsoft Foundry also announced round tables in the Foundry Discord that focus on agent security in practice. One covers the Browser Automation Tool (BAT) and how Foundry agents use Playwright Workspaces to drive real browser workflows, emphasizing guardrails like oversight (human-in-the-loop), isolation, and observability. Another focuses on scaling agents with Foundry Toolbox, Skills, and Tool Search, including MCP-based architecture, versioning, runtime tool discovery, and identity passthrough with governance controls.

These sessions are worth tracking if you are experimenting with agents that can take real actions (browser clicks, workflows, shared tools) because the biggest risks come from over-broad tool access and weak audit trails. The consistent theme is to treat agents like automation systems: sandbox them, constrain tools, and ensure every action is attributable and reviewable.

Azure AI Landing Zones and governance as “policy to proof”

For longer-horizon planning, Microsoft outlined Hypervelocity Engineering (HVE) as an operating model for continuously evolving enterprise AI platforms, mapping it to Azure AI Landing Zones using IaC, Policy as Code, DevSecOps, and continuous observability. A separate architecture post framed AI governance as a loop from policy to controls to observability to audit proof, mapping governance domains to services like Foundry, Purview, Entra, Defender, and APIM AI Gateway, with mentions of OpenTelemetry and an Agent Control Specification (ACS).

The shared message is that AI security is becoming an engineering system, not a one-time review. It reinforces last week's governance-through-telemetry direction (AGT + OpenTelemetry and SIEM-ready audit trails) by spelling out where to encode controls (policy), where to enforce them (gateway/identity), and where to prove them (logs, traces, audits).

Edge and data-path security: programmable controls at the edge and safer outbound AI from SQL Server

Azure Front Door edge actions (public preview)

Azure Front Door introduced edge actions in public preview, letting you run lightweight JavaScript during request processing at Microsoft's global edge. Supported scenarios include request routing, header manipulation, request rejection, and basic auth checks, and Microsoft highlighted Hyperlight micro-VM isolation along with operational tooling like versioning, execution filters, canary deployments, and logging.

For security teams, this creates a new place to enforce pre-origin controls without waiting for application deploys, but it also adds a new “policy surface” that needs governance and review. Treat edge actions like code: version them, restrict who can publish, and ensure logs flow into your central observability so you can correlate edge decisions with WAF and app telemetry.

SQL Server 2025 outbound AI connectivity security reaches GA

Following last week's focus on controlling outbound paths (for example, Fabric Workspace Outbound Access Protection), SQL Server 2025 outbound AI connectivity security features are now generally available, covering how external REST invocation and external model objects are enabled, permissioned, authenticated, and audited. The post specifically calls out least privilege, endpoint restrictions, and SQL-native monitoring via SQL Server Audit and Extended Events, with examples like sys.sp_invoke_external_rest_endpoint and CREATE EXTERNAL MODEL.

This is a meaningful boundary-hardening step for teams embedding AI calls into database workflows: outbound connectivity is a common exfiltration route if it is not tightly controlled. If you enable these features, plan for explicit allowlists, tight permissions on who can invoke external endpoints, and auditing that lets you answer “who called what endpoint with what context” during incident investigations.

Patch and posture: July 2026 .NET servicing and platform security-by-default

Microsoft published the July 2026 servicing recap for .NET and .NET Framework, including fixed CVEs and links to release notes, downloads, container images, Linux install instructions, and known issues for .NET 10/9/8 (including .NET 10.0.10, .NET 9.0.18, and .NET 8.0.29). If you run .NET in containers, the post is a reminder to update base images in addition to SDK/runtime packages, since stale images often keep vulnerable layers around even after code upgrades.

From a security operations perspective, align this with your patch SLAs: prioritize internet-facing ASP.NET Core services and any workloads processing untrusted input, then follow with internal services and build agents. Make sure your SBOM and vulnerability scanners are pointed at both application dependencies and runtime layers, especially if you publish multiple images or maintain long-lived build pipelines.

Other Security News

Organizations that need more control over developer tooling got a new governance option, and a couple of reference pieces focused on building secure data and API access patterns without embedding secrets in app code. These are not incident-driven, but they support the same goal: reduce uncontrolled software surfaces and make access auditable.