Weekly Security Roundup: Identity Hardening and Agent Guardrails

by TechHub

This week in security, the focus shifted from adding more automation to putting tighter boundaries around it, starting with stronger identity and session controls in GitHub and extending into agent governance across Microsoft Foundry. Updates also targeted the places teams tend to forget until something breaks, including SSH hardening, CodeQL packaging changes, and NuGet signing trust policies that can block CI if you do not update proactively. On the threat side, new reporting on compromised service principals and device code token theft reinforced an identity-first reality where attackers can automate destruction and persistence once they have the right tokens. Rounding things out, platform guidance and releases highlighted practical isolation and egress controls (microVM sandboxes, pod sandboxing, confidential containers) plus operational lessons like how Blob immutability can quietly prevent cleanup when you need it most.

This Week's Overview

Identity and session hardening for developer platforms

GitHub shipped two changes aimed at reducing damage from stolen sessions and weak SSH defaults. “Proof of presence” (public preview) adds a step-up requirement for high-impact actions in GitHub Enterprise Cloud EMU enterprises using Microsoft Entra ID SSO, forcing a fresh re-authentication or MFA prompt before sensitive operations (building on GitHub sudo mode). That shifts risk from “session token stolen once, admin forever” toward a tighter window where privileged actions require recent user presence.

On the transport side, GitHub outlined upcoming SSH hardening that will break older client and key setups. The platform is deprecating SHA-1-based RSA signatures (ssh-rsa), removing diffie-hellman-group-exchange-sha256, enforcing a 3072-bit minimum for newly uploaded RSA keys, and enabling the post-quantum hybrid key exchange mlkem768x25519-sha256 on github.com and some GitHub Enterprise Cloud regions. If you run older OpenSSH clients, automate Git operations in CI, or depend on legacy key material, now is the time to validate SSH algorithm negotiation and move to RSA-SHA2 or Ed25519 where possible.

Local agent tooling got a similar guardrail in the GitHub Copilot app (public preview) with per-project sandbox policies, continuing last week's push to constrain Copilot agent actions by moving those boundaries down to the local runtime. You can restrict filesystem access, network access, and credential usage for local sessions, and the app “fails closed” if the OS cannot enforce the requested sandbox, which is a meaningful default for teams experimenting with local agent workflows. You can even enable sandboxing mid-session with /sandbox on, which is useful when a chat turns into “run commands in my repo” territory.

Agent and AI governance controls move closer to “default-on”

Several posts this week converged on a clear pattern: ship more autonomous agents, but pair them with enforceable boundaries (identity, isolation, egress control, evaluations, and auditability), picking up where last week left off with Citadel-style governance patterns and Copilot policy controls. Microsoft Foundry updates expanded model and agent capabilities while adding governance hooks, and GitHub/Microsoft tools continued to push measurable safety practices from documentation into day-to-day developer workflows.

Runtime risk measurement and policy generation with run-assert-eval

The new run-assert-eval VS Code skill connects three pieces into a tight loop: Clarity risk discovery, ASSERT evaluations, and Agent Control Specification (ACS) policy generation, extending last week's theme of turning agent governance into repeatable, testable controls rather than one-off reviews. The point is not just to find failures, but to apply runtime controls (expressed as policies, including Rego-based enforcement) and rerun the same eval to prove whether risk dropped without reducing helpfulness. For teams building agent experiences, this is a practical way to treat governance like a test suite rather than a one-time review.

Network egress controls for hosted agents (audit first, enforce later)

Foundry Agent Service added a preview path for controlling where hosted agents are allowed to connect, which complements last week's emphasis on AI gateways and policy-managed boundaries by making outbound reachability an explicit, observable control. The workflow supports Audit and Enforced modes, so you can start by observing what the agent would have tried to reach, then flip to hard blocks once you have confidence. The post highlights that you get observable egress decision telemetry (for example through Application Insights), which is critical if you want enforcement without creating “it stopped working” mysteries.

Isolation primitives for hosted sessions (and how to design for them)

Microsoft Agent Framework documentation dug into two isolation controls for Foundry hosted agents: user isolation and hosted session isolation, continuing the same “bounded automation” thread from last week's agent governance coverage by showing how to scope state and identity per user and per session. The guidance is practical: you can supply delegated identities, manage an agent_session_id to keep a stable sandbox when needed, or pool sessions when you want a shared environment with controlled boundaries. If you are building multi-tenant agents, this is the difference between “every request shares state” and “state is intentionally scoped and traceable.”

Agent-first platform design: split governance from execution

An “agent-first” platform pattern showed up as a proposed architecture, and it lines up with last week's Citadel framing by treating governance (identity, tracing, evaluation) as a shared platform concern while keeping execution tightly sandboxed. Keep governance in Microsoft Foundry (Entra Agent ID, tracing, evaluation) while pushing execution into Azure Container Apps Sandboxes, where each task can run in an isolated microVM. That separation helps teams scale autonomy without letting runtime execution inherit broad permissions, and it makes it easier to apply compliance controls consistently even as toolchains and agent runtimes multiply.

Secure reference architectures for multimodal GenAI workflows

A manufacturing-oriented reference architecture demonstrated how to turn assembly videos into illustrated work instructions using Azure OpenAI (Whisper plus GPT-5.1), Azure Functions, and explicit human approval gates, extending last week's focus on applying landing-zone style controls to AI workloads into a concrete multimodal pipeline. The security guidance was not abstract: it called out storage protections, identity via managed identity, private networking, monitoring, and AI governance (including Azure AI Content Safety). If you are implementing multimodal pipelines, the big takeaway is to treat media ingestion, intermediate artifacts, and model calls as a chain with different data sensitivity levels and controls at each hop.

Threat intelligence: agentic and token-driven attacks raise the bar for identity protection

This week brought two detailed looks at how attackers are operationalizing automation and token theft, reinforcing last week's incident writeups on AiTM and device-code style abuse by showing what post-compromise looks like when adversaries can automate cloud control plane actions. The common thread is that cloud identity (service principals, OAuth tokens, device code flows) is now a primary blast radius multiplier, so detection and recovery need to assume “identity compromise first, payload later.”

Storm-3168 (JADEPUFFER): compromised service principals used for rapid cloud destruction

Microsoft Security Research reported Storm-3168 activity targeting Azure via compromised service principals, using them for reconnaissance, storage key retrieval, and fast destructive operations across storage and app resources, which is a direct escalation of last week's “identity-first” message from user sessions to workload identities. The mitigations emphasize workload identity protection and least privilege in Azure RBAC, plus recovery safeguards like resource locks and improved logging and detections through Defender for Cloud and Defender XDR. The practical message for platform teams is to inventory service principals, tighten permissions, rotate credentials, and make sure you can quickly detect anomalous principal behavior before it turns into “delete and destroy” automation.

EvilTokens: device code phishing and token persistence at scale

Microsoft disrupted EvilTokens, an AI-enabled phishing-as-a-service platform that automated inbox analysis and fraud preparation after compromising email accounts, building on last week's coverage of AiTM and OAuth device code phishing by detailing the token lifecycle and persistence mechanics defenders actually have to break. The companion technical write-up explains how the platform abuses the OAuth device code flow to steal tokens and compromise accounts, including evasion infrastructure and how tokens can persist (for example via PRT-style persistence patterns). Defensive guidance focuses on Entra ID and Conditional Access mitigations, plus Defender XDR detections and KQL hunting queries so SOC teams can catch the chain earlier than “fraudulent payment change request received.”

Storm-2570: consistent post-compromise tradecraft across ransomware ecosystems

Microsoft Threat Intelligence mapped Storm-2570's repeatable post-compromise behaviors across multiple ransomware-as-a-service ecosystems (including Qilin, DragonForce, Anubis, and others), complementing last week's emphasis on cross-domain disruption by providing hunting coverage that triggers during the staging and lateral movement phase. The report highlights common tooling and techniques for remote access, credential theft (including NTDS.dit dumping), lateral movement, and exfiltration (including tools like s5cmd for S3-style transfer patterns). You get mitigation guidance plus Defender coverage and Sentinel hunting queries, which is especially useful if you want detections that trigger during the setup phase rather than at encryption time.

Supply chain and scanning: signing changes and CodeQL updates that may break pipelines

Two GitHub updates and a .NET ecosystem change landed in the same week, and all three can impact build and security automation, continuing last week's DevSecOps guardrails thread where small policy shifts (rulesets, cache permissions, scanning rollouts) can become release blockers if you do not bake them into CI hygiene. The theme is “small operational changes that become incident-level when they break CI or hide security drift,” so it is worth verifying your tooling now.

Microsoft updated its default NuGet author-signing certificate starting September 23, 2026, publishing the new SHA-256 fingerprint and the steps needed to update trusted signer policies. If you enforce trusted signers (for example through dotnet nuget trust) or run dotnet nuget verify, stale policies can surface as install failures (including errors like NU3034). Teams with locked-down build agents should roll the fingerprint update through images and internal documentation, not just developer machines.

CodeQL 2.27.1 landed with query and extractor improvements and added Kotlin 2.4.20 support, along with new or improved queries across C/C++, C#, and GitHub Actions. In parallel, GitHub deprecated the all-platform CodeQL bundle starting with CodeQL CLI 2.27.0, with removal planned for mid-March 2027, which means you should update any automation that downloads a single bundle for all runners and instead pull platform-specific artifacts (including Linux ARM64). Treat both as “pipeline hygiene” work: update versions, validate results, and confirm that scanning remains consistent across your supported languages and runner architectures.

Secure-by-default infrastructure for running agents and untrusted workloads

This week had a cluster of releases and guides focused on running untrusted code and agent workloads with stronger isolation and policy controls, expanding on last week's agent governance theme by showing the runtime substrates (microVMs, pod sandboxes, confidential containers) that make those policies enforceable. The direction is consistent: isolate execution with microVMs or pod sandboxes, restrict egress by policy, and make identity and attestation part of the platform layer rather than an application afterthought.

Azure Container Apps Sandboxes reached general availability, providing hardware-isolated microVM sandboxes for untrusted code and agent workloads with per-sandbox egress controls, private networking, snapshots, volumes, and opt-in telemetry export (OTLP) to Azure monitoring destinations. If you are currently running “tool execution” inside long-lived containers, the microVM boundary is a clear upgrade for containment and incident response, especially when combined with tight outbound policies. The GA announcement notes infrastructure-as-code support through Bicep and Terraform (ACA provider), which matters if you want the isolation guarantees to be reproducible across environments.

AKS updates leaned into similar ideas for AI-heavy clusters, including pod sandboxing with Kata Containers and confidential GPU support (AMD SEV-SNP plus NVIDIA H100). On the bursty compute front, next-generation AKS virtual nodes on Azure Container Instances (ACI) position ACI as a serverless layer that still fits standard kubectl and Helm workflows, and the guide shows how to enable confidential containers using confcom to generate CCE policies (Rego) and use hardware-backed attestation (SEV-SNP). For security teams, the interesting part is that you can combine “burst compute” with “measurable isolation” instead of treating burst capacity as an exception to your runtime policies.

Data retention and deletion safety: when “immutability” blocks cleanup

Azure Blob Storage immutability (WORM) can quietly turn routine cleanup into an operational outage, and a troubleshooting post walked through why accounts and containers become undeletable after enabling immutability features, which pairs well with last week's resilience focus by highlighting a failure mode that can block recovery, teardown, and cost control when you most need clean reversibility. The details matter: locked vs unlocked policies behave differently, legal holds can prevent deletion even when you think you disabled the policy, and hidden blob versions can keep storage around unexpectedly. The post also highlights how version retention setting changes trigger Lifecycle Management cleanup, so “I changed the setting” is not the same as “the data is gone.”

For platform operators, the practical value is the deletion/cleanup checklist that ties controls back to observable state: verify immutability policy state, check for legal holds, enumerate versions/snapshots, and confirm lifecycle rules that will actually delete old versions. If you use ImmutableStorageWithVersioning, build a runbook that includes version inventory and lifecycle timing, otherwise you will end up with surprise retention costs and blocked deprovisioning during incident response or environment teardown.

Other Security News

Microsoft Defender outlined an Integrated Security Operations Center (ISOC) preview as a unified SecOps foundation that combines SIEM and threat protection into an “integrated protection loop” (shared signals, context, and actuators). In the same week, the broader “What's new in Microsoft Security: September 2026” roundup called out investigation improvements with Microsoft Security Copilot and new Purview and Entra Global Secure Access controls aimed at stopping sensitive data from reaching shadow AI, plus eDiscovery and retention/cleanup updates.

GitHub Enterprise added credential inventory exports (UI and paginated REST API) so enterprises can pull a complete list of keys and tokens with metadata and filtering, then correlate it with audit log activity for incident response, echoing last week's theme of making controls enforceable and auditable across identity and supply chain surfaces. On the Microsoft Fabric side, the on-premises data gateway September 2026 release (v3000.334) added Soft Delete recovery and shipped security updates including Log4j 2.26.1 and a fix for CVE-2026-18401, making it a sensible upgrade if you run gateways in controlled networks.

Developers working on session security also got a preview-era option in ASP.NET Core: experimental Device Bound Session Credentials (DBSC) support in .NET 11 preview, including enablement for cookie auth and ASP.NET Core Identity. The goal is to bind sessions more tightly to a device and reduce replay value of stolen cookies, though the feature is still experimental and will require careful rollout and compatibility testing.