Four open source projects to explore at Microsoft Build
Open source is where developers experiment, collaborate, and turn new ideas into tools that others can build on. At Microsoft Build, we’re creating a dedicated space for that energy: the Open Source Zone. This year, the Open Source Zone will bring together maintainers, contributors, and developers working on some of the most interesting open source projects in AI. Whether you’re building agents, experimenting with local models, exploring prompt workflows, or looking for practical ways to bring AI into your development process, this is a place to meet the people behind the projects and see what they’re building. The Open Source Zone is inspired by similar community spaces we’ve hosted at GitHub Universe: hands-on, conversation-driven, and centered on the people and projects moving open source forward. Meet the projects OpenClaw OpenClaw, originally Clawbot, formerly Clawdbot and briefly Moltbot,before landing on its current name (because naming is hard), is a personal AI assistant project built for developers who want more control over how AI agents run across tools, devices, and workflows. Its repository describes it as “your own personal AI assistant” across operating systems and platforms, with support for agent workspaces, skills, and device nodes. It has also become one of the fastest-growing open source projects on GitHub, with over 370,000 stars to date. At the Open Source Zone, attendees can learn how OpenClaw approaches personal agents, extensibility, and local-first experimentation. AutoGPT AutoGPT is one of the best-known open source projects in the autonomous agent space. The project’s mission is to make AI accessible for everyone to use and build on, with tools for building, testing, and delegating work to agents. Visit AutoGPT in the Open Source Zone to learn how the project is evolving agent development, benchmarking, frontend experiences, and practical workflows for building agent-powered applications. Come for the autonomous agents; stay for the very human maintainers. AutoGPT is also a member of GitHub’s Secure Open Source Fund, with a goal of enhancing AI security across the open source ecosystem. Open WebUI Open WebUI is a self-hosted, extensible AI platform for working with large language models. The project supports Ollama and OpenAI-compatible APIs and includes built-in RAG capabilities, making it a strong option for developers and organizations exploring local, private, or provider-flexible AI experiences. At Build, the Open WebUI team will show how developers can run, customize, and extend AI interfaces for their own environments. prompts.chat prompts.chat, formerly Awesome ChatGPT Prompts, is a curated collection of prompt examples for AI chat models. The project is designed to help people discover, share, and build better prompts for modern AI assistants. Created by Fatih Kadir Akın, a GitHub Star from Istanbul, prompts.chat reflects his work at the intersection of open source, developer education, and AI-assisted development. Fatih leads Developer Relations at Teknasyon, has authored books on JavaScript and prompt engineering, and is active in the community as a speaker, organizer, and contributor. Stop by to explore prompt libraries, prompt engineering resources, self-hosting options, and ways the community is making prompting more reusable and collaborative. Register for Microsoft Build Microsoft Build takes place June 2–3, 2026, in San Francisco and online. In-person passes are available, and online registration is free for livestreamed keynote and select session access. Register for Microsoft Build and come visit the Open Source Zone to meet the teams behind OpenClaw, AutoGPT, Open WebUI, and prompts.chat. We’ll see you there. <3Unpacking Endpoint Management is back - and we’ve got a lot to talk about
If you've been missing real, candid conversations about endpoint management, good news! Unpacking Endpoint Management is officially back. This series is all about what actually works. No fluff, just practical tips, proven strategies, and honest discussions to help you optimize and simplify the way you manage and secure endpoints today (and prepare for what's next). We're bringing together people from across Microsoft Intune, Security, and Customer Experience engineering and product teams, along with guest practitioners, to share what's worked, what hasn't, and what we've learned along the way. And yes…we're absolutely here for the tough questions. A quick update on the hosts Danny Guillory, a familiar face to the community and a Product Manager for Intune and Configuration Manager, will continue to host the series. He's joined this season by Rachelle Blanchard as co‑host, bringing a strong community and discovery lens to the series. Rachelle focuses on surfacing real customer questions and guiding conversations toward practical outcomes, helping ensure each episode reflects how endpoint management works in the real world. Up next June 30, 2026 – 9:00 a.m. PDT Topic TBD - What should we cover? Drop ideas below in the comments. July 30, 2026 - 9:00 a.m. PDT Topic TBD Sign in to the Tech Community and follow this post for the latest updates on upcoming episodes. Catch up on demand You may have missed them, but you don't have to miss out on the learnings. Watch and learn when it's convenient for you. Device security with Microsoft Intune Trends in endpoint management (live from Tech Takeoff 2026) Not sure where to start? Watch our most recent episode, Policy: from hybrid to cloud-native, now on demand! What's the format? This web series is streamed live on Tech Community, LinkedIn, YouTube, and X. In addition to open discussion, we answer your questions so sign in (or sign up for) the Tech Community and RSVP to submit questions early and throughout the live show. How do I join? There's no call or meeting to join. Simply head to aka.ms/JoinUEM. Show up at start time, watch live, and jump into the discussion with us. Help shape the series This series is for you - so tell us what you want to hear. Drop a comment below with: Topics you'd like us to cover Tough questions you want answered Speakers you'd love to hear from We can't wait to get started - and even more excited to hear from you along the way. Join the Community to get early insight into what's coming for Intune, connect with experts, and share real-world feedback that helps shape the product. 👉 aka.ms/JoinIntuneCommunity
Location of custom skills - cannot find them in OneDrive
I'm using Copilot Cowork to create skills, and Cowork insists the skills are being saved in OneDrive>Documents>Cowork>skills but I cannot find them in there. I cannot find the raw MD files anywhere in OneDrive, and Cowork can only surface them when I ask to see them. Anyone else experienced this and have the answer? I need to be able to create Cowork Skills and store them in a central repository for the team to use. #coworkHow to enable HTTPS support for Microsoft Connected Cache for Enterprise and Education
By: Aditya Middha | Product Manager 2 - Microsoft Connected Cache Starting on June 16 th , 2026, or soon after, Intune will enforce HTTPS content delivery for customers using Microsoft Connected Cache for Enterprise and Education. To continue using Microsoft Connected Cache to localize Intune Win32 app downloads and reduce the bandwidth impact on your network, you’ll need to configure HTTPS on Connected Cache nodes. Without this configuration, devices will still fetch the requested content, but they’ll fall back to the Content Delivery Network (CDN) and lose the performance and bandwidth savings that Microsoft Connected Cache provides. This guide assumes you have already deployed a standalone Microsoft Connected Cache node in your environment. If not, please see the Create and configure Microsoft Connected Cache nodes page. By the end of this walkthrough, you’ll be able to: Prepare the TLS certificate that your Connected Cache needs Enable HTTPS support on both Windows and Linux‑based Microsoft Connected Cache servers Validate that HTTPS is working end‑to‑end Diagnose the most common setup issues This guide mirrors the workflow described in Microsoft Connected Cache’s public documentation. For further explanation of what HTTPS support changes for Microsoft Connected Cache review HTTPS Support for Microsoft Connected Cache Overview, then proceed to Configure HTTPS on Windows or Configure HTTPS on Linux. Step-by-step: Enabling HTTPS support To keep this walkthrough easy to follow, the screenshots and command examples use a simple, reproducible environment that matches what most admins will see during their first HTTPS configuration. In this guide, the examples are based on: A single Connected Cache node deployment Windows 11, using a local user runtime account Public certificate authority (CA)-signed TLS certificate This baseline environment is only meant to make the screenshots and file paths predictable. Your own environment may look different, and that’s completely fine. Many customers run Microsoft Connected Cache on: Linux (Ubuntu or RHEL) Windows Server 2022 or Windows Server 2025 Networks with outbound restrictions Most of the workflow is identical across these variations. The folder structure, log locations, and command flow will look nearly the same on any Windows host. If you’re running Microsoft Connected Cache on Linux, the workflow is the same, but simpler—bash scripts are ran directly instead of being invoked through PowerShell. If your environment includes proxies, make sure all required endpoints are allowed. Before you start Before generating a certificate signing request (CSR) or importing a certificate, there are a few quick checks to make sure your Connected Cache server can enable HTTPS successfully. First, visit the “Cache Node Management” tab on Azure portal. Under the “Software Version” column, verify that your cache node is running on software version 2.0.0.2112 or higher. If not, you will need to reinstall Connected Cache. Next, confirm the hostname or IP address your client devices use to reach your Connected Cache node—this value will be configured when you generate the CSR. Also, ake sure port 443 is free on the host; Microsoft Connected Cache needs to bind to it. Finally, if your network performs TLS-inspection, ensure the required endpoints are allowed. Intercepted HTTPS traffic will cause devices to reject Microsoft Connected Cache’s TLS certificate, even if everything else is configured correctly. Once these checks are done, your node is ready for the HTTPS workflow: generate the CSR on your Connected Cache host machine, sign it with your CA, and import the resulting certificate. For more details, refer to the documentation: HTTPS on Windows Prerequisites. 1. Generate a CSR The first step in enabling HTTPS support is generating a CSR directly on your Microsoft Connected Cache node. This step cannot be skipped. Microsoft Connected Cache must create the CSR itself so it can generate and retain the private key that will later be paired with your signed certificate during TLS negotiation. When configuring the parameters for the generateCsr script, the most important values to get right are the Subject and SAN. These must match exactly how your managed client devices connect to your Connected Cache node. If the client devices use FQDN, include that FQDN; if they connect via IP, include that IP. A mismatch here won’t break CSR generation, but it’ll cause clients to bypass Microsoft Connected Cache later since they won’t trust the certificate during the TLS negotiation. For parameter configuration guidance on your specific environment, review these documented scenario-based parameter examples. After parameter configuration, you will need to locate the Installer scripts directory, the same as when you installed Microsoft Connected Cache originally. You can move directly to this path by running the following command in your terminal: Push-Location (deliveryoptimization-cli Microsoft Connected Cache-get-scripts-path) Once in the correct folder path, run the generateCsr command with your configured parameters. Running the command launches the CSR generation workflow inside the Microsoft Connected Cache-managed Windows Subsystem for Linux (WSL) distribution. The terminal output shows exactly what Connected Cache is doing: where it stores certificate files, where logs are written, which WSL distribution is being used, and the final location of the generated CSR. You’ll also see that Microsoft Connected Cache runs the CSR generation as a scheduled task inside WSL—this is expected and part of the normal flow. For example: This output confirms that Microsoft Connected Cache: Validated the CSR request Passed the Subject (Common Name) and SAN values to the internal script Generated the private key and CSR, stored both inside the container Wrote logs to the \Certificates\logs folder Created the CSR file in the Certificates folder When the process completes, you’ll see the timestamped CSR written to the Windows-side certificates folder (…\Certificates\certs). This is the file you’ll submit to your signing CA: Troubleshooting: Every time you run generateCsr, Microsoft Connected Cache writes a full log to a directory that ends with …\Certificates\logs. The terminal output shows you the exact path, and you can always return to this folder if you need to understand what happened during CSR generation. If you do need to troubleshoot, start by opening the most recent log file. The generateCsr log provides a detailed trace of each step. The following lines are checkpoints (in order) that you can look for in the more extensive log output: “Algorithm validation passed / CSR name validation passed” - Microsoft Connected Cache accepted your inputs and is ready to generate the CSR. “Subject Components: … / SAN Components: …” - Microsoft Connected Cache will embed these values into the CSR. If these don’t match your Connected Cache server hostname or IP address, regenerate the CSR. “Attempting to call http://localhost:5000/csr” - Microsoft Connected Cache internal controller is generating the keypair and CSR inside the WSL container. “Key verification succeeded” - Microsoft Connected Cache successfully generated and validated the private key. “CSR verification successful” - OpenSSL has validated the CSR structure. “Successfully copied logs to windowsCerts location” - The logs were written to the host machine directory. “CSR generation completed successfully” - Completed end-to-end successfully. One thing to be aware of: during a successful run, you may still see messages like: mkdir: cannot create directory '/keys': Permission denied chmod: cannot access '/keys': No such file or directory These are not errors. The script checks for required folders before creating them, and if they already exist, those checks generate harmless warnings. As long as the script finishes with a success message and you see a .csr file in the certs folder, the run is successful. 2. Sign the CSR This step occurs outside of the scope of Microsoft Connected Cache. Signing your CSR will rely on the PKI that your organization has chosen to use. This may include an internal ADCS, other enterprise internal PKI, or an externally hosted PKI (DigiCert, Let’s Encrypt, etc.). Of note, Cloud PKI will not work with Connected Cache because it requires the CSR be generated via SCEP before signing. Ensure that your client devices will be able to trust the CA signature. For many customers, we recommend signing using a public CA that Windows client devices automatically trust. Please reference documentation on signing the CSR for more details. The only requirement on the Connected Cache side is that the certificate is in unencrypted .crt format. Microsoft Connected Cache cannot import password-protected certificate formats yet - including .pfx bundles - even if they contain the correct certificate. For now, make sure your signing CA gives you, or allows you to export, a plain X.509 .crt file. After your CA signs the CSR, you’ll import the resulting certificate back to Microsoft Connected Cache. With the signed certificate in hand, place it in the same certs folder where your CSR was generated. Microsoft Connected Cache expects both files to live together so it can pair the returned certificate with the private key created earlier. A successful setup in the folder directory looks like this: If the certificate exists in the Certificates folder in .crt format, you’re ready to continue. Note: The CSR and .crt certificate do not have to have the same name. 3. Import the certificate back to Microsoft Connected Cache Before importing your certificate, remember that the CSR must have been generated on the same Microsoft Connected Cache node. You cannot skip directly to importing a certificate - Microsoft Connected Cache must have created the private key during CSR generation so it can pair the signed certificate with that key. After configuring the parameters referenced in the documentation to import the signed TLS certificate, run the importCert command from the same scripts directory used during CSR generation. When you start the import, Microsoft Connected Cache runs a full verification workflow inside its managed WSL distribution. The terminal output for this step is intentionally simple—it shows only that the certificate file passed basic validation, that the internal import script was invoked, and that the import is running as a scheduled task within the WSL distribution. You’ll also see that logging is active and that Microsoft Connected Cache has begun monitoring the process: Although the terminal output is brief, the full workflow is visible in the import logs. A successful import means Microsoft Connected Cache: Found your .crt file in the expected folder Ran cryptographic verification confirming the certificate, CSR, and private key all match Copied the certificate into the container and updated Microsoft Connected Cache internal configuration Restarted the container with the new certificate Enabled HTTPS for Microsoft Connected Cache’s Intune content endpoints Once these steps are complete, Microsoft Connected Cache is fully configured to serve HTTPS content. You usually won’t see new files added to the Windows certs folder after import as the changes occur inside the Connected Cache container. The final validation that import is successful is if the script exits successfully and the logs show that Microsoft Connected Cache restarted with the new certificate in place. Troubleshooting Troubleshooting certificate import is similar to troubleshooting CSR generation: every run produces a detailed log in the ...\Certificates\logs folder. If import fails, these logs will show exactly which step did not complete. At this stage, SAN or hostname mismatches do not show up; those only appear later during client-side validation. The importCert script only ensures that your certificate, CSR, and private key match (stored inside container, not visible from Certificates folder) and that Microsoft Connected Cache can load them. To help interpret the log, below are the checkpoints you can reference (in order): “Certificate file validation passed” - Microsoft Connected Cache found the .crt file in the certs folder and its .crt format is valid. “Using CertName: … / CSR being used: …” - Microsoft Connected Cache matched the certificate to the CSR that generated the private key. “SUCCESS: The CSR, certificate and private key cryptographic materials all match” - Microsoft Connected Cache verified the keypair, CSR, and certificate are a correct trio. “Nginx restarted successfully with new certificates” - Microsoft Connected Cache is now configured to serve HTTPS on port 443 inside the container. “Certificate import completed successfully” - The end-to-end import succeeded with no errors. Once the importCert script succeeds, your node is ready for validation. Validating HTTPS support end-to-end Once your certificate is imported, the final step is validating that Microsoft Connected Cache is now serving content over HTTPS. Detailed test commands are all documented in the Validate HTTPS on Windows guide. Complete the tests first on the Microsoft Connected Cache server, then on a client device. This order matters - server-side validation confirms Microsoft Connected Cache is listening on port 443 with its new TLS certificate; client-side validation confirms that client devices can trust and use that certificate. On your Microsoft Connected Cache server Start validation on the Microsoft Connected Cache host server. The server side tests include HTTPS and HTTP health endpoint checks that confirm: Microsoft Connected Cache is successfully bound to port 443 The TLS certificate loaded correctly The TLS certificate, private key, and CSR all correspond Microsoft Connected Cache can return its health endpoint over HTTPS If any of the server-side validation steps fail, check the generateCsr and importCert logs in the …\Certificates\logs folder. The validation guide includes troubleshooting tests that help distinguish whether the issue is certificate-related, connectivity-related, or due to another process on the host. Only move on to client-side validation once the Microsoft Connected Cache server passes its own tests. On your client device After confirming the server is configured correctly, the next stage is validating HTTPS content delivery from a client device that is pointed to use Microsoft Connected Cache. The client-side tests contain both browser-based and command line tests that help verify: The client trusts the issuing CA DNS resolves the Microsoft Connected Cache hostname correctly The device can complete a full TLS handshake with Microsoft Connected Cache The device is retrieving HTTPS content from Microsoft Connected Cache rather than falling back to CDN Once both server-side and client side-validation steps succeed, you can be confident that your Microsoft Connected Cache node is fully configured and ready to serve Intune content securely over HTTPS. Known issues with HTTPS Support Configuration Most customers will complete the HTTPS workflow without any problems, but there are a few known issues we want to call out proactively. These issues have been fully addressed with the release of the new Windows-hosted deployment application (v1.0.26.0) for Windows host machines, the new Linux-hosted deployment package (v1.10) for Linux host machines, and the latest GA container release (v2.0.0.2124_e) for all cache nodes. ImportCert issues on Windows Server 2022/2025 using a gMSA account, and on Windows 11 using a local user runtime account If your Microsoft Connected Cache runtime account is a Group Managed Service Account (gMSA) on a Windows Server 2022 or Windows Server 2025 host machine, you may see failures when running importCert. In the importCert logs, this can show up as unsuccessful permissions access or indefinite logging. The same importCert issues can also appear on Windows 11 if you are using a local user as the runtime account. Status: RESOLVED Please download Windows-hosted deployment application v1.0.26.0 by running the following command in an elevated PowerShell window: Add-AppxPackage https://aka.ms/do-mcc-ent-windows-x64 Then you may proceed to re-deploy your Connected Cache node, which will implement the necessary changes. You can further verify that you are deploying with the correct application version. When run in the terminal, the copied “Cache Node deployment command” given in the Azure portal will run deploymcconwsl.ps1 out of the folder path that looks like: C:\ProgramFiles\WindowsApps\Microsoft.DeliveryOptimization_1.0.26.0_neutral__8wekyb3d8bbwe\deliveryoptimization-cli ImportCert hangs on software version 2119_e (buffer bug) During the week of January 19 th , 2026, we deployed container version 2119_e to all customer cache nodes. We discovered a bug where the container’s internal buffer is not cleared during importCert, causing the import to run indefinitely. If you see this behavior and your Azure portal shows that your cache node is on version 2119_e, this is likely the cause. Status: RESOLVED: On March 3 rd , 2026, we pushed container version 2124_e to all cache nodes on the “Fast Ring” update schedule. If your cache node is on software version 2119_e today, you can change the update schedule configuration to the “Fast Ring”. Head to the 3 rd tab (“Updates”) of the Cache Node Configuration on the Azure portal and configure the update ring. Container version 2124_e will be pushed to all “Slow Ring” nodes in early April 2026. If your cache node is still not pulling down container version 2124_e after being configured on the Fast Ring, please reach out to us. The fixes for these issues have all been validated. Once ready for public release, the latest software version will be pushed to all cache nodes and the updated Windows installer will be available to download in Azure portal. Stay tuned to the Microsoft Connected Cache Release Notes for up-to-date information. Enabling HTTPS support on Linux hosts This guide walked through the setup of HTTPS using a Windows-based Microsoft Connected Cache host, since that’s what most customers deploy today. If you're running Microsoft Connected Cache on Linux, the overall steps are the same - generate a CSR on the node, sign it with your CA, and import the resulting .crt file - but a few details differ. For a Linux-hosted Microsoft Connected Cache nodes, shell scripts handle the entire process, specifically generateCsr.sh and importCert.sh. The Enable HTTPS Support on Linux guide documents these steps in detail, including the exact script parameters, file locations, and how to interpret the Linux-specific logs. The biggest differences on Linux are: You run the CSR and import scripts directly in bash (no WSL component). File paths and log locations follow the Linux directory structure (/var/mcc/...). Check port conflicts, firewall configuration, and TLS inspection using Linux tools (ss, iptables, proxy settings). Validation steps use Linux equivalents of the server side tests documented in the Windows validation guide. Maintaining your HTTPS configuration Once your Microsoft Connected Cache node is serving content over HTTPS, the next thing to plan for is ongoing certificate maintenance. TLS certificates aren’t a onetime import - certificates expire, CA chains change, and your operational process needs to keep up. Microsoft Connected Cache will soon surface certificate details both through a command line script and directly in the Azure portal, but those capabilities are not available yet. Until then, verification and rotation rely on simple checks you perform on the Microsoft Connected Cache host. Monitoring The easiest way to monitor your deployment today is to periodically check the Key Metrics chart in the Overview blade of your Microsoft Connected Cache resource in Azure. If Intune content is flowing through Microsoft Connected Cache, that’s a strong proxy signal that HTTPS is healthy. For the certificate itself, many admins perform a lightweight weekly or monthly review: ensuring the TLS certificate is still valid, not approaching expiration, and still matches the configuration you imported. Re-running the validation tests from our public documentation every so often is also a good way to catch any issues early. The updated Windows installer, as mentioned in Known Issues, will also have a PowerShell script that displays the status and expiration date of existing TLS certificates. Renewal When planning for renewal, we recommend starting at least 60 days before the certificate expires. Renewal is typically straightforward: either reuse the existing CSR (most common) or generate a new one, then have your CA resign it, convert it into .crt format, and test the renewed certificate on a test node if you have one. If your workflow doesn’t include a test Connected Cache node, you can still safely import the renewed certificate on your production node - if import fails, Microsoft Connected Cache simply keeps using the existing certificate until a valid one is applied, so you won’t break your environment. If your certificate management system has automation capabilities, you can script Microsoft Connected Cache’s certificate renewal workflow as well - for example, by using Secure Shell (SSH) to remotely to run the generateCSR or importCert scripts on the host machine. For larger or distributed environments, testing the signing and import processes on a non-production node first can help confirm SAN correctness, trust behavior, and chain completeness before touching production. We are actively working to streamline certificate monitoring and renewal inside Microsoft Connected Cache. Summary HTTPS support for Microsoft Connected Cache will soon become a requirement for delivering Intune Win32 apps, and every Microsoft Connected Cache node must be configured for HTTPS by June 16, 2026. After the deadline, Intune Win32 apps will only be delivered via HTTPS. However, all other content – Windows updates, Office apps, etc – will continue to be served via HTTP after the June 16 th enforcement date. This guide walked through the essentials: generating a CSR on your Microsoft Connected Cache node, submitting it to your CA, importing the signed certificate, and validating HTTPS from both the server and client devices. Along the way, you saw how to interpret the logs, verify Connected Cache is using your certificate correctly, and ensure that Teams and/or Intune content is flowing over HTTPS instead of falling back to CDN. As you move forward, keep your workflow consistent - regenerate or reuse CSRs the same way each cycle, validate regularly, and renew certificates well before expiration. Even though improvements are coming soon, completing this setup now ensures your environment is ready long before Intune HTTPS enforcement begins. With your certificate in place, HTTPS validated, and a simple renewal process in hand, your Microsoft Connected Cache deployment is prepared for the June 16 th , 2026 deadline and ready to deliver Intune content securely. FAQs Do I really need HTTPS Support, and by when? Yes. All Microsoft Connected Cache nodes serving Intune Win32 apps must deliver over HTTPS by June 16, 2026. If HTTPS isn’t configured, devices will fall back to CDN when requesting Intune win32 apps —content delivery still works, but you’ll lose caching benefits. Why do I have to generate the CSR on the Connected Cache node? Since Microsoft Connected Cache must generate and retain the private key itself. Certificates signed from any other machine, keypair, or CSR cannot be imported. The CSR you generate on the node produces the only key that Microsoft Connected Cache will accept. Can I reuse an existing certificate? Only if it was originally issued from the CSR generated on the same Microsoft Connected Cache node. If the certificate was created elsewhere (different machine, tooling, or CSR), Microsoft Connected Cache won’t accept it. Can I reuse my CSR when renewing the certificate? Yes. Many customers reuse the same CSR each cycle as long as the CA resigns it. Reusing the old certificate output is not supported. Can I “bring my own certificate”? Not yet. Microsoft Connected Cache only supports certificates created from its own CSR. Support for bringing an external certificate is coming soon; stay up to date by viewing the latest Microsoft Connected Cache Release Notes Can I use a wildcard certificate? Microsoft Connected Cache does not officially support them and they’re not recommended. Wildcards often involve shared private keys across systems, which creates operational and security risks. What certificate formats does Microsoft Connected Cache support? Microsoft Connected Cache only supports unencrypted .crt files today. Password protected .pfx or .p12 formats cannot be imported. What happens if I redeploy Microsoft Connected Cache or the hostname changes? If the hostname or connection path changes, you must request a new certificate that matches the new SAN parameters. If the hostname stays the same and the certificate came from the Connected Cache-generated CSR, you can continue using it. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam! Post Updates: 04/08/26: Updated the “Known issues with HTTPS Support Configuration” section to reflect that previously identified issues have been fully resolved in the latest deployment application and container releases, along with updated guidance for affected cache nodes.
Architectural: Copilot should detect missing source data, avoid inference, and surface uncertainty.
Users expect the AI to detect when it lacks source data, avoid inference, surface uncertainty, and adapt to environmental constraints like character normalisation. These behaviours materially improve trust and usability. I’ve been working with Copilot on structured data extraction from a PDF and noticed a behaviour that seems like an architectural gap rather than a simple bug. Copilot attempted to infer table structure from a template when it did not have access to the actual source data. It produced confident but incorrect output instead of signalling that the source was unavailable. Additionally, Copilot attempted to output TAB‑delimited data, but the MS365 environment silently normalised TABs to spaces, and Copilot did not detect or adapt to this constraint. Recommendation: Copilot should proactively: detect when it lacks source data avoid inference when accuracy is expected surface uncertainty explicitly detect environment‑specific formatting limitations (e.g., TAB stripping) adapt output formats automatically These behaviours would materially improve trust, reliability, and user experience.Cowork Custom Instructions Not Autoloading
When you tell Cowork "remember this for next time" or "always do X," Cowork suggests (or just goes ahead and makes) an update to copilot-instructions file. It tells you the preference has been saved and the file does get written. However, it doesn't automatically load the custom instructions file at the start of new sessions. You have to specifically mention it in a prompt. Once you do, it will load the and use the file to guide its responses for the remainder of the session. I feel like one of two things are happening here: 1. I'm missing something 2. The Cowork dev team missed implementing what I would consider a basic feature, even for a "Frontier" feature. Can anyone else confirm that this is the behavior they experience?Known issue: Upgrading Microsoft Tunnel version 20260129.1
We identified an upgrade issue with the early March release of Microsoft Tunnel version 20260129.1 that caused servers to become stuck and unable to complete the upgrade. The issue can be resolved by uninstalling and reinstalling the server to a newer version (20260330.1 or later). Alternatively, we’ve created a script to help you update affected servers. This blog explains how to use the mstunnel-patch-2602 script to remediate the issue. Before you begin Before you run the script, make sure you have the following: Access to the Linux virtual machine hosting the Microsoft Tunnel server Permission to run commands with sudo The patch script downloaded to the server from https://aka.ms/mstunnel-patch-2602 When to use this script Use this script if your server is showing one or more of the following behaviors: The server remains on the affected version (20260129.1) and doesn’t move to the latest version In the Intune admin center, the server health state appears as Healthy, but the upgrade banner shows an error The server rolls back to the affected version because of a version mismatch in Agent Settings Identify impacted servers The issue affects servers on version 20260129.1, use the following hash to identify whether your deployment is on this version: Agent: sha256:abbdcd854aa5ac376aed32c828e4c84917e776a701855cd1e3febed18a3e4dae Server: sha256:ad57d6a7ffe21f64fc1577713063ae9b180914cf65bc70b4e49be21299cfc1d3 The issue was resolved with version 20260330.1, released March 30, 2026. You can verify your servers are on this version with the following hash: Agent: sha256:163214b94af6d91a5ef02690f891c5a41e87b1059b9530324716ee34778c1785 Server: sha256:dd62c292528e8e5aa4e7b84418efa42fd3830ec0db40467947cde8125aa17d7e Run the script After downloading the script to the server, complete the following steps. Step 1: Enable execution permissions If needed, make the script executable: chmod +x mstunnel-patch-2602.sh Step 2: Run the script Run the script with elevated permissions: sudo ./mstunnel-patch-2602.sh When the script runs, it performs the following actions automatically: Checks whether the current server is using the affected build hashes. Creates backups of the current configuration so the system can revert if the update fails. Stops the Tunnel agent and server services. Updates the configuration with version 20260330.1 hashes Pulls version 20260330.1 and forces mst-cli install without requiring additional user input Expected results After the script completes successfully, the server should be updated to the March 30, 2026 version 20260330.1. This remediation is intended to resolve upgrade failures caused by a version mismatch and eliminate the need for a manual uninstall and reinstall workflow. If you have any questions or issues running the script to update your servers, reply to this post or reach out to the team on X @IntuneSuppTeam.After the Agent Acts: Proving What Happened and Who Authorized It
In part one of this series, we covered AGT's runtime governance: the policy engine, zero-trust identity, execution sandboxing, and the OWASP Agentic AI risk mapping. In part two, we moved earlier in the lifecycle: shift-left governance, CI/CD gates, attestation workflows, and supply chain integrity. Both posts focused on governance that happens around the moment of action, before it, during it, or right after it. That coverage is essential. But after those posts went live, a different pattern emerged in conversations with teams deploying agents in production. The question was more pointed: "An agent executed a financial transfer last Tuesday. A compliance officer is asking us to show who authorized it, through what chain, and exactly what scope it was granted. We have logs. But can we prove they weren't altered?" No policy engine prevents a past action. No CI gate reconstructs a delegation chain after the fact. No shift-left tool tells an auditor whether the cryptographic identity that authorized a trade was legitimately derived from a human principal, or was injected mid-chain. This is the accountability gap. It is the governance question that neither runtime enforcement nor pre-runtime checks were designed to answer. Regulatory frameworks are tightening: the EU AI Act includes high-risk obligations with enforcement timelines in 2026, and the Colorado AI Act introduces requirements for automated decision-making. Courts are beginning to encounter AI agents in the evidentiary record. The accountability infrastructure has not caught up. This post covers what post-hoc accountability means for autonomous agents, what the Agent Governance Toolkit has to help address it, and three value propositions that are real but not yet visible in how governance tooling is typically described. Note: The policy files, workflow configurations, and code samples in this post are illustrative examples designed to show the concepts. For working implementations, see the QUICKSTART.md in the repository. The Accountability Gap in Multi-Agent Systems The accountability problem is architectural. When a single agent takes a single action, accountability is straightforward: you know which model ran, what prompt it received, and what it called. When agents delegate to sub-agents, which delegate further to tool-execution agents, the chain of authorization becomes progressively disconnected from the original human instruction that started it. Consider this delegation topology, common in any production orchestration scenario: Human Principal └── Orchestrator Agent (did:mesh:orchestrator-001) └── Data Analyst Agent (did:mesh:analyst-001) └── File Write Tool (write /reports/q3-summary.csv) By the time file_write fires, three delegation hops have occurred. The file write tool has no reliable way to know whether the human principal actually authorized file writes, what scope they granted to the orchestrator, or whether the analyst agent's instructions arrived through a legitimate delegation or were injected by a prompt injection attack. This gap has three concrete consequences: Consequence Operational Impact Post-hoc audits cannot reconstruct authorization Incident investigations are limited to "the agent did this," not "here is who authorized this, through what chain, at what time, with what scope" Agents cannot distinguish legitimate delegation from injection A prompt injection attack that inserts itself into a delegation chain is indistinguishable from a real orchestrator instruction without cryptographic verification Accountability cannot be attributed to a human authorization event When a regulator asks "who is responsible for this action," the answer is a shrug and a log file AGT already has the technical foundations designed to help close all three. The gap is not capability, it is visibility. What AGT Has: The Cryptographic Accountability Stack AGT's accountability infrastructure spans three components that work together: cryptographic agent identity, delegation chains, and tamper-evident audit logs. 1. Ed25519 Agent Identity with Lifecycle Management Every agent in an AGT-governed system carries a cryptographic identity: a verifiable Ed25519 keypair with a W3C DID Document that can be exported, shared, and verified by any participant in the system. from agentmesh import AgentIdentity, IdentityRegistry # Create a verifiable agent identity identity = AgentIdentity.create( name="data-analyst", sponsor="operator@contoso.com", capabilities=["data.read", "report.write"], organization="data-team", description="Q3 close data analyst agent" ) # Export as W3C DID Document for cross-system verification did_document = identity.to_did_document() # Register in the shared identity registry registry = IdentityRegistry() registry.register(identity) Identity lifecycle states, active, suspended, revoked, are tracked and cascaded. When an orchestrator identity is revoked, every downstream agent delegated from it is also invalidated. This cascade revocation behavior lets you kill a compromised delegation chain from its root rather than hunting sub-agents individually. 2. Delegation Chains with Scope Inheritance When an orchestrator delegates to a sub-agent, AGT records the delegation cryptographically: who delegated, to whom, what capabilities were transferred, and what restrictions were applied. Sub-agents are designed to be unable to exceed the scope of their delegating principal. from agentmesh import ScopeChain, DelegationLink # Create a scope chain rooted in a human sponsor chain, root_link = ScopeChain.create_root( sponsor_email="operator@contoso.com", root_agent_did=str(orchestrator_identity.did), capabilities=["data.read", "report.write", "data.delete"], sponsor_verified=True, ) # Orchestrator delegates narrowed scope to analyst agent link = DelegationLink( link_id="link-analyst-001", depth=1, parent_did=str(orchestrator_identity.did), child_did=str(analyst_identity.did), parent_capabilities=["data.read", "report.write", "data.delete"], delegated_capabilities=["data.read", "report.write"], # narrowed: no delete parent_signature=orchestrator_identity.sign( f"{orchestrator_identity.did}:{analyst_identity.did}:data.read,report.write".encode() ), link_hash="", # computed on add previous_link_hash=root_link.link_hash, ) link.link_hash = link.compute_hash() chain.add_link(link) # Verify the entire chain: scope narrowing + hash integrity + signatures valid, reason = chain.verify() if not valid: raise ValueError(f"Chain verification failed: {reason}") The scope chain carries the human authorization context: the root sponsor email, when the chain was created, and what capabilities were granted at the top. Every downstream agent can trace any capability back through the chain using chain.trace_capability("data.read"). A file write tool executing three hops from the human principal can verify that the original sponsor authorized file writes in this scope. This is the mechanism designed to help close the prompt injection gap: an injected instruction cannot produce a valid signed delegation link from a legitimate orchestrator identity. 3. Tamper-Evident Audit Logs Every policy decision, every delegation event, every tool call, every trust score evaluation: AGT writes a signed, append-only audit record. The signature covers the content hash of the log entry plus the hash of the preceding entry, forming a chain where tampering is designed to be detectable. from agentmesh import PolicyEngine, AuditLog # Create the audit log (with optional external sink for production) audit_log = AuditLog() # Log a governance decision entry = audit_log.log( event_type="policy_decision", agent_did=str(analyst_identity.did), action="report.write", resource="/reports/q3-summary.csv", data={"task_id": "q3-close-2026"}, outcome="success", policy_decision="allow", ) # Verify the audit chain has not been tampered with valid, reason = audit_log.verify_chain() # valid == True: all hashes and chain links are intact # Query audit trail for a specific agent trail = audit_log.get_entries_for_agent(str(analyst_identity.did)) The audit trail for a single task session includes the complete delegation chain, from human authorization event at the top to tool execution at the bottom, with cryptographic signatures at every step. Validating a Compliance Evidence Package The three components above are most powerful when used together. At runtime, AGT's audit chain, identity registry, and delegation system each produce structured records. Assembling these into a single evidence package for compliance submission or incident investigation is a deployment-level concern: your CI pipeline or orchestration layer collects the outputs into a JSON artifact. Once assembled, AGT's agt verify --evidence flag validates the package: checking that signatures are intact, delegation chains are complete, and audit entries have not been tampered with. # Validate a runtime evidence package agt verify --evidence ./agt-evidence.json # Strict mode: fail if evidence is missing, incomplete, or signatures don't verify agt verify --evidence ./agt-evidence.json --strict Future direction: A built-in agt evidence collect command to automate evidence assembly is on the backlog. The evidence package helps answer the audit questions directly: Auditor Question Where It Lives in the Evidence Package Which agent executed this action? identity.agent_id with Ed25519 public key Who authorized it? delegation_chain[0].human_principal with timestamp What scope was granted? delegation_chain[*].granted_capabilities at each hop Was the delegation legitimate? delegation_chain[*].signature, verifiable against issuer's public key Was the audit log altered? audit_trail.chain_valid: true/false with entry-level hash verification What policy governed the action? policy_decision.rule_name with the policy YAML snapshot at decision time This is the difference between "we have logs" and "here is a verifiable chain of custody backed by cryptographic signatures." The Governance Dial: Enabling Autonomy, Not Just Blocking Risk There is a framing problem in how agent governance is typically described. Governance is described almost entirely as a constraint: what agents cannot do, what gets blocked, what violations get caught. This framing is accurate but incomplete. Governance is the mechanism that helps you safely expand what your agents can do. Without governance evidence, every expansion of agent autonomy is a leap of faith. With it, expansions are decisions with a measured risk profile: Scenario Without Governance Evidence With AGT Accountability Stack Expand agent to write to production databases Requires human approval on every write indefinitely Pilot with human-in-loop for 500 writes; audit trail shows 0 violations; graduate to autonomous Deploy agent in a regulated data environment Blocked by legal until "we can prove it" Evidence package helps satisfy audit requirement; deployment proceeds Respond to a security incident involving an agent Manually reconstruct what happened from scattered logs Pull the task session's evidence package; full chain of custody in minutes The governance layer is the dial between supervised and autonomous operation. Audit evidence is what helps justify turning the dial further in the autonomous direction. Blast Radius: The Governance Assurance You're Not Advertising The sandboxing and privilege ring system in AGT is typically described in security terms: isolation, privilege reduction, process-level enforcement. But there is a more concrete operational value: blast radius definition before an incident occurs. The question every operations team needs to answer before deploying an autonomous agent at scale is: *"If this agent goes wrong, not if, when, what is the worst-case outcome?"* Without governance-enforced privilege boundaries, the answer is uncomfortably open-ended. With AGT's capability model and execution rings, the blast radius is a policy configuration: a bounded, declared set of resources the agent can touch, scoped to what the task requires. # policies/financial-agent.yaml apiVersion: governance.toolkit/v1 version: "1.0" name: financial-agent-policy default_action: deny rules: - name: allow-report-write condition: "tool_name == 'report.write' and path.startswith('/data/reports/')" action: allow priority: 10 - name: allow-data-read condition: "tool_name == 'data.read' and path.startswith('/data/processed/')" action: allow priority: 10 With this policy in place, the worst-case outcome for this agent is declared in the policy file, not discovered during a post-incident review. The audit log records not just what the agent did, but also every action that was blocked, giving you a full picture of how close any session came to the declared blast boundary. Regulatory Alignment The OWASP-COMPLIANCE.md in the AGT repository maps the toolkit's controls to each of the 10 OWASP Agentic AI risks. The compliance picture for specific regulatory frameworks: Regulatory Requirement Relevant Framework AGT Control Technical documentation for high-risk AI EU AI Act, Art. 9-11 Evidence package, policy audit trail, OWASP attestation Logging for automated decisions EU AI Act, Art. 12 Tamper-evident audit log with entry-level signatures Human oversight mechanisms EU AI Act, Art. 14 Circuit breakers, privilege rings, delegation scope limits Algorithmic impact assessment Colorado AI Act Policy snapshot at decision time, signed governance evidence Audit trail for automated decisions HIPAA, SOC 2 Type II Immutable audit log with W3C DID-based agent identity Non-repudiation of agent actions Financial services (MiFID II, SEC) Ed25519-signed audit entries, delegation chain with human auth context Note: The Agent Governance Toolkit does not guarantee compliance with any specific regulatory framework. The mappings above show how the toolkit's controls align with common requirements. Consult legal counsel for your specific obligations. Putting It Together The three posts in this series cover three distinct layers of the governance lifecycle: Layer Timing Primary Value Post Shift-left governance Before production Catch policy violations at commit, PR, and CI time Part 2 Runtime governance At the moment of action Deterministic policy enforcement, zero-trust identity, sandboxing Part 1 Post-hoc accountability After the action Cryptographic chain of custody, blast radius evidence, regulatory proof This post None of these layers substitutes for the others. Pre-runtime governance cannot prevent a runtime violation. Runtime enforcement cannot retroactively prove authorization. Post-hoc accountability cannot undo an action that runtime governance should have blocked. They compose. Getting Started If you already have the AGT policy engine in place, the path to full accountability coverage is incremental: Add agent identity - Create identities for each agent and register them. Export DID documents for cross-service verification. Record delegation tokens - At each orchestrator-to-agent delegation boundary, create and sign a delegation link. Pass tokens as context to the policy engine. Configure a tamper-evident audit backend - Configure the audit chain with a signing key and chain verification. For production, use an immutable backend: Azure Blob with WORM retention, S3 Object Lock, or equivalent. Generate your first evidence package: agt verify --evidence ./agt-evidence.json --strict Add evidence generation to your CI/CD release gate: # .github/workflows/release.yml - name: Governance Evidence Gate uses: microsoft/agent-governance-toolkit/action@<sha> #v3.5.0 with: command: governance-verify evidence-path: ./agt-evidence.json strict: true fail-on-missing-chain: true Conclusion Runtime governance and shift-left governance answer the question: did we apply the right controls? Post-hoc accountability answers the question: can we prove it? The Agent Governance Toolkit has the technical infrastructure designed to help answer it: Ed25519 agent identity with cascade revocation, cryptographically signed delegation chains with human authorization context, and tamper-evident audit logs that form a verifiable chain of custody from human principal to terminal tool call. The governance dial analogy is worth keeping. Every autonomous agent deployment exists on a spectrum between fully supervised and fully autonomous. The limiting factor on where you can set that dial is not model capability or framework maturity. It is how much governance evidence you have, and how verifiable that evidence is. Resources GitHub: microsoft/agent-governance-toolkit: AI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10. Quickstart: Quick Start - Agent Governance Toolkit OWASP Compliance Mapping: OWASP Compliance - Agent Governance Toolkit PyPI: pip install agent-governance-toolkit[full] npm: npm install microsoft/agent-governance-sdk NuGet: dotnet add package Microsoft.AgentGovernance Have questions about deploying AGT in your environment? Open an issue at aka.ms/agent-governance-toolkit or join the conversation in the comments below.
