Architecting Multi-Agent Systems in Copilot Studio: Orchestration, Delegation, and Handoffs
Executive Summary As enterprise conversational AI matures, organizations quickly run into the "Monolithic Agent Dilemma": a single bot tasked with answering IT questions, navigating HR benefits, generating financial forecasts, and resetting passwords quickly becomes unmanageable. Maintenance turns brittle, topic trigger collisions skyrocket, and system prompts balloon beyond effective context windows. The industry solution is Multi-Agent Architecture—decoupling monolithic agents into specialized, bounded worker agents governed by an intelligent supervisor agent. In this article, we break down how to architect, build, and deploy an enterprise-grade multi-agent ecosystem using Microsoft Copilot Studio, complete with orchestration patterns, state-passing best practices, and graceful human-in-the-loop (HITL) escalations. 1. The Architectural Shift: Monolith vs. Multi-Agent In traditional chatbot design, all logic resides in a single container. In a multi-agent system, agents mimic a real-world enterprise organizational chart with a Front-Door Supervisor Agent, specialized Worker Agents (IT, HR, Finance), and human escalation queues. Why Multi-Agent Wins for Enterprise: Separation of Concerns: HR teams maintain HR topics and knowledge; IT teams maintain infrastructure playbooks without cross-team deployment collisions. Isolated Context Windows: Worker agents only receive instructions and data relevant to their domain, reducing hallucination risks. Granular Security and DLP: IT agents can access privileged admin connectors, while HR agents operate under zero-trust privacy boundaries. Independent Versioning and ALM: Teams deploy updates to their specific agent solution without redeploying the entire company bot. 2. Core Architectural Roles: The Supervisor & Worker Agents The Supervisor Agent (The Front-Door Concierge) Acts as the primary endpoint interacting with end users across Microsoft Teams, web portals, or M365 Copilot. Greeting and persona consistency. Ambiguity clarification and intent routing. Shared state and session tracking. Handoff management and post-execution response synthesis. Worker Agents (Domain Specialists) Focused task-solvers that execute deterministic workflows or specialized generative actions: Identity and Access Agent: Handles Entra ID group requests, MFA resets, and licensing checks. Travel and Expense Agent: Inspects corporate travel policy, checks receipts, and posts expense reports. Knowledge Agent: Connects to specific Graph connectors and Azure AI Search indexes with targeted grounding. 3. Communication & Delegation Patterns Pattern 1: Direct Sub-Agent Invocation (Agent-as-a-Tool) How it Works: The supervisor agent registers worker agents as callable tools or custom actions via OpenAPI or Power Automate. Best Used For: Fast, single-turn tasks where worker agents return structured data to the supervisor. Pattern 2: Bot-to-Bot Protocol / Skills How it Works: The supervisor connects to worker agents registered as Bot Framework Skills using Direct Line or App Registrations. Best Used For: Long-running multi-turn dialogs where the worker temporarily takes over the conversation canvas. Pattern 3: Event-Driven Orchestration via Dataverse How it Works: Tasks are logged to an audit table in Dataverse; background agents pick up requests asynchronously and notify the user via Adaptive Cards. Best Used For: Asynchronous workflows requiring multi-approver sign-off or external job completion. 4. State & Context Passing: Avoiding the "Amnesia Problem" The biggest challenge in multi-agent handoffs is loss of context. If a user reports a specific VPN error code, transferring them to the IT Agent with a blank state causes the bot to ask the user to repeat themselves. Solution: Context Packet Schema When transferring between the Supervisor and Worker Agent, serialize and pass a structured JSON Context Payload: json { "sessionId": "conv-98421-m365", "initiator": { "userId": "user_aad_guid_12345", "upn": "email address removed for privacy reasons", "department": "Engineering", "locale": "en-US" }, "intent": { "domain": "IT_Support", "subCategory": "VPN_Diagnostics", "confidence": 0.94 }, "extractedEntities": { "errorCode": "800", "clientOs": "Windows 11 Enterprise", "initialQuery": "My VPN is failing with error 800, can you help me fix it?" } } Implementing in Copilot Studio: In the Supervisor Agent, capture global variables (such as Global.UserContext and Global.ExtractedProblem). When calling the Worker Action or Skill, map these global variables into the worker's Input Arguments. In the Worker Agent, configure the topic to check incoming arguments: if errorCode is already populated, skip intake questions and begin diagnostics immediately. 5. Designing Graceful Fallbacks & Human-in-the-Loop (HITL) Multi-agent systems require a fault-tolerant escalation pipeline when automated resolution confidence falls below threshold. Best Practices for Human Escalation: Warm Handoffs Only: Never dump a cold transfer. Always attach the transcript, attempted diagnostic steps, and error codes. Microsoft Teams Shared Channels: For internal support, dispatch escalation Adaptive Cards into a private Support Teams channel where engineers can claim the ticket with one click. Omnichannel for Customer Service: Utilize Copilot Studio's native integration with Dynamics 365 Omnichannel to pass live chats with full routing rules. 6. Security, DLP, and Governance Guardrails Data Loss Prevention (DLP) Isolation: Assign worker agents to dedicated Power Platform environments based on their data classification tier. General environments handle read-only FAQ and public knowledge; high-privilege environments handle Active Directory changes and ERP transactions. Prompt Injection Resilience: The Supervisor agent must sanitize freeform inputs before passing them into sub-agent prompts. Audit Trails: Log every agent-to-agent delegation event in Dataverse with execution timestamps, latency, and token consumption metrics. 7. Implementation Checklist Audit Your Current Bot: Identify topics with high trigger overlap and cluster them by business domain. Define the Supervisor Contract: Standardize a JSON schema for user identity, intent, and parameter passing. Build Your First Worker Agent: Start with a high-volume, bounded domain like IT Service Desk or Password Management. Implement Tool Calling: Register the worker agent as a callable action inside your front-door supervisor. Test Edge Cases: Validate that multi-turn dialogs maintain context and unknown intents gracefully route back to human triage. Join the Discussion Have you implemented multi-agent architectures in your tenant? How are you handling state transfer and DLP across specialized bots? Share your thoughts and architectural questions in the comments below!The CISO Cheat Sheet to Microsoft Digital Defense Report 2026
I know we’re all busy, so I’ve pulled the most important data from this year’s Microsoft Digital Defense Report into one short read. The full report is well worth exploring, but this article focuses on the numbers and trends most relevant to security leaders. This year’s edition shows that AI is lowering the time, expertise and cost required to discover and exploit weaknesses, enabling attackers to operate with greater speed, scale and autonomy. The report describes this as AI “changing the physics of cybersecurity”: attack timelines are compressing and agentic systems are beginning to automate more of the attack lifecycle. Trend 1: Time has collapsed The clearest finding is about speed. Vulnerability discovery is increasingly running ahead of remediation, while the time from discovery to weaponisation is shrinking. In the AI era, weaponisation can follow in hours. Vulnerability discovery and weaponisation now often needs only a well-written prompt. The median time from discovery in the wild to weaponisation is below 24 hours. Vulnerabilities were on track for a record estimated 72,000 CVEs in 2026. The report expects a multi-year period in which the number of known but unpatched vulnerabilities rises sharply before eventually declining. The median time from container start to first exploit attempt is 5.3 hours. The ransomware actor Storm-1175 moved from web-facing exploitation to deploying Medusa ransomware in as little as 24 hours. CISA added over 110 CVEs to its Known Exploited Vulnerabilities catalogue between November 2025 and May 2026, most within a week of disclosure. The mismatch with enterprise reality is the uncomfortable part. The report says the disclosure-to-exploitation window has shrunk to single-digit days. Between November 2025 and May 2026, CISA added more than 110 vulnerabilities to its Known Exploited Vulnerabilities catalogue, most within a week of disclosure. In one example, Storm-1175 moved from exploiting a web-facing vulnerability to deploying Medusa ransomware in as little as 24 hours. Microsoft’s Red Team makes an important point: a patch is also a disclosure. Every fix points attackers towards the flaw it closes. As AI-assisted analysis makes reversing patches faster and more reliable, the report argues that patch velocity, not simply patch availability, becomes the control that matters. Trend 2: Attack chains are gaining autonomy The report charts a clear progression: September–November 2025: AI assists in orchestrating a campaign, as in the Anthropic-reported espionage case. April–June 2026: Full-chain autonomy is demonstrated in labs. July 2026: Real-world autonomous attacks of increasing complexity appear. Two frontier models, Mythos and GPT-5.5, completed a 32-step attack chain against an emulated enterprise with no human help. The test environment had no defenders. The UK AI Security Institute reached a similar finding independently. GPT-5.5 was the second model to solve its end-to-end corporate network attack simulation, a task AISI estimates would take a human about 20 hours. Open-weight models lag closed models at orchestrating attacks by about seven months. In the wild, early July 2026 saw the first documented automated ransomware extortion attack, named JADEPUFFER by Sysdig. Microsoft has seen AI-orchestrated intrusions that share elements with it. Initial access consistently came from internet-exposed services running known-vulnerable software. The report is measured on this point. Volumes of AI-orchestrated activity remain low. In most observed real-world operations, complex end-to-end intrusions still retain meaningful human direction. The Red Team's framing is the most useful one: AI doesn't create a new class of attack, it collapses the effort needed to find and exploit existing attack paths. Trend 3: AI has become an attack surface The report's second takeaway is that attackers are already targeting AI itself. The adoption numbers explain why. 88% of enterprises are experimenting with agents, and 82% of leaders plan broader rollouts within 12–18 months. The report cites industry projections of roughly 1.3 billion agents in production by 2028. What attackers are doing to AI systems: Four techniques accounted for roughly 90% of observed attack activity in telemetry from Azure AI workloads: malicious link injection (52%), jailbreaks (16%), tool and agent abuse (12%), and identity and credential abuse (10%). Memory poisoning: An attacker who can place content anywhere an agent reads can often place it where the agent remembers. Email is the dominant pathway the Red Team has observed. Human-in-the-loop isn't a complete control: Red team testing saw approval prompts ignored, or bypassed by a policy stored in poisoned memory. Developer tools turned against their owners: The "s1ngularity" malware hijacked locally installed AI command-line tools to hunt for secrets. It leaked about 2,000 secrets and 20,000 files across 225 victims. AI browsers: In daily use at more than 40% of organisations in Microsoft's dataset, they were the initial infection vector in incidents involving 57 malware families in a May 2026 analysis. Chat histories as a target: Malicious AI-assistant extensions reached nearly 900,000 installs and more than 20,000 enterprise tenants, harvesting AI chat histories that often contain code, architecture and credentials. The identity implications are direct. Each agent needs its own identity, not one borrowed from an employee, and a named human sponsor. The report also treats revocation latency, the time to cut off a compromised agent, as a measured outcome. Trend 4: The front door is still identity AI changes the speed and personalisation of social engineering. It hasn't changed where attacks start. Initial access in Defender Experts data: User execution: 30% Valid accounts: 20% Malicious copy-and-paste: 13% Phishing: 11% Together, user execution and valid accounts account for over half of observed activity. In incident response engagements, phishing as an initial access vector jumped from 7% to 23% year on year. The standout numbers: ClickFix: Defender saw user-pasted malicious commands on more than 1.1 million unique devices between February and early May 2026, roughly an 8x increase. AiTM: URLs accounted for 45% of the identified phishing techniques in the report’s breakdown. Separately, the share of AiTM phishing and token-theft attacks more than doubled during the first six months of 2026, although the report notes that their overall share remained comparatively small. Teams vishing: Weekly confirmed malicious volume increased 502% year on year. Per attempt, 48% of vishing calls kept the victim engaged for more than 20 seconds, and 30% lasted more than one minute. When a call succeeds, attackers can persuade the victim to install a remote-management tool and complete reconnaissance in two minutes or less. Business contact impersonation (BCI): The report introduces this term for conversations that start with a trusted-looking contact. Microsoft detected more than 46 million attacks in 12 months, with a 121% spike in April 2026. The share of first-contact messages that explicitly asked for money or documents fell from 17% to 3%. The first message is deliberately bland, like "Are you at your desk?" Password attacks declined 26% year on year, which the report describes as strong evidence that MFA and passkeys are forcing attackers to pivot. That pivot includes techniques such as fatigue attacks, AiTM phishing and token theft designed to circumvent conventional MFA. Trend 5: Attackers are inheriting trust rather than breaking in The report's headline theme is that risk is increasingly interconnected. Threats travel through the trusted relationships between identities, software supply chains, partners and cloud platforms. The numbers: Supply chain: Major open-source ecosystems saw attacks roughly every ten days, accelerating through Q2 2026. Shai-Hulud 2.0 affected 25,000 repositories. Megalodon backdoored 5,561 GitHub repositories in under six hours. Trusted signing: In May 2026, Microsoft disrupted Fox Tempest, a "malware-signing-as-a-service" operation that obtained genuine certificates for ransomware loaders and infostealers. Microsoft revoked over a thousand fraudulent code-signing certificates. Legitimate access: An unsanctioned remote monitoring tool is now one of the most reliable mid-stage indicators of a human-operated intrusion. Cloud identity: Cloud identity abuse was the most observed technique against critical infrastructure, representing 78% of the technique mix in Microsoft’s data for March to June 2026. Hybrid intrusions: The Storm-2885 case showed an attacker using a privileged cloud identity to close and downgrade security alerts. The report says identity governance and alert-handling workflows deserve Tier 0 treatment. Dwell time: DART data shows a statistically significant increase in dwell time year on year, meaning organisations took longer to detect intrusions. Ransomware shows the same ecosystem pattern. Qilin led leak-site data with 16.4% of victims, up 386%. Defender detections tell a different story, with Akira at 22%. Trend 6: Defence works best when it's connected The report is not only a catalogue of threats. The strongest defensive evidence: Disruption works. Following the March 2026 disruption, Tycoon2FA activity had fallen 95% from its November 2025 peak by June. Its share of CAPTCHA-gated phishing declined from 76% in December 2025 to 12% in June 2026. Correlation is the highest-leverage variable. The report argues that how well defenders share and correlate signals across endpoint, identity, cloud, email and network is one of the highest-leverage strategic variables under their control. AI is also changing defensive operations. The report describes AI-assisted triage, incident summarisation, hunting-query generation and detection engineering as ways to accelerate investigations and allow analysts to concentrate on higher-value work. Automated disruption can compress response time. The report says that when a correlated incident reaches a defined confidence threshold, defensive systems can automatically isolate devices, disable compromised accounts, revoke sessions or quarantine affected cloud resources. It also stresses the importance of appropriate governance and human oversight for high-risk AI actions. The report also recommends changing what leaders measure. It suggests moving from patches deployed to exposure reduced, detection coverage increased and time-to-mitigate compressed. What the MDDR recommends: ten security priorities The report starts its recommendations with the foundations: Secure by Design, Secure by Default and Secure Operations, applied through identity-centric Zero Trust. Microsoft says these keep the priorities below durable as AI adds more identities, applications, agents and dependencies to govern. Govern cyber risk at leadership level. Report identity exposure, patch latency, agent permissions, critical dependencies, dwell time and recovery readiness to the board. Defend identity as the primary control plane. Deploy passkeys and phishing-resistant MFA, reduce privilege and govern human and non-human identities. Invalidate and rotate tokens and session credentials quickly. Establish governance, visibility and data controls for AI. Keep visibility of approved AI tools, services and agents, and monitor for unauthorised or unmanaged use. Apply sensitivity-aware access and data protection to the data those systems can reach. Reduce exposure and edge risk. Continuously discover internet-facing assets and patch edge devices quickly. Centralise high-fidelity logging, enforce strong authentication and combine network visibility with threat intelligence. Focus on cross-signal correlation. Correlate endpoint, identity, cloud, application, email and network signals to detect intrusions earlier. Correlation also helps defenders anticipate attack paths and likely targets. Enact a continuous threat and vulnerability management model. Combine asset visibility, vulnerability identification, threat detection and AI-accelerated insight into a single continuous programme. Validate exposure through proactive testing. Run assume-breach exercises on cloud services, SaaS platforms, APIs and workflow automation. Prioritise them by where your highest-value data is stored, accessed or aggregated. Secure software dependencies. Harden software installation, keep a software inventory and validate provenance. Monitor packages and prepare for rapid containment. Participate in collective defence. Share actionable threat indicators and victim-informed intelligence with trusted partners and law enforcement. This supports coordinated tracking, investigation and disruption. Prepare for long-horizon technology transitions. Build a cryptographic inventory and advance post-quantum planning alongside AI governance. Read together, the numbers tell one story: the attacker’s workflow is becoming faster and less expensive. AI can shorten vulnerability discovery, exploitation, secret discovery and lateral movement, while organisations still face the slower operational work of testing, coordinating and deploying safe changes across complex environments. At the same time, agent identities can proliferate faster than organisations can inventory, govern and revoke them The defining question for boards today is not whether disruption will occur, but whether the organization can continue operating, contain harm, recover quickly, and maintain trust when it does. Source: Microsoft Digital Defense Report 2026, Version 1.1. Reporting period: July 2025–June 2026.
Introducing the Power Platform Admin Plugin in Cowork: Agentic Governance with Natural Language
Explore agentic Power Platform governance with the Power Platform admin plugin in Copilot Cowork. Ask questions about your tenant and turn governance insights into customized reports, dashboards, and apps.Copilot Studio custom MCP connector: server-verifiable identity of the calling agent?
I am evaluating a Copilot Studio agent calling a custom MCP connector with delegated Entra authentication and client federation. The private pilot uses a synthetic catalogue. In my published PALO Framework, the governance model binds the admitted identity, time-bound mandate and exact proposed action before execution: https://paloframework.org/PALO_AIGovernance.html . The point I want to clarify is how far that identity binding can go for the originating Copilot agent. I read the Microsoft guidance on agent identities: https://learn.microsoft.com/en-us/microsoft-copilot-studio/govern-agents-identities-overview . An Agent ID in the registry and a connector client identity are different evidence. In our documented pilot, the delegated token admission and the Copilot tool trace are checked separately; I do not treat the connector client ID alone as cryptographic proof of the originating agent. For this custom-connector path, is there a supported claim or signed attestation that a remote MCP server can validate to bind each call to the specific Copilot Studio agent? I would appreciate the documented validation rules and whether the test pane and published channels differ. If this is not supported on this path, which supported isolation pattern would you use for separate agent mandates? This is a design question from an evaluation pilot, not a production capability claim.
You don't have access to talk to this bot, contact the owner. copilot studio
I created a copilot studio agent and then embedded it inside a code app. It works fine but i am facing the below error. You don't have access to talk to this bot, contact the owner. copilot studio I have provided Microsoft based authentication and am an owner so will have access to the bot. Yet facing the above issue. Is there something i am missing
Large OS Disk Encryption is now generally available for Azure Confidential VM migrations
Today, we are excited to announce the General Availability of Large OS Disk Encryption (LOSDE) for Azure Confidential VM migration scenarios. This capability removes a key adoption barrier for customers migrating sensitive workloads to Azure Confidential Virtual Machines by enabling encryption for operating system disks larger than 127 GB. With LOSDE, organizations can securely migrate larger, more complex workloads to Azure to enable the confidentiality protections provided by Azure Confidential Computing. Why this matters For many enterprises, migrating existing workloads to the cloud is not simply a matter of redeployment. Business-critical applications often rely on large operating system disks and established operational configurations that must be preserved during migration. Until now, customers migrating workloads with operating system disks larger than 127 GB faced limitations when attempting to bring those workloads into Azure Confidential VMs while preserving confidential computing guarantees. This created an adoption challenge for organizations operating highly regulated or security-sensitive environments. Large OS Disk Encryption addresses this gap by extending encryption support to larger operating system disks during migration workflows. With LOSDE, customers can: Enable upgrading virtual machines to Azure Confidential VMs through the migration process. Migrate workloads with OS disks larger than 127 GB to Azure Confidential VMs. Continue to use customer-managed keys (CMKs) aligned with their security and compliance requirements. Support migration scenarios for Windows, Ubuntu, Red Hat Enterprise Linux, and Rocky Linux. Check the Azure Migrate documentation for the support list. Accelerate adoption of Azure Confidential Computing for existing enterprise environments. Simplifying secure migration to Azure Confidential VMs The Large OS Disk Encryption feature integrates seamlessly into Azure migration workflows, enabling customers to move existing workloads into Azure Confidential VMs while continuing to benefit from hardware-backed protections and the trusted execution environment capabilities of Azure Confidential Computing. LOSDE helps close that gap by enabling customers to bring existing workloads into Azure Confidential Computing environments while preserving the confidentiality guarantees required for regulated, critical, and sensitive applications. The solution offers automation with Azure Migrate , enabling Windows, Ubuntu, RHEL, and Rocky Linux workloads to be encrypted while preserving the confidentiality guarantees of Azure Confidential Computing and supporting customer-managed keys (CMKs). The result is a simpler path to cloud modernization, stronger protection for data in use, and expanded adoption opportunities for Azure Confidential Virtual Machines . This work reflects Microsoft's ongoing commitment to making advanced security capabilities easier to adopt without increasing operational complexity.
Agent Credit Limits and Alerts - Copilot Studio
Hi everyone, We're evaluating the use of Agent Credit Limits and alert notifications in the Power Platform Admin Center as a way to control unexpected Copilot Credit consumption. Recently, we had an agent consume 668k Copilot Credits in just 3 days, which raised concerns about how quickly usage can grow before administrators become aware of it. My questions are: How frequently is Copilot Credit consumption evaluated against an agent's credit limit? Are alert notifications generated in near real-time, or are they dependent on the same reporting pipeline used by the consumption reports? If an agent reaches its configured credit limit, is it automatically turned off or blocked from further consumption? Given that consumption reports often appear to refresh hours later (or even the next day), can alerts also be delayed? If there is a reporting delay, is there a risk that an agent could significantly exceed the intended limit before administrators receive a notification? What is the recommended approach for preventing large unexpected consumption spikes in production? Has anyone successfully implemented a governance model that provides more immediate protection against runaway usage, or are the current credit limits and alerts primarily intended for retrospective monitoring? Thanks in advance for any guidance.MCP action approvals after expiry: review and replay tests from a Copilot Studio pilot
I am testing an approval and recovery pattern for a Copilot Studio agent calling a custom MCP endpoint on Azure. I would appreciate feedback on the failure cases to add before qualifying the approved execution and replay path. Context I built PALO, an independent governance project. This private pilot uses a synthetic catalogue with one price and resource version. Microsoft Entra supplies delegated identity; the runtime checks the admitted caller, delegated scope, time-bound mandate and exact proposed action. The connector uses federated authentication without a client secret. A separate reviewer interface records decisions; approval itself does not write the catalogue. Observed cases • The actual Copilot test agent invoked a catalogue read and returned price 100/version 1. • Proposal 151/version 1 was denied, with zero target writes confirmed independently in persistent records. • Proposal 120/version 1 required review and expired without execution. • We reproduced a withdrawal defect for the expired-approval state. The correction permits withdrawal in that state only when the action claim has also expired, while preserving the authorization, version and unresolved-effect checks. The same 89-test suite passed locally and on Azure Linux, followed by a reviewer withdrawal confirmed in UI and persistent records. Lessons so far 1. A connection shown as configured did not qualify the consuming-agent path. We retained the actual tool-call trace and checked target state separately. 2. MCP media negotiation mattered: the connector request Accept policy needed application/json and text/event-stream. 3. The five-minute action-claim validity, approval record lifetime and authentication freshness are different clocks. An expired request must not be silently renewed or automatically resubmitted. Next qualification gate We still need one fresh linked successor, a new reviewer decision, execution of that exact request, independent verification of one target effect, and a replay with no second effect. Two identities are operated by the same person in this pilot, so this only tests technical role separation. Incremental benefit over native identity, workflow and logging controls has not yet been measured. Questions for builders • Which expiry, revocation, concurrent-update or ambiguous-outcome cases would you prioritize before approving the live execution and replay test? • What native-control baseline would make an incremental-value comparison credible? Configuration record and dated evidence: https://paloframework.org/docs/palo-azure-copilot-pilot.html Two-minute report, narrated with my own voice: https://youtu.be/cfkms-cWp-I Disclosure: I built PALO. This is a private synthetic-data pilot, without a Marketplace listing or Microsoft certification. AI assisted the drafting and technical review; claims were checked against retained pilot records. The post requests engineering feedback rather than announcing production readiness.Microsoft Foundry Guardrails Getting in Your Way? Here’s How to Dial Them Down
How This All Started So here’s the story. I just got back from a trip and had a pile of footage sitting on my laptop. Being the lazy (sorry, efficient) person I am, I fired up OpenCode and asked GPT-6 Astra, running on Microsoft Foundry, to cut me a travelogue. Nothing fancy: under two minutes, nice lighting, clean transitions, no cringy effects, a quick QA before showing me, and the output in its own folder. Easy, right? Nope. This is what I got instead: “Image processing blocked due to content policy violation.” Seriously? It’s holiday footage! Nothing even remotely dodgy in there. This is a classic false positive from the default guardrails, and the good news is it’s totally fixable. Let me show you how. My Setup Quick context before we dive in: I’ve got two models deployed on Microsoft Foundry, gpt-6-astra and gpt-6-sol. Both were running on Microsoft’s out-of-the-box guardrail. Step 1: Find the Guardrails Page Head over to the Microsoft Foundry portal, click Build, then hit Guardrails in the left menu. You’ll see three guardrails that Microsoft gives you by default: Microsoft.Default, Microsoft.DefaultV2 and Microsoft.MAIDefault. Microsoft.DefaultV2 is the one every new deployment gets, which is why it’s sitting on both of my models. Here’s the catch: you can’t edit or delete these Microsoft-managed defaults. So instead of tweaking them, we’re going to build our own guardrail and swap it in. Step 2: Create Your Own Guardrail Smash that "Create" button and you’ll land on the Create guardrail page. This is where all the knobs and switches live: Every control has three bits: the risk type, the intervention point (does it check what you send in, what the model spits out, or both?) and the action. The magic trick for loosening things up is flipping the action from Block to Annotate. With Annotate, Foundry still scans the content and tags it in the API response, but it stops slamming the door on your request. So What Does Each Setting Actually Do? Before you go on a switching-off spree, it’s worth knowing what each of these does and what you’re giving up when you loosen it. Here’s the quick tour: Jailbreak: This one catches prompts trying to trick the model into ignoring its rules. On Block, those prompts get rejected outright. On Annotate, they go through with a flag. Turn it off completely and you’re trusting the model’s own training to keep it in line. Network (egress rules): Controls which outbound calls a hosted agent is allowed to make. As the portal points out, it only applies to hosted agents, so for plain model deployments like mine it doesn’t change a thing. Indirect prompt injections: Watches user input and tool responses (files, docs, web pages the model reads) for sneaky instructions someone has planted. Leave it on and your agents are protected when they read outside content; switch it off and a dodgy file could quietly hijack your model. For an agentic tool like OpenCode, which reads files and runs shell commands, I’d honestly keep this one on, even if it’s just on Annotate. Spotlighting (Preview): Tags external content inside the prompt so the model can tell your real instructions apart from random untrusted data. Think of it as an extra seatbelt against indirect attacks. Content harms (Hate, Sexual, Self-harm, Violence): Each of these has a severity slider that starts at Medium blocking, meaning anything rated medium or higher gets blocked. Slide it down to Lowest blocking and only the really nasty stuff gets stopped, which kills off most false positives like mine. The asterisk means these four are mandatory: you can turn the dial down, but you can’t switch them off. Blocklists: Want to ban specific words or phrases, like profanity or your competitor’s name? This is where you do it. It’s off by default. Protected material for code and text: Checks whether the model is about to spit out known copyrighted text (song lyrics, articles and so on) or code lifted from public repos. Block stops it; Annotate lets it through with a flag. Switch it off and you’re rolling the dice on your app reproducing someone else’s copyrighted work. Step 3: Pick Your Models Hit Next and Foundry asks which agents and models you want this guardrail on. Any model you’ve already deployed in your project shows up here. For me that’s gpt-6-astra and gpt-6-sol, so I ticked both. Step 4: Name It and Pick a Streaming Mode One more Next and you’re on the Review page. Give your guardrail a name (I went with NoGuardrails, because subtlety isn’t my thing) and pick a streaming mode. You’ve got two choices: Default: Foundry buffers the response and runs it through the guardrail before each chunk goes out. Nothing reaches the user until it’s been checked. Safest option, but you’ll feel a bit of lag when streaming. Asynchronous: Content streams back the moment it’s generated, with the filters running in the background. Much snappier, but flagged content might flash up briefly before the filter catches it, so your app has to clean up after the fact. Microsoft pitches this for low-latency stuff like internal dev tools, which is exactly my use case. Give the summary a quick once-over, then click Create. Done! Did It Work? Yep! With my shiny new guardrail in place, I fired off the exact same request, this time to GPT-6 Sol. And boom: no more content policy error. The model went straight to work scanning my footage and putting the video together. Wrapping Up Look, Microsoft’s default guardrails are a solid starting point, but they can be a bit trigger-happy when you’re doing perfectly legit stuff like video editing, creative work or internal tooling. Since you can’t touch the defaults, the trick is to roll your own: flip Block to Annotate where it makes sense, drag those content harm sliders down, pick the streaming mode that fits your app, and assign it to your deployments. That’s it! One friendly word of warning though: with great power comes great responsibility. Only loosen what you actually need, keep things like indirect prompt injection detection switched on for any agent that reads files or browses the web, and think twice before doing this on anything customer-facing. And if you want to go further than the portal lets you, like switching content filters off completely, you’ll need to apply to Microsoft for approval first. Happy building!Managing apps built in Copilot Studio
Last week we announced app building in Copilot Studio and Copilot Cowork. Makers can now describe business outcomes and produce full-stack apps with built-in source control, deployment stages, and version isolation—all on Microsoft-hosted infrastructure that requires no infrastructure provisioning, hosting configuration, or deployment pipeline. With those capabilities built in, your administrative scope is narrower and more familiar. Apps are created in the maker's personal developer environment following the environment routing policies you already have. That means things like connector permissions and data policies apply to an app both while it is being built and after it is published. Apps also access connected data on behalf of the signed-in user, which means publishing or sharing an app never grants anyone access to data they could not already reach. With these new capabilities, there are three things that every admin should be thinking about: Review your app estate Control cost with credit caps Choose where makers can build apps Review your app estate Published apps are inventoried in the Microsoft 365 admin center. Each app shows: Who built it Its lifecycle state Which data sources and connectors it uses Which policies apply to it Usage and operational metrics From the same experience, you can also block or disable a published app, remove a connector, bring an app back within policy, control whether it can be shared, and retire apps that are no longer used. Control cost with credit caps Building and running apps are both charged through Copilot Credits usage-based billing, and are metered as two separate services. This distinction lets you manage maker cost and app runtime cost independently. Build consumption varies with the language model used, the complexity of the app, and how much iteration is involved. Runtime consumption, on the other hand, varies with the volume and complexity of the tasks the app processes. At runtime, if the user holds a Power Apps Premium license, usage is included within existing request limits. Beyond those limits, or without a license, usage bills through Copilot Credits. You can learn more by reviewing the Copilot Credits licensing guide. As an admin, you can define credit cap policies to manage your costs. For both maker and runtime usage, caps are set per user, and the controls are managed through usage-based billing. For makers, think of a cap as a per-user budget: you can set the same budget for everyone, or different budgets for groups of users, such as departments that carry separate budgets of their own. Choose where makers can build apps By default, app creation is available to all users in both Copilot Studio and Copilot Cowork. However, you may want to limit where people can build apps. To do so: In the Microsoft 365 admin center, navigate to Apps, then Overview, and find ‘Choose where people can make apps’. Two paths appear: Copilot Studio, where makers build directly, which is on by default and recommended Copilot Cowork, where people create apps through chat, with availability managed by your organization's participation in the Frontier program Note that turning a path off prevents new apps being created that way. However, apps that are already published through that path will continue to run. Key takeaways for managing apps built in Copilot Studio The Microsoft 365 admin center is the one place to review the app estate, adjust app policies, and decide which creation paths stay open. Set credit caps as per-user budgets today, uniformly or by group, and plan for environment-level caps as project budgets when they arrive. Decide who is accountable for overseeing published apps before makers start publishing, as you would for any other application estate. Go to the Microsoft 365 admin center
