Look out for Hexmasks and the Locked Room in the Labyrinth of Kindo'jan, which can give you bonus power and rewards!Labyrinth of Kindo'jan

Random Rooms

In the Labyrinth of Kindo'jan, five locations are designated as special spawn locations. Once you reach Rank 2 of the Labyrinth journey, each run randomly selects three of these spawns for Hexmasks and one for the special locked room. The final room will contain nothing.

Hexmask/Locked room spawn 1
Hexmask/Locked room spawn 2
Hexmask/Locked room spawn 3
Hexmask/Locked room spawn 4
Hexmask/Locked room spawn 5

/way #2647 50.3 82.6 Possible Hexmask/Locked room spawn (Chamber of Rites)
/way #2647 88.5 51.5 Possible Hexmask/Locked room spawn (The Cave Towers)
/way #2647 56.8 17.8 Possible Hexmask/Locked room spawn (Akil'zon's Roost)
/way #2647 18.8 18.2 Possible Hexmask/Locked room spawn (Jan'alai's Refuge)
/way #2647 58.5 21.7 Possible Hexmask/Locked room spawn (Nalorakk's Rest)

Hexmasks

Three Hexmasks are hidden in the Labyrinth of Kindo'jan and each deals damage differently. If you collect all three in the same run, you get the Happy Hexmask Collector achievement.

Frozen Hexmask — Frost Nova

Fiery Hexmask — Burning Gaze of Ula'tek

Thundering Hexmask — Chain Lightning

If you want some extra friends to deal some extra damage, make sure to check out these areas while you're clearing each chamber.

Locked Room

One of the random rooms will have a locked door, indicated by a key. You'll have to find the Archaic Amani Key, which drops from the Keeper of the Key. This NPC is found somewhere in the Labyrinth and you may find the door before you find the key holder.

Once you find the Keeper of the Key, it shouldn't prove much of a threat. Make sure to loot the bag on the floor to get the key and head back to the door. The secret room contains Chests for some reputation and Mislaid Curiosities for extra stats. You'll want to get used to looking for this room, since Lock and Key Master requires 20 separate runs to complete!

Across my conversations with leaders in government, critical infrastructure and regulated industries, one priority consistently rises to the top: putting technology to work on their most important systems while maintaining the control those systems require.

This challenge is becoming more important as advanced cloud and AI capabilities move into public services, regulated processes and essential operations. Organizations are considering more than where data resides. They also seek to understand who can access and operate their systems, how sensitive digital assets remain protected, which technology dependencies matter most and whether critical services can continue as regulatory, geopolitical, security or network conditions change. Digital sovereignty should give organizations greater control and security over the technology they depend on, while continuing to innovate.

Last year, we introduced Microsoft Sovereign Cloud to give customers more choice in how they address these requirements. Since then, we have continued to turn our commitments into practical capabilities across public cloud and customer-operated environments, while expanding how we enable partners to address sovereignty requirements in their local markets. Today, we are sharing the next stage of that work.

A continuum of control, built around the workload







Our approach to digital sovereignty starts with the workload. Each workload carries different requirements for data, operations, technology dependencies, continuity and risk. Microsoft Sovereign Cloud is designed to make it easier for organizations to apply the appropriate level of control to each workload without forcing every application into the same deployment model.

Those needs can vary widely across organizations. A public-facing digital service may benefit from the scale and pace of innovation in the public cloud. A system supporting essential operations may need to continue running locally if connectivity is disrupted. An AI workload handling highly sensitive data may require models, data and processing to remain within a customer-controlled environment.

Microsoft Sovereign Cloud is designed around this workload-based approach, providing a continuum of management, control and options across Sovereign Public Cloud, Sovereign Private Cloud and the Sovereign Partner Ecosystem. Organizations can apply the level of control appropriate to each workload while maintaining a consistent approach to governance and operations across their digital estate. Sovereign Public Cloud adds capabilities for workloads that require greater control and transparency while continuing to benefit from the scale and innovation of Azure.

Sovereign Private Cloud extends cloud capabilities into customer-operated environments, including connected and disconnected operations. The Sovereign Partner Ecosystem broadens the continuum through independently operated environments, specialized partners, locally relevant expertise and technologies that support customers’ sovereignty requirements.

These are not isolated destinations. Customers can combine public cloud, private cloud and partner capabilities across their digital estate, applying different levels of control to different workloads as their operating needs evolve.

Making control more visible in Sovereign Public Cloud

For many workloads, the public cloud provides a combination of scale, innovation, integrated security and compliance. Organizations can benefit from these capabilities while applying additional sovereignty controls for residency, confidentiality, operator access, policy and continuity. Our work in Sovereign Public Cloud makes these controls easier to understand, apply and demonstrate.

Sovereign Control Panel, entering public preview at Microsoft Ignite, brings these signals together in a unified Azure portal experience. It helps organizations understand their sovereignty posture, apply and manage controls, identify gaps and risks and take action to address them. It also supports business continuity readiness by helping customers understand workload dependencies and assess portability across operating environments when required.

This visibility complements controls across the operator-access lifecycle. Just-in-time Access and Customer Lockbox give customers additional control over access to their environments. For customers in the European Union (EU) and the European Free Trade Association (EFTA), we are rolling out Data Guardian, which adds European-resident oversight by a trusted EU partner for qualifying Microsoft engineer remote access to in-scope production systems. Production Touch Ledger, also launched with phased rollout in the EU and EFTA, creates tamper-evident records of that access and the actions performed.

Azure Key Vault Managed Hardware Security Module (HSM) already gives customers dedicated, single-tenant protection and control over the encryption keys used by supported Azure services. Last year, we committed to extending that control beyond Microsoft infrastructure. External key management with Azure Managed HSM is now generally available, allowing customers to keep the root encryption key in hardware they own and operate on-premises or through a trusted third party. This gives organizations another option for workloads that require physical control of key hardware outside Microsoft infrastructure.

Azure confidential computing helps protect supported data while it is processed in a hardware-based and attested trusted execution environment. We are also increasing transparency into the technologies that underpin that trust. Azure Confidential Clean Rooms, now in limited preview, applies confidential computing to approved multiparty collaboration, allowing participants to analyze shared sensitive data while limiting broader exposure of the underlying information.

Together, these capabilities provide additional technical and operational controls that can support a broader digital sovereignty strategy aligned to an organization’s legal, policy, security, resilience and business requirements.

Designing for resilience and operational independence

For some workloads, digital sovereignty also means maintaining critical operations as connectivity, geopolitical and operating conditions change. Resilience must be designed from the start so essential workloads can continue operating through disruption.

To help customers prepare for these scenarios, we are publishing new sovereign business continuity guidance and architecture patterns. These resources help organizations translate resilience requirements into architectures they can plan, implement and test before they are needed.

For many workloads, the scale and geographic reach of the public cloud provide a strong foundation for resilience across locations and operating conditions. For workloads that require greater operational independence, Sovereign Private Cloud extends that continuum into customer-operated environments. It supports connected and disconnected operating models. The ability to transition workloads from connected to disconnected operations is entering public preview, giving organizations greater flexibility to sustain critical services as connectivity and operating requirements change.

Bringing more of the application lifecycle under local control

Operational independence requires more than infrastructure. Increasingly, organizations need data, development tools, model capabilities and productivity services their applications depend on to operate within the same customer-controlled environment.

Sovereign Private Cloud, built on Azure Local, extends Microsoft cloud capabilities into environments that customers operate and control. SQL Server on Azure Local is already generally available for connected and disconnected deployments. DocumentDB and Blob Storage on Azure Local are both entering public preview, giving organizations more choice in how they run and manage critical data within customer-controlled environments.

GitHub Enterprise Local will become generally available at Microsoft Ignite as a validated GitHub Enterprise Server appliance on Azure Local, helping organizations keep repositories, code and development artifacts under local control. Developers can also use GitHub Copilot with locally hosted models for inference, bringing AI-assisted development closer to their code and data within the environments they control.

The local application environment is expanding with Foundry Local. At Ignite, Foundry Local will become generally available for connected and disconnected operations on Azure Local, with an expanded model catalog that includes Microsoft, partner, open-weight and open-source models. Local inference and agentic retrieval will also enable users to interact with local enterprise data using natural language and receive responses grounded in that data. Integration with Microsoft 365 Local, available in preview for approved customers, extends this functionality to locally operated Microsoft SharePoint and Exchange servers.

Confidential virtual machines on Azure Local are generally available, extending confidential computing capabilities to customer-controlled infrastructure. Hardware-encrypted memory and hardware-based isolation help protect sensitive data while it is being processed. Workload attestation adds assurance before sensitive data or keys are released. For regulated, sensitive and mission-critical workloads, these safeguards provide another layer of protection while giving organizations greater control over where their data and applications run.

Azure Local will support multitenancy, allowing organizations to separate resources, governance and management across multiple tenants while sharing the underlying infrastructure. This significantly expands what customers with distinct business units or security boundaries can achieve with Sovereign Private Cloud. Multitenancy also creates new opportunities for local operators and service providers to deliver differentiated sovereign cloud services on Azure Local infrastructure.

These additions bring more of the application lifecycle under local control, spanning data, development, productivity, AI and operations. Organizations can determine what runs locally based on the requirements of each workload.

Extending the continuum through partners







Navigating sovereignty is increasingly complex. Regulatory, security, operational and business requirements vary across countries, industries and workloads. Organizations must translate these needs into technology and operating models that work in their local context. Meeting these needs often requires a combination of technology, local operating authority, sector expertise and specialized solutions.

The Sovereign Partner Ecosystem broadens the ways customers can address these requirements. National Partner Clouds, including Bleu in France, provide independently operated environments for customers that require a different ownership and operating model. Software partners can enhance Azure Local environments with capabilities across security, identity, observability, backup and recovery, migration, data, networking and applications. Digital sovereignty specialized partners combine Microsoft technologies with local knowledge and implementation expertise. Platform co-innovation partners expand infrastructure choice from datacenter to the edge.

This ecosystem gives customers the flexibility to combine technology, operating models and trusted expertise based on the requirements of each workload.

The next chapter of digital sovereignty

AI is amplifying both the opportunity and the impact of technology choices. As AI systems and agents interact with sensitive data, business processes and essential infrastructure, they also expand the security considerations organizations need to manage. Organizations need clear control over where these systems run, who can operate them, what actions they can take and how critical services continue when conditions change.

Microsoft Sovereign Cloud brings these choices together as a continuum of control across the public cloud, customer-operated environments and our partner ecosystem. It gives organizations the flexibility to apply the appropriate level of control to each workload while continuing to benefit from cloud capabilities and ongoing innovation.

We will continue to expand this continuum so organizations can innovate with cloud and AI while maintaining the control, confidentiality, resilience and operational authority their most important workloads require.

Douglas Phillips leads global engineering efforts for Microsoft’s specialized, sovereign and private clouds. He is responsible for Microsoft’s global strategy, products and operations that bring Microsoft’s industry-leading solutions, including Azure, our adaptive cloud portfolio and Microsoft 365 collaboration suite, to customers with additional sovereignty, security, edge and compliance requirements.

Learn more

• Microsoft Sovereign Cloud
  
  
• Sovereign Landing Zone architecture guidance
  
  
• Sovereign Public Cloud Tech Community blog
  
  
• Sovereign Private Cloud Tech Community blog
  
  

The post Advancing digital sovereignty with greater control and choice appeared first on The Official Microsoft Blog.

When making your way through the Labyrinth of Kindo'jan, make sure to loot Mislaid Curiosities to stack up some massive stat buffs!Labyrinth of Kindo'janSeason 2 Delves Guide

Mislaid Curiosities

Mislaid Curiosities are scattered in Midnight Delves, granting Valeera experience and temporary stat buffs. These buffs last for the remainder of the Delve, which isn't very long for a normal Delve. However, for the Labyrinth of Kindo'jan, these stat buffs last for the entire run, meaning you can stack these stat buffs up massively and use them to your advantage against the Nemesis boss, Kindo'jan.

You can get eight different buffs from Mislaid Curiosities. Each one you loot will increase one or two stats:

Maximum Health

Movement Speed

Primary Stat

Haste

Critical Strike

Mastery

Versatility

Damage Reduction

By the time you reach Kindo'jan, you can stack up a lot of bonus stats and become super powerful. This can trivialize Kindo'jan and help you kill him very quickly, maybe even before he enters Phase 2. The bonus movement speed also helps you dodge some of his mechanics more easily, such as the De Rising Storm ability.

Your existing .NET MAUI app builds with Xcode 27, installs on an iPhone running iOS 27, shows its splash screen, and then disappears. Not exactly the grand entrance you were hoping for.

That symptom can have many causes. But if the only thing that changed is that you’re now building with Xcode 27 and running the app on iOS 27, and you see the device log message below, your .NET MAUI app needs a few changes:


UIKit’s scene lifecycle manages each instance of an app’s user interface, including its windows and transitions between foreground and background states. It works alongside the application lifecycle, which manages the app process as a whole. Apple introduced this model with iOS 13, and .NET MAUI already supports it.

This is an Xcode 27 compatibility requirement, not a broken .NET MAUI lifecycle. Existing .NET MAUI projects might still use only the older application lifecycle because updating .NET MAUI or its workloads doesn’t rewrite their platform files. It’s not specific to the iPhone Duo. Every iOS app built with Xcode 27, on any form factor, needs to adopt this pattern. An existing binary built with an older SDK doesn’t suddenly need this migration just because someone updates their phone.

For a straightforward app, the change is small: a scene delegate and an entry. The part that deserves your attention is everything you’ve added over the years, such as authentication callbacks, deep links, and App Actions.

That’s where the agent skill comes in. It guides your coding agent through the project checks, the migration, and the verification. You still review the changes, and the manual steps below explain what it’s doing.

Let an AI agent handle the migration

The .NET MAUI CLI can install agent skills into your development environment. A skill is a set of instructions and supporting resources for the agent. It’s not another runtime dependency in your app.

The Xcode 27 migration skill requires Microsoft.Maui.Cli 0.1.0-preview.13.26512.5 or later. Install that preview release:


If you already have it installed, update it instead:


Preview tooling

The .NET MAUI CLI and this skill are experimental and are not covered by the Microsoft Support Policy. The CLI downloads the skill from the public catalog, so catalog discovery and installation require network access.

From your app’s repository, check that the CLI can find the skill and install it for GitHub Copilot CLI:


If you use another AI provider, check and change the option accordingly. Run the command from the app repository you want to change, because the skill is installed for that project.

Restart or reload your agent session so it picks up the new skill, then ask:


You don’t need to name the skill in your request. A compatible agent should pick from the installed skills based on the task. If you want to remove any doubt, feel free to name it explicitly.

The CLI installs the skill, and your coding agent does the migration. There’s no command in this workflow, and installing the skill on its own doesn’t touch your app.

Prefer to manage the skill directly with GitHub Copilot CLI? Follow the official GitHub Copilot plugin installation documentation, then add the marketplace and install the plugin:


You can also find the migration skill directly in the

Code:

dotnet/maui-labs

repository. Pick one installation method so you don’t end up with duplicate copies.

What the skill checks

Before editing anything, the skill should work out which project, .NET SDK, .NET MAUI packages, Apple workloads, and Xcode version you’re actually using. A , shared package versions, or an existing custom scene delegate can all change the right approach.

The migration covers:

• Compatible versions. Match the Apple workload to Xcode, update the required .NET MAUI packages, and check deployment targets without silently dropping older OS support.
  
  
• Scene configuration. Add or reconcile the delegate and manifest for the iOS and Mac Catalyst targets, including configuration-specific plist files. Preserve existing scene customizations, launch-screen settings, and multi-window behavior.
  
  
• Custom behavior. Review app-delegate overrides as well as lifecycle registrations, authentication, warm and cold links, notification taps, startup work that needs a window, and App Actions.
  
  
• Verification. Run a read-only lifecycle audit, review the diff, build the affected targets, and test launch and the behaviors the migration can change. Report anything that could not be exercised.
  
  

Commit or otherwise save your current work before starting, and go through the resulting diff before accepting it. A successful build doesn’t prove that an authentication redirect or a Home screen shortcut still works.

If you’d rather do things by hand, the instructions are below.

Before you start: check your app and toolchain

Scene lifecycle support was available before Xcode 27, so your app might already use it. If you already have a and matching scene manifest, good news: you can skip the migration steps below. You should still check the toolchain versions and test your app on iOS 27.

At the time of writing, the released .NET 10 iOS and Mac Catalyst workloads 27.0.10722 require Xcode 27.0. Installing a newer Xcode doesn’t automatically make it compatible with that workload. Check the .NET for iOS and Mac Catalyst release notes and use the matching versions rather than disabling the SDK’s Xcode check.

Check your setup

Run for a quick check of your active .NET SDK, .NET MAUI workload, selected Xcode, and Apple SDK compatibility. It also checks supporting components such as the Xcode license, command-line tools, and installed iOS runtimes.

For a .NET 10 app, update your .NET MAUI packages to 10.0.110 or higher before enabling scenes. The two-file launch fix can work with an older .NET MAUI version because already exists there. However, 10.0.110 also includes the scene-side App Actions dispatch and relevant forwarding. Treat the package update as part of the migration, otherwise you might fix the launch and silently break those integrations.

Template projects often get from the installed workload. To pin the minimum version explicitly, add this to your :


If you already manage this version elsewhere, update that value instead. Don’t downgrade a newer compatible version.

Apps created with the .NET MAUI 10.0.110 templates already have the scene configuration. Existing projects aren’t retrofitted by a package or workload update, so you’ll need to do that part yourself.

Add the scene delegate

In your existing app, create and paste in this code. If the file already exists, check its base class and registration instead of adding a second delegate:


Replace with your app’s namespace. For this default setup, keep the class public and the registration name as . If your app already has a custom registered scene delegate, preserve its behavior and use its registered name consistently in the manifest instead of adding a competing delegate.

Yes, that’s the whole class. .NET MAUI does the actual window setup for you. Leave your existing exactly where it is too. The scene delegate works alongside it, not instead of it.

Add the scene manifest

Open as XML and add the following inside the root . If you already have a , update its existing scene configuration instead of adding a duplicate key:


Three details matter here:

• Keep
  Code:

  __MAUI_DEFAULT_SCENE_CONFIGURATION__
  exactly as shown. That’s the name .NET MAUI expects.
  
  
• Match the delegate name in the plist with the C# registration:
  Code:

  SceneDelegate
  and
  Code:

  [Register("SceneDelegate")]
  in this example.
  
  
• Leave
  Code:

  UIApplicationSupportsMultipleScenes
  set to
  Code:

  false
  unless your app really supports multiple windows.
  
  

You don’t need a . .NET MAUI creates the window in code, and your existing splash screen configuration stays as it is.

If you have custom scene configuration names or override or , review them together rather than replacing the manifest wholesale. The default window-creation path expects ; a different name needs an existing custom implementation that handles window creation.

Some apps select a different plist for Debug, Release, customer, or environment builds. Add or reconcile the manifest in every plist that can produce a shipping app. If you only update the default file, one configuration can still crash right after the splash screen. Preserve the existing or setup while editing these files.

That’s the iOS scene configuration done. If you don’t target Mac Catalyst, skip ahead to the minimum OS versions.

Do the same for Mac Catalyst

If your project also targets Mac Catalyst, make the same two changes there:

1. Add
   Code:

   Platforms/MacCatalyst/SceneDelegate.cs
   .
   
   
2. Add the same
   Code:

   UIApplicationSceneManifest
   section to
   Code:

   Platforms/MacCatalyst/Info.plist
   .
   
   

Check your minimum OS versions

The .NET for iOS and .NET for Mac Catalyst 27 SDKs also raise the minimum supported versions: iOS needs at least , and Mac Catalyst needs at least (macOS 14 Sonoma). In your app’s , update the existing entries if yours are lower:


These entries belong inside a . Replace the existing values instead of adding duplicates, because a later definition can override your change. Keep each version directly between its XML tags, without leading or trailing whitespace.

Keep a higher deployment target if your app already requires one. If you must retain support for iOS versions below 15 or macOS 12 and 13, moving to these SDKs requires a support-policy decision. Stay on a compatible 26.x SDK while you decide, rather than silently dropping those users. This SDK minimum is separate from scene adoption; see the .NET MAUI template deployment-target guidance.

Check any custom app behavior

With scenes enabled, UIKit no longer calls the activation, backgrounding, URL, and user-activity callbacks. That goes for both registrations and methods you override in , such as or . Move that logic to the corresponding scene events:

Existing event
Scene event













The callback arguments differ, so move the logic instead of just renaming the registration. If you instead override methods in your , call the corresponding implementation. The framework’s window setup, lifecycle events, and authentication forwarding depend on that behavior.

For custom deep links, also handle : URLs and user activities that launch the app arrive in its . That callback runs before .NET MAUI creates the window, so defer navigation until the window is ready.

If your app opens content from a notification tap, inspect as another cold-start input. Preserve that route separately from ordinary push registration and , which remain application-level callbacks.

A regular launch may have no URL or user-activity payload. Guard against absent and before enumerating them, even when the binding’s nullability annotation suggests a value will be there.

still runs, but the standard .NET MAUI scene path creates the window later through the scene delegate. stays . Code that accesses it after needs to use the appropriate scene window when it is ready instead. The cross-platform lifecycle events keep working; do not duplicate that forwarding.

.NET MAUI 10.0.110 handles scene-based App Actions and forwards the relevant URL and user-activity callbacks to . That authentication handling is not general app deep-link navigation and does not replay cold-start links for you. Test authentication and your own links with the app both running and fully closed.

If you use App Actions, make sure every custom handler calls its completion callback exactly once. Pass when the action was handled and when it was not. A handler can respond asynchronously after returning, but returning alone does not acknowledge the action.

Even a handler that only writes a log message needs to respond. As an example, add to , then register this observer inside , before :


The default .NET MAUI builder already forwards App Actions to Essentials. You don’t need this logging observer unless you want it, and you shouldn’t add another registration. If your overrides , that override is no longer called with scenes enabled. Move its custom logic into a registration like the one above, completion callback included.

Rebuild and try it

Restore and build the iOS target:


If the simulator still seems to have an old version of your app, uninstall it, delete the app project’s and folders, and run those two commands again.

Launch both Debug and Release builds on a regular iPhone or iPad simulator running iOS 27 with the matching workload and Xcode. A successful build or launch on iOS 26 doesn’t prove that the app will launch on iOS 27 when built with Xcode 27. Check a cold launch, background and foreground transitions, your authentication flow, links and notification taps with the app both running and closed, and App Actions. If you target Mac Catalyst, build and exercise that target too.

You don’t need an iPhone Duo simulator to verify this migration. Device-specific layouts and the Xcode 27.1 tooling are a separate topic that we’ll cover in a follow-up post soon.

The post Get Your .NET MAUI App Ready for Xcode 27 appeared first on .NET Blog.

Mike Nelson, XBOX Wire Editor


October 19, 2026 · 1 min read


[/url]










Filed under


[url=https://news.xbox.com/en-us/games/]Games



Keep reading

All stories→






Opens in a new tab
Spotlight

Spotlight · Explore
Modern Warfare 4: Campaign Early Access Now Live




Opens in a new tab
Spotlight

Spotlight · Explore
DMZ Early Access Starts October 20




Opens in a new tab
Spotlight

Spotlight · Explore
Modern Warfare 4 Launches October 23 as a Standalone Release

Mike Nelson, XBOX Wire Editor


October 19, 2026 · 1 min read


[/url]










Filed under


[url=https://news.xbox.com/en-us/great-games/]Great Games
Call of Duty: Modern Warfare 4



Keep reading

All stories→






Read

Great Games · Great Games
Tenebris Somnia: Blood, Pixels, and Prosthetics




Read

Great Games · Great Games
Celebrating the Next Generation of Latin American Game Creators




Read

Great Games · Great Games
Next Week on XBOX: New Games for October 19 to 23

Blizzard has posted hotfixes for today, which includes many Labyrinth bug fixes!Many players had issues with Labyrinth runs ending up in an uncompletable state. This has now been fixed according to the hotfixes.

Hotfixes
October 14, 2026

Aqir Invasions

Fixed an issue where the final boss of the invasion was not properly randomizing between the three different types.

Classes

Druid

Guardian

Fixed an issue causing Rebirth in Bear Form to have an incorrect mana cost.

Fixed an issue preventing the Bear Form version of Heart of the Wild from being cast.

Fixed an issue causing Persistence to grant an incorrect amount of armor.

Restoration

Fixed an issue where Nature’s Bounty could cause Abundance to fall off the Druid early.

Delves

Dundun has returned and hides within Bountiful delves once again. May you revel in his radiant prosperity!

Labyrinth

Fixed an issue where the kill credit for a boss may not register if it was the second time the boss had to be defeated in the same Labyrinth run.

Fixed an issue where the Kindo’jan encounter would fail to successfully complete when Kindo’jan reached 1 health.

Fixed an issue in the “Returning the Bounty” scenario that could sometimes prevent the initial bag interaction from being completable.

Fixed an issue in the “Returning the Bounty” scenario where Hording Looters could sometimes stop spawning.

Fixed an issue where Ancient Hash’ey Battle Arts enchantment effects can trigger outside of delves and The Labyrinth of Kindo’jan.

Increased the maximum item level for the Ancient Hash’ey Battle Art enchantment to 344 (was 334).

Players can no longer cleanse Cursed Energy in the “Fools and Curses” scenario.

Enemies in Halazzi’s Lair no longer spawn within the walls.

Characters can no longer fall through the terrain when respawning in Nalorakk’s Rest.

Quests

Ancient Foes in the Vaults of Atal’Utek will now properly reward Primordial Venom Motes to players who defeat them while in raid groups.

Fixed issue where NPCs in Amani’Zar Village weren’t visible during the quest “De Legend of de Hash’ey”.

Hi,

I know, I keep coming back to the same theme on this blog: agent harnesses. In Build Your Own AI Agent Harness in C# we built one from scratch. In From dotnet run to Foundry Hosted Agent in 3 lines of C# we took an agent and hosted it. Today we use a harness we do not have to build at all: the one GitHub already ships, through the GitHub Copilot SDK.

One of the most popular questions we received during the Let’s Learn GitHub Copilot SDK sessions was:

Quote:“Can I use the Copilot SDK with my own model deployment?”

The short answer is yes.

The longer answer is, the GitHub Copilot SDK gives your application the Copilot agent runtime, while lets you route model inference to a provider you control. That provider can be any of the providers officially supported by the Copilot SDK: OpenAI, Anthropic, Ollama, Microsoft Foundry Local, or any OpenAI-compatible endpoint such as vLLM or LiteLLM. Today’s sample uses Microsoft Foundry, authenticated with Microsoft Entra ID or, when needed, an API key.

The complete sample is now part of Generative AI for Beginners .NET. It is a small .NET 10 console application: read configuration, create a BYOK provider, start the Copilot runtime, create one session, and ask one question.

Get the complete BYOK C# sample

What BYOK means in this sample

BYOK means Bring Your Own Key, but in this context the important idea is broader than the key itself: you bring your own model provider.

The Copilot SDK still supplies the runtime that manages the client, session, system message, and agent configuration. changes the destination and authentication for model inference.

BYOK is not customer-managed encryption keys

In this article, BYOK means using your own model endpoint and credentials for inference. It does not refer to customer-managed encryption keys or a storage-encryption configuration.

The sample intentionally keeps the session minimal. It disables tools, skills, configuration discovery, and host Git operations so that the first run demonstrates one thing clearly: a Copilot SDK session can send a model request to your own Foundry-compatible deployment.



The runtime and the model provider are separate parts of the application.

The project

The sample is a regular .NET 10 console application. These are the packages it uses:


provides the .NET client for the Copilot runtime. provides , which lets the sample reuse the identity from . The configuration packages load development-only secrets without putting endpoints or credentials in source control.

Step 1: read the model configuration

The sample uses the shared User Secrets values already used by the repository:


There are two required values:

• Code:

  AzureOpenAI:Deployment
  is the name of your model deployment in Microsoft Foundry or Azure OpenAI. Choose a deployment that supports the Responses API, because this sample uses
  Code:

  WireApi = "responses"
  .
  
  
• Code:

  AzureOpenAI:Endpoint
  is the Foundry or Azure OpenAI resource endpoint.
  
  

is optional. If it is not present, the sample uses Microsoft Entra ID through . If it is present, the sample sends it in the header.

Step 2: configure the provider

This is the core of the sample:


The configuration tells the Copilot runtime how to communicate with the provider:

• Code:

  Type = "openai"
  selects the OpenAI-compatible provider shape.
  
  
• Code:

  BaseUrl
  points to the OpenAI-compatible API surface.
  
  
• Code:

  WireApi = "responses"
  selects the Responses API.
  
  
• Code:

  ModelId
  identifies the model to the Copilot runtime.
  
  
• Code:

  WireModel
  is the model name sent to the provider.
  
  
• The token limits keep this small example bounded.
  
  

For a reasoning model, includes reasoning tokens as well as the visible answer. The 512-token limit can be reached before the model produces any answer. Increase or omit the override when using a reasoning deployment, then tune the limit for your workload.

In this sample, and have the same value. They are separate properties because the runtime-facing model identifier and the provider-facing model name do not have to be identical in every integration.

The endpoint helper accepts either the resource URL or a URL that already includes :


The helper also requires HTTPS. It is better to reject a malformed endpoint before creating a session than to discover it after the first model request.

Step 3: use Entra ID by default

The default authentication path uses the Azure CLI login:


Before signing in, make sure your identity has the Cognitive Services OpenAI User role on the resource. Then run:


is a callback. The SDK can call it when it needs a token instead of receiving one token value that the application has to manage itself.

Step 4: use an API key when one is configured

Some deployments or environments still require an API key. The sample supports that path without changing the rest of the provider configuration:


Set the optional secret:


When the value exists, the sample uses the header and does not require . The console output reports only the authentication mode; it never prints the endpoint or the credential.

Keep credentials out of source control

Use User Secrets for local development, environment-managed configuration for deployed applications, and never paste an API key into the source file or a README.

Step 5: start the Copilot runtime

The provider controls model inference, but the Copilot runtime is still required:


This is an important distinction. BYOK does not mean “the Copilot SDK without Copilot.” The local Copilot CLI runtime still provides the orchestration process. BYOK changes where the model request goes.

Prerequisites

Install the .NET 10 SDK and the GitHub Copilot CLI, and make sure reports a .NET 10 SDK and works. For the default Microsoft Entra ID authentication path, also install the Azure CLI and make sure works. The API-key path does not require the Azure CLI. The sample starts the local Copilot runtime through .

Step 6: create a deliberately small session

The session configuration connects the model name and provider, then disables capabilities that are outside the scope of this first example:


The empty tool collections and disabled features are intentional. They make the sample easier to reason about and safer to run while learning the provider configuration.

The system message also makes the output predictable for a multilingual live-learning sample. replaces the default system message instead of appending another instruction to it.

Step 7: send one question

Finally, the application sends one prompt and waits for the final response:


The default question is:


You can provide another question as command-line arguments:


Run the sample

From the sample directory, configure the required values:


Then use the default Entra ID path:


The output looks like this:


The sample prints the selected model and authentication mode, but not the endpoint or credentials.

So, what did we actually learn here?

Honestly, the part I like most is how little code this takes.



The Copilot SDK runtime and the model provider are two different things, and once that clicks, the rest is easy. You keep the runtime that GitHub gives you: the client, the session, the system message, and the agent plumbing. Then you just point inference somewhere else. That “somewhere else” is your Foundry deployment, your OpenAI key, your local Ollama, whatever you need.

Entra ID is the default path here, and I think it should be. No key to rotate, no key to leak, no key to accidentally commit. and you are done. The API key branch is there for the cases where you really need it, and it stays out of the way until you configure it.

And the session is deliberately boring. No tools, no skills, no MCP, no Git access. That is on purpose: the first run has exactly one job, which is proving that your model is answering. Once you see that answer in the console, you have a working baseline.

That is the fun part. From here you can start adding things one at a time: tools, MCP servers, skills, approvals, and streaming. When something breaks, you will know exactly which piece broke it.

Go try it with your own deployment.



Learn more

• GitHubCopilotSDK-01-BYOK sample
  
  
• Generative AI for Beginners .NET
  
  
• GitHub Copilot SDK
  
  
• Let’s Learn .NET
  
  
• Let’s Learn .NET event page
  
  
• Building Agentic AI Apps with GitHub Copilot SDK (Coursera Professional Certificate)
  
  
• Microsoft Foundry
  
  

Explore the complete GitHub Copilot SDK sample

Happy coding!

Bruno

The post Bring Your Own Model to the GitHub Copilot SDK with C# appeared first on .NET Blog.

The first Beta release of Godot 4.8 has arrived and it’s jam packed with features and improvements. This *should* be the feature complete version of what should ship with Godot 4.8, with the current feature set frozen. This is of course a beta, so shouldn’t be used in production environments.

Highlight features of Godot 4.8 include:

Here is the updated summary with the UI improvements consolidated into the top bullet:

• Massive Editor UI Improvements: The biggest highlight of this release is a comprehensive overhaul of editor UI features. The game view is now embedded into the main editor window by default, alongside main screen editors that have been converted into regular, undockable, and closable windows. Furthermore, quality-of-life enhancements like zoomable resource thumbnails, improved drag and drop indication and new hover visibility toggles in the scene tree make managing complex projects incredibly fast.
  
  
• Trail3D for VFX: A highly requested native 3D trail node has been added to make creating stunning visual effects accessible without requiring deep math knowledge. It provides an out-of-the-box solution that just works (It really is stupidly easy to use).
  
  
• Mip-level Texture Streaming: You can now dynamically load and unload images based on a camera’s relative position. This improves rendering performance and manages memory more effectively in larger scenes. While not quite texture streaming, it should greatly improve performance on texture dense games like open worlds.
  
  
• Focused GDScript Underlines & Refactoring: The editor now features focused in-editor underlines specifically designed to highlight GDScript warnings and errors without cluttering the screen. It also improves syntax highlighting performance and introduces powerful new GDScript refactoring capabilities.
  
  
• CanvasItem Game View Manipulation: You can now directly move, resize, rotate, and scale CanvasItems of your running game within the game view using a dedicated toolbar. It also supports full undo/redo and opening scenes via double-clicking.
  
  
• VisualShader Node Groups: To reduce bloat in complex shader graphs, you can now encapsulate frequently-used sections into reusable node groups. This cleans up messy boilerplate and makes shader development much more organized.
  
  
• Auto-Resizing UI Fonts: Labels and RichTextLabels now include properties for auto, minimum, and maximum font sizing. This automatically adjusts in-game text to fit constraints..
  
  
• Screen Space Contact Shadows: A new rendering feature creates an R8 shadow texture for each directional light and blends them with shadow maps. This delivers highly performant shadows without compromising visual quality.
  
  
• Built-in Android SDK Manager: The editor can now automatically download, set up, and manage the Android and Java SDKs with the click of a button. This dramatically streamlines the mobile export process.
  
  
• TextEdit & CodeEdit Touch Support: The script editors received major touch input upgrades, including tap-to-place cursor, drag-to-scroll, and double-tap for text selection. The code completion popup can now also be scrolled via touch.
  
  
• Core Engine Optimizations: Runtime RAM usage has been reduced by ~12mb by simplifying GDType, and object property access was accelerated by 1.6x. Removing many child nodes simultaneously is also noticeably faster.
  
  

Key Links

Godot Homepage

Godot 4.8 Beta Release Notes

You can learn more about the Godot 4.8 Beta in the below. Special thanks to Synty Pass for sponsoring this video.

In the last few months, concerns have arisen about AI safety as a growing number of incidents were publicly disclosed. These incidents exposed how powerful models have become and how they represent a significant threat if not handled well. And with the global race on innovation, the challenge will compound as models become even more powerful.

While most have been worried about threat actors using powerful models to attack, the focus has been less on agents within our own walls. Since we were the ones who deployed agents internally for our companies, we implicitly trusted our agents.

Unfortunately, frontier models, regardless of their origin, cannot be trusted. This is not because models are inherently malicious. Models have been trained to attain results, which often leads to reward hacking, and models are not optimized around organizational norms or judgment. Agents are unpredictable. They will adapt as the context changes, may not behave as intended and will collaborate and collude with other agents to reach their objectives, without needing to be compromised.

Agents have been unleashed in the enterprise, at scale, and their numbers are growing rapidly. These agents are frequently overprivileged, have access to data, tools and systems and can take actions and make decisions in critical processes. They have become active participants in the enterprise.

They are agentic insiders.

Monitoring and securing those agents must become continuous. We need to understand in real time what the agents are doing and what risks those actions create, and we need to adjust their ability to act accordingly.

To manage and control these insiders, we will need Guardian Agents — an established industry term — that watch and moderate every action of every agent, before it happens, 24/7.

An agent brings together a model, a harness that orchestrates its work, an action space of tools and resources and a runtime in which it executes. Securing agents requires protection across multiple layers: identity, permissions, data, endpoints, network, cloud and runtime.

In July, we announced Project Perception, an agentic security system that uses our new cyber stack and teams of red, blue and green agents to help defenders act with speed, while defending against AI driven attacks from outside of the enterprise.

The same cyber stack is also directly applicable to managing and governing the agentic insiders that run in the enterprise.







Project Perception can be leveraged to contain agentic insiders, implementing deterministic controls on non-deterministic intelligence:

• Sensors/Signals/Actuators: bring together signals across the various sensors (identity, data, cloud, endpoint, network, runtime) to discover agents in the enterprise and bring them under management by assigning an identity, container and set of policy and permissions.
  
  
• Context: use those signals to compute, dynamically, the risk associated with what the agents are attempting to do.
  
  
• Harness/agents/models: based on dynamic agent risk, a team of Guardian Agents, with green and blue agents, actively and continually supervise every action of every agent and surgically respond as the risk profile increases, in real time.
  
  

This is where agentic security changes the equation for security practitioners.

Project Perception can supervise in real time while providing traceability for practitioners to examine what happened, understand why the risk emerged and apply the judgment needed to update their security system accordingly. Agentic security provides speed. Practitioners provide judgment. That is how defenders begin operating at the same speed as the systems they are protecting against.

Today, security systems can reliably observe the actions of the agents. Those signals are essential and tell us what we need to contain. Our security controls should increasingly be able to ask not only “What is happening?” but also “Why is it happening?” Is this consistent with the intent of the task?” This will require greater transparency into the model itself, not only the input and output tokens, but the thinking and chain of thought tokens. Only then can we truly understand whether the model’s intent is aligned with the purpose of the agent. Model transparency will not replace containment. It will make containment smarter and stronger. And it will allow us to better inform accountability and traceability. This needs to be the next step in securing agentic insiders.

With Project Perception, you can get started today on the journey to secure your agentic insiders. There should not be a choice between innovation and safety.

Hayete Gallot leads Microsoft’s work to help organizations operate securely in an AI-driven world. Her scope includes identity, threat protection, compliance and data security at global scale.

The post Securing the agentic insider appeared first on The Official Microsoft Blog.