Weekly Security Roundup: OAuth hygiene, agent guardrails, CMK

by TechHub

This week's Security roundup focuses on tightening access and making security decisions easier to audit. GitHub shipped OAuth refresh tokens with stricter redirect hygiene and added incident response controls to revoke credentials by token type, while CodeQL and code scanning updates improved detection coverage and clarified governance with new audit signals and a “Mitigated” dismissal reason. On the platform side, Azure and Fabric continued the shift toward keyless patterns (managed identity), programmable encryption governance (CMK APIs), and stronger recovery posture with immutable SQL backups, alongside practical guidance for securing agentic systems by constraining tools, data access, and runtime.

This Week's Overview

GitHub OAuth and incident response controls

Building on last week's push to replace long-lived secrets with identity-first, time-bounded access (for example NuGet's move toward OIDC trusted publishing), GitHub OAuth apps now get first-class refresh tokens and clearer redirect hygiene so integrators can stay durable without relying on overly broad or permanent credentials. Access tokens now expire after 8 hours, and you can request a 6-month refresh token by adding the offline_access scope, which makes it easier to build long-lived integrations without minting overly-permissive tokens. GitHub also added support for up to 10 callback URLs, which helps teams keep dev/staging/prod redirects separate without registering multiple apps.

The security footnote is worth acting on: if you rely on legacy wildcard redirect URI matching, treat this as an audit trigger. Tight, explicit redirect URIs reduce the blast radius of redirect-based token theft, and the new multi-callback support removes one of the common reasons teams keep wildcard redirects around.

On the response side, GitHub Enterprise added the ability to revoke or deauthorize credentials by token type (PATs, SSH keys, OAuth tokens, and GitHub App user tokens) from both the UI and REST API, with audit logging and user notifications. That gives security teams a more targeted playbook during incidents (for example, revoke all PATs while leaving deploy keys untouched) and makes it easier to automate containment without taking the whole org offline.

GitHub application security and governance updates

This week's GitHub security changes mostly land in the “make security state easier to audit and explain” category, picking up directly from last week's focus on stronger scanning defaults and enterprise-wide controls by adding more modeling coverage and clearer governance signals. spanning CodeQL, code scanning workflow separation, and new audit signals.

CodeQL 2.26.3 expands modeling and GitHub Actions detections

Following last week's CodeQL 2.26.2 language and query updates, CodeQL 2.26.3 updated multiple GitHub Actions security queries, including detections for cache poisoning and environment variable injection patterns that are easy to miss in review but common in workflow abuse. It also expanded JavaScript/TypeScript modeling (including Vue and Vue Router) so dataflow sources and sinks are recognized more accurately, which should improve both coverage and signal for web apps.

The release also adjusted C/C++ modeling around Windows registry APIs and refined how Ruby vendored gems are treated to reduce false positives. If you maintain query baselines or triage automation, plan for some alert churn as the modeling changes settle.

Code scanning adds “Mitigated” to make risk decisions explicit

Building on last week's theme of making security outcomes enforceable at scale (not just visible), GitHub code scanning now supports a “Mitigated” dismissal reason for alerts where the vulnerable code still exists but external controls reduce exploitability (for example, a WAF rule, network policy, or compensating runtime control). This is a practical middle ground between “won't fix” and “false positive”, and it helps teams record the real reason an alert is being closed.

For developers, the key is process: “Mitigated” works best when you pair it with a link to the control (policy, rule, ticket) and a review cadence, since compensating controls can drift over time.

GitHub Code Quality gets better auditability (and changes how workflows appear)

After last week's Code Quality GA and scaling-focused CodeQL default setup work, GitHub Code Quality now emits audit log events when it is enabled, disabled, or updated on a repository, and those events are available in org/enterprise audit logs and queryable via the audit log API. That closes a common governance gap where security teams can see scanning results but not always when a repo changed its configuration.

Separately, Code Quality CodeQL workflows now run under a dedicated GitHub Actions path and actor, which means workflow-history filters and billing/usage reports that previously keyed off the old path or actor need updates. If you have internal dashboards that aggregate “all CodeQL runs” or enforce policies based on workflow identity, validate them against the new separation.

Securing agentic systems by constraining tools, data, and runtime

Building on last week's “humans set policy, systems execute” guardrails for agents (approval gates, least privilege, and MCP allowlists/denylists), several posts converged on a consistent theme: for AI agents, safety comes less from telling the agent “don't do bad things” and more from designing the environment so unsafe actions are hard or impossible. This week that showed up in both platform design (sandboxing and approvals) and in practical ways to attach governed tools (MCP) without leaking secrets.

Azure SRE Agent shifts enforcement outside the model's reach

Continuing the “Zero Ops” governance pattern from last week, Azure's SRE Agent redesign puts guardrails in the infrastructure rather than the agent prompt. The design uses microVM sandboxing to isolate execution, routes outbound access through an egress proxy to enable secretless authentication, and scrubs secrets before anything is included in model context. For high-risk production mutations, it adds risk-based approval so the agent cannot unilaterally apply changes.

For teams building their own internal agents, the pattern is portable: assume the model output is untrusted, keep credentials out of the agent process, and enforce “can it do X” checks in components the agent cannot modify. That tends to produce controls you can reason about, test, and audit, instead of relying on prompt discipline.

MCP connectors reduce hand-built auth while keeping policy central

Following last week's MCP governance focus (including Copilot enterprise MCP allowlists/denylists and Azure DevOps Remote MCP Server GA), the MCP Connectors canvas extension for the GitHub Copilot app aims to remove the common foot-gun of wiring MCP servers by manually pasting endpoints and auth headers. Instead, you connect hosted MCP servers from Azure Connector Namespace, with user-scoped MCP configuration shared across the Copilot app and Copilot CLI. The security story matters here: connectors can rotate secrets and apply access policies centrally, so “agent tooling” looks more like managed integration than ad-hoc scripting.

Azure Connector Namespace also showed up as a practical way to host MCP servers for Azure SRE Agent, including an end-to-end SQL MCP example using Azure Developer CLI (azd) and managed identity authorization. For platform teams, this is a useful step toward standardizing how agents call internal systems while keeping identity and policy in Entra ID and Azure.

Fabric and SQL MCP servers bring RBAC and governed access to data operations

In the same direction as last week's guidance to reduce ambient authority for agent-to-tool access (and use centrally enforced allowlists), Microsoft Fabric added a preview Fabric Data Warehouse MCP Server (remote) plus “Skills for Fabric” so MCP-compatible agents can execute T-SQL against Fabric Warehouses and follow Fabric-specific guidance for authoring, querying, and diagnostics. Authentication is based on Microsoft Entra ID OAuth 2.0, which lets organizations bring existing conditional access and RBAC patterns into the agent workflow.

In the broader SQL ecosystem, the SQL MCP Server concept (built on Data API Builder and MCP) frames a governance goal: let tools like Copilot query SQL Server, Azure SQL, and Fabric SQL Database without giving the agent raw SQL access by default. If you're adopting agentic data tooling, this is the line to draw early - prefer constrained APIs with explicit permissions and auditing over “agent can run arbitrary SQL”.

Platform security hardening across Azure and Fabric

This week included several “foundational security” platform updates that reduce key sprawl, improve encryption governance, and harden recovery against ransomware-style threats, extending last week's identity-first CI/CD and confidential compute threads into more day-to-day platform controls. The common thread is moving from manual configuration to repeatable, auditable controls.

Managed identity and keyless patterns keep showing up in new services

Building on last week's emphasis on replacing long-lived secrets with workload identity, Azure Web PubSub chat entered public preview with chat-native concepts like rooms, members, roles, ordered messages, and persistent history backed by Azure Storage. Security-wise, it supports using managed identity and Microsoft Entra ID to avoid embedding long-lived secrets in services that often sit on the public edge.

Fabric Eventstream also added workspace identity authentication (preview) for Azure Event Hubs sources, replacing shared access keys in connection strings with Entra ID tokens governed via Azure RBAC. This is a straightforward but high-leverage shift: rotating keys and hunting down leaked connection strings is painful, while RBAC-based access and token lifetimes are easier to standardize.

Encryption governance becomes programmable for Fabric workspaces

Customer-Managed Key (CMK) REST APIs for Microsoft Fabric workspaces reached general availability, enabling programmatic assignment and rotation of Key Vault-backed keys. The APIs also support inspecting encryption configuration, resetting keys, and generating tenant-wide reporting about workspace encryption state.

For platform teams, the practical win is automation: you can enforce CMK at scale during provisioning, integrate key rotation into change management, and continuously audit compliance rather than treating encryption as a one-time setup step.

Backup immutability strengthens database recovery posture

Echoing last week's ransomware containment and “assume compromise” operational guidance, Azure SQL Database and Azure SQL Managed Instance now support automatic backup immutability, using WORM-style protection so backups cannot be modified or deleted during the retention window. This targets a common ransomware tactic where attackers destroy backups after gaining control of a subscription or credentials.

If you operate regulated workloads or have strict recovery requirements, immutability shifts the recovery conversation from “did we rotate keys and lock down delete permissions” to “are backups cryptographically and policy-protected against tampering”. Make sure you understand retention implications and how to verify immutability status as part of your recovery testing.

Threat intelligence and defender tradecraft: tracking MacSync Stealer

Building on last week's macOS evasion reporting (ClickFix cloaking and fingerprinted gates), Microsoft Security Research and Defender Experts published a deep dive on tracking MacSync Stealer infrastructure as it rotates, focusing on durable behavioral pivots rather than brittle indicators. The write-up highlights hunting pivots like curl command-line patterns, URI paths, headers, and upload parameters, along with KQL advanced hunting queries defenders can adapt.

For security teams running Microsoft Defender for Endpoint and Defender XDR, this is a useful template for tracking “infrastructure churn” campaigns where IPs and domains change frequently. The practical takeaway is to build detections around behaviors that are expensive for adversaries to change consistently, then use those hits to continuously refresh concrete indicators.

Other Security News

Azure App Service Managed Instance reached GA with security-relevant defaults and controls (managed identity by default, Azure Policy and Defender for Cloud coverage, zone redundancy, and IaC support via Bicep and Terraform), which makes it a more realistic landing zone for Windows-dependent and .NET Framework apps that still need modern governance. If you're planning migrations, treat the platform security baseline as part of the “minimal code change” promise and validate how your policies (identity, network, logging) apply in this hosting model.

GitHub shipped moderation/admin improvements to manage blocked users (search, sorting/pagination, block-reason filtering, private notes, and clearer attribution/expiry info), which helps orgs operationalize trust and safety decisions with better recordkeeping. It sits alongside other governance signals this week (audit log events, new dismissal reasons) that collectively make security state easier to defend during reviews.

A few broader pieces rounded out the week: guidance on running GitHub Actions runners on AKS emphasized identity scope, egress/DNS validation, workload isolation, and runner image lifecycle as recurring security failure boundaries. On the agent side, cloud-hosted browser automation argues for session isolation, governance, observability, and reproducibility as browser-based agents move from local machines into shared infrastructure.