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

by TechHub

This week's Security roundup ties together three threads: tighter controls in CI/CD and package publishing, stronger enterprise identity enforcement in GitHub, and more practical guidance for hardening AI agents and their tool access. On the supply chain side, GitHub Actions workflow execution protections reached GA, npm introduced stage-only tokens for safer automation, and GitHub completed its SHA-1 HTTPS sunset while warning teams to audit risky pull_request_target usage ahead of enforcement. We also look at agent security patterns (MCP governance, identity-aware tool authorization, and outcome-based observability) plus Azure hardening work across TLS, private networking DNS automation, hosted control planes, and repeatable image and configuration delivery.

This Week's Overview

Securing CI/CD and the Software Supply Chain

Building on last week's supply-chain thread around OIDC-based publishing, stronger scanning signals, and safer GitHub Actions permissions, GitHub Actions workflow execution protections are now generally available, giving security teams a clearer way to control which workflows can run in sensitive contexts and to measure how policies affect developer activity. GA adds workflow file targeting, Insights reporting, and a REST API for managing allowlist-based policies, which makes it practical to roll out protections across many repositories without hand-editing settings.

GitHub is also tightening defaults around pull_request_target in certain public repositories, with enforcement moving to November 2, 2026. If you rely on pull_request_target to access secrets or elevated permissions in PR workflows, you should audit where it is used and shift untrusted PR logic to safer patterns (for example, using pull_request with reduced permissions and explicit artifact handoffs).

On the npm side, new stage-only granular access tokens let automation run npm stage publish while preventing direct npm publish, which supports an approval step (and 2FA) before a package goes live. This is positioned as a migration path ahead of npm's January 2027 removal of bypass-2FA direct publishing, so teams that still have unattended publish automation should start adjusting release flows now.

GitHub also removed SHA-1 from HTTPS on github.com and partner CDNs as scheduled, affecting GitHub Enterprise Cloud (including Data Residency). Most developers will never notice unless they have legacy clients or network middleboxes that still negotiate older crypto, but this is a good time to verify older build agents and embedded environments can connect cleanly.

Enterprise identity and policy enforcement in GitHub

This week's GitHub enterprise updates focus on reducing “configuration drift” across orgs while making identity operations more automatable. The common theme is moving security posture from best-effort guidance to enforceable controls and APIs.

Enforce GitHub Advanced Security configurations

This continues last week's push toward more consistent, auditable security baselines in GitHub (better scanning signals and clearer permissions) by letting enterprise administrators enforce GitHub Advanced Security security configurations across organizations so org and repo admins cannot override enterprise-level settings. Practically, this helps standardize code scanning and related security tooling across large enterprises, especially when teams spin up new orgs or repos frequently.

If you use GitHub Security Configurations as the source of truth, this change makes it more realistic to treat security scanning as a baseline requirement rather than a per-team opt-in. It also reduces the need for periodic audits that discover exceptions only after coverage gaps have existed for weeks.

Automate SSO authorization for classic PATs and SSH keys

This fits the same “identity-first operations” arc we covered last week (moving away from brittle, long-lived credentials) by adding an opt-in enterprise setting plus a REST API so enterprise-installed GitHub Apps can bulk-authorize classic PATs and SSH keys for SSO. The API supports authorizing across up to 50 organizations per request, which targets a common operational pain point during onboarding or org restructuring.

This does not eliminate the security trade-offs of classic PATs, but it does make SSO enforcement less brittle in large environments where developers and automation still depend on existing credentials. Treat it as a stepping stone while you continue migrating to more modern auth patterns (for example, fine-grained tokens and GitHub Apps).

SCIM user responses now include profileUrl

Following last week's theme of improving audit readiness and governance workflows, GitHub SCIM user responses now include the RFC 7643 profileUrl attribute, returning the absolute URL of the linked GitHub account. The update is additive and documented in the SCIM OpenAPI schema, so existing SCIM and GraphQL integrations should continue to work unchanged.

For identity teams, profileUrl can simplify reconciliation workflows and troubleshooting (for example, when correlating IdP users with GitHub accounts in audit processes). If you generate internal identity dashboards from SCIM responses, this gives you a stable, user-facing pointer without custom URL construction.

AI agents and MCP: hardening tool access, routing, and observability

Agentic apps are pushing security concerns up the stack from “does the model behave” to “what can the agent reach, and how do we prove it used the right permissions.” This week, several pieces connected around MCP (Model Context Protocol) servers, identity-aware tool authorization, and the reality that agents can look healthy in standard monitoring while still producing unsafe outcomes.

Running MCP servers securely

Building on last week's focus on governed MCP tool access and policy layers that sit outside the model, running MCP servers for GitHub Copilot introduces governance questions that look more like API management than typical developer tooling. The analysis compares two hosting patterns: a centralized MCP Gateway running in containers/Kubernetes versus fronting MCP endpoints with Azure API Management (APIM) and using Azure API Center as a private registry for internal MCP endpoints.

A key gap called out is around per-user OAuth and session-aware routing, which matters if you want tools to execute with the user's identity instead of a shared service credential. If you are piloting MCP internally, treat identity propagation and per-user authorization as first-class design constraints, not follow-up hardening work.

Securing AI agent tool calls with an “Agent Control Loop”

This extends last week's “enforcement outside the prompt” guidance by proposing an Agent Control Loop framework that breaks secure tool calling into five handoffs: identity validation, retrieval permissions, tool-call authorization, execution constraints, and outcome verification. The practical value is in mapping each step to concrete Azure building blocks (Microsoft Entra ID, APIM, managed identities, RBAC/Policy, and Azure AI Search security trimming), with code-level patterns for request validation and verified execution.

This approach helps teams avoid the common failure mode where retrieval is permission-trimmed but tool execution is not, or where the agent can call tools but no one can prove what happened after the call. If you are building internal copilots, this is a solid checklist for deciding where to enforce policy and where to record evidence.

Observability patterns for agents (and why “healthy” is not safe)

Picking up from last week's emphasis on OpenTelemetry-based evidence for agent hardening, Microsoft Foundry guidance highlighted that agents can pass infrastructure health checks while still generating incorrect or risky outputs, so you need outcome-based signals alongside traces. The proposed setup combines Foundry traces/evaluations with Azure Monitor (Application Insights and Log Analytics), using OpenTelemetry for instrumentation and Kusto Query Language (KQL) for investigations, alerting, and continuous evaluation.

A related Azure Databricks incident-response write-up described an “AI SRE” pattern: run deterministic platform checks and version-controlled runbooks in parallel, then use an LLM to synthesize evidence into recommendations. The guardrails called out (rate limits and scoped permissions for access to observability systems) are a useful reminder that an incident helper agent still needs least privilege.

MCP ecosystem updates and private-workload reference architecture

Following last week's momentum around MCP governance and constrained tool use, MCP Live recordings bundled spec and ecosystem updates, including MCP authorization discussions and enterprise governance via Toolboxes in Microsoft Foundry. If you're standardizing how tools get exposed to agents across teams, the governance angle matters as much as the developer SDK angle.

A separate reference architecture showed how to connect Azure AI Foundry agents to private Azure VMware Solution workloads using per-workload MCP servers on VNet-integrated Azure Container Apps. The security posture leans on ExpressRoute, private endpoints, managed identity, and Key Vault for read-only access, which is a practical template for “agents in the cloud, data on private networks” scenarios.

Azure platform security and operational hardening

Azure-focused security content this week clustered around practical controls: encrypting traffic end-to-end, avoiding certificate renewal traps, tightening private networking hygiene, and making infrastructure configuration repeatable and auditable.

End-to-end TLS and site-scoped certs for Azure Functions Flex Consumption

Building on last week's platform hardening thread around certificates and identity plumbing for hybrid and cloud services, Azure Functions Flex Consumption now supports site-scoped certificates and end-to-end TLS encryption in GA. The announcement covers certificate sources (Azure Key Vault import, managed certificates, and uploads), how to configure via infrastructure as code (IaC), and operational guidance for inbound/outbound mutual TLS (mTLS) and certificate rotation.

For teams running APIs or internal services on Flex Consumption, this closes a common gap where edge TLS existed but hop-by-hop encryption and cert lifecycle management were messy. It also makes it easier to meet stricter internal requirements (like mandating mTLS for service-to-service calls) without abandoning serverless hosting.

Certificate renewals and Azure API Management behind an edge

A troubleshooting write-up explained why Azure API Management (APIM) custom-domain validation can fail during certificate renewal when APIM sits behind Azure Front Door, Traffic Manager, or Application Gateway. The key operational lesson is that certificate renewal and custom-domain validation depend on traffic and validation flows that can be disrupted by where TLS terminates and how the edge forwards requests.

The recommendation is to move the custom domain and TLS termination to the edge, then keep APIM focused on API routing and policy enforcement behind it. The included checklist (Key Vault sync and monitoring in particular) is worth turning into a runbook if you have APIM custom domains that rotate certificates automatically.

Automating Private Endpoint DNS across tenants

This complements last week's focus on making private networking and egress controls operational (not just “turn on Private Link”) by tackling DNS sprawl, especially across multiple Microsoft Entra tenants. A proposed design automates DNS registration by combining Azure Policy DeployIfNotExists with narrowly scoped Azure Lighthouse delegation to centrally managed Private DNS zones, with phased rollout steps and validation guidance.

Security-wise, the post emphasizes using managed identities and workload identity federation (OIDC) to avoid long-lived secrets, and scoping delegation tightly so central automation can manage DNS without gaining broad access to tenant resources. If your org has multiple tenants or many subscriptions, this kind of automation is what keeps Private Link secure and supportable over time.

Hosted control planes for Azure Red Hat OpenShift (preview)

Azure Red Hat OpenShift hosted control planes entered public preview, shifting the OpenShift control plane to a Microsoft-managed service while keeping worker nodes in the customer subscription. The announcement calls out Azure integrations relevant to security operations, including Entra ID, Key Vault, Azure Monitor, and Customer Lockbox for Microsoft Azure.

From a security perspective, hosted control planes can reduce the operational burden of patching and maintaining control plane components, but you still need to validate shared responsibility boundaries and how identity/workload identity flows map to your cluster policies. If you already standardize on OpenShift, this preview is worth evaluating for environments where control plane management has been a persistent risk or staffing challenge.

Secure infrastructure delivery: images, configuration, and release gates

Repeatability was the throughline across this set of guides: treat OS images, configuration drift, and deployment approvals as part of security posture, not just operations. The focus is on producing artifacts you can validate, promote, and roll back with evidence.

Deterministic VM images with Packer and Azure DevOps validation gates

A guide outlined an Azure VM image pipeline where Packer bakes a deterministic image, publishes it to Azure Compute Gallery, and then validates the published image by creating a temporary VM. The pipeline publishes validation evidence and only promotes approved versions, which turns image delivery into an auditable process instead of “golden image by convention.”

For security teams, the validation-and-promotion approach is a practical way to enforce baseline hardening and verify required agents/extensions exist before an image reaches production. For platform teams, the Compute Gallery versioning model provides a clean rollback path when a patch or configuration change causes boot or connectivity regressions.

Immutable image releases to VM Scale Sets

A related tutorial covered deploying applications to Azure Virtual Machine Scale Sets (VMSS) using immutable, versioned VM images stored in Azure Compute Gallery and released via Azure DevOps CI/CD. It includes rolling upgrades and rollback mechanics, plus security guidance like using service connections/managed identity and Azure Key Vault for secrets.

This pattern reduces configuration drift on fleets because “what is running” maps to an image version, not a set of post-provision scripts that may or may not have succeeded. If you are still patching in place or running heavy bootstrap on every scale-out, shifting to versioned images usually makes security baselines easier to prove and incident rollback faster.

Desired State Configuration (DSC) v3.3.0 GA

This continues last week's “compliance and governance as code” direction by making host configuration drift easier to preview and remediate repeatably. Microsoft Desired State Configuration (DSC) v3.3.0 reached GA with updates aimed at day-to-day operability, including new built-in Windows resources, a registry-backed adapter, expanded --what-if support, and experimental synthetic export filtering. One notable rename is dsc mcp to dsc server, which matters if you have scripts or documentation that referenced the previous command.

For secure configuration management, better --what-if coverage helps teams preview drift remediation before enforcing changes, and built-in resources (like Microsoft.Windows/FirewallRuleList) reduce the amount of custom glue code needed for baseline hardening. If you are standardizing Windows host configuration, v3.3.0 is a good checkpoint to retest your pipelines and update command references.

App and identity security fundamentals (web, sessions, and email)

This week's security reading had a strong “back to fundamentals” theme: protect session tokens from theft, stop accidental exposure of files, and use real measurement to improve email defense. It also included Microsoft guidance on turning foundational controls into prioritized action.

A deep dive explained Device Bound Session Credentials (DBSC), which binds authentication sessions to a device using TPM-backed keys and signed challenges so stolen cookies are less useful. The walkthrough covers registration and refresh flows and calls out key HTTP headers and JWT validation steps servers need to implement.

For app teams, DBSC is a reminder that session security is not only about cookie flags but also about preventing replay on a different device. If you run high-risk apps (financial, admin portals, internal tools with broad access), device binding can meaningfully reduce the blast radius of phishing and token exfiltration.

Protecting sensitive files under wwwroot in ASP.NET Core

ASP.NET Core serves everything under wwwroot as public by default, which can surprise teams that write runtime-generated files into that directory. The recommended fix is to insert a custom middleware check before UseStaticFiles() so you can enforce authentication/authorization for specific paths.

The post also notes routing behavior and IIS reverse-proxy bypass risks, which matter when you assume an upstream component blocks access but the app still serves static files directly. If you store exports, temporary reports, or user uploads anywhere under wwwroot, treat this as a quick audit item.

Email security benchmarking and prompt injection protection

This pairs with last week's phishing-evasion coverage (normalization, telemetry, and response-ready detections) by showing how Microsoft is measuring real-world email outcomes and hardening content handling, including prompt injection protection. Microsoft shared email security benchmarking results for Microsoft Defender for Office 365 across pre-delivery and post-delivery scenarios. The update emphasized how measurement drives product changes, including improved ML/NLP detection and prompt injection protection, which matters as LLM-assisted phishing and content manipulation become more common.

For defenders, the practical takeaway is to look beyond block rates at the gateway and pay attention to post-delivery remediation and investigation workflows. If you run a Secure Email Gateway (SEG) alongside integrated cloud email security (ICES), the benchmarking framing can help you decide which layer should own which controls and how you validate outcomes.

Turning fundamentals into prioritized work with Secure Now

Building on last week's focus on turning governance into repeatable, auditable controls (policy-driven enforcement and evidence you can point to), Microsoft's Secure Now in Security Exposure Management was positioned as a way to prioritize and execute foundational controls as AI accelerates attack-path discovery and lateral movement across identity, endpoint, and network. The guidance highlights concrete control areas like Conditional Access and Attack Surface Reduction (ASR) rules, with a focus on moving from “we know what to do” to “we can prove we did it.”

This is most useful if your backlog includes dozens of security recommendations and you need a defensible order of operations tied to real risk reduction. If you are already operating a Zero Trust program, it reads as a playbook for getting the basics consistently deployed across tenants and device populations.

Other Security News

GitHub code scanning AI Scan for pull requests can now run without CodeQL default setup, which follows last week's CodeQL release cadence by lowering the friction to get scanning coverage started (even if teams are not ready to manage full query configuration yet). Azure Confidential Clean Rooms described a multiparty analytics pattern for ad measurement and audience matching using Spark SQL executed in a Trusted Execution Environment (TEE), with governance and auditability emphasized. While the example is advertising-focused, the technical pattern (controlled computation over sensitive datasets with verifiable policy) is relevant anywhere you need cross-organization analytics without sharing raw data.

ServiceNow and Azure DevOps integration guidance focused on real-world patterns like bidirectional syncing of work items, comments, attachments, and state mapping across single and multi-org setups, with governance and OAuth 2.0/Entra ID choices often deciding whether the integration stays secure at scale. A separate FinOps-ready Azure Landing Zone post reinforced keeping Azure-native governance, monitoring, identity, and automation as the foundation, then layering application-centric monitoring, alerting, remediation, and cost allocation where needed.

Finally, two agent-building resources highlighted the need to embed security in agent workflows early: a C# “agent harness” series that includes tool approvals, safe file access, observability, and governance, and a repo-readiness checklist for AI coding agents that pushes for repeatable bootstrap, CI enforcement, and least-privilege controls (including MCP and secrets handling). Both are useful if you are moving from prototypes to agents that operate in real repositories and production environments.