In our previous post, we mapped where exposure can exist when organizations deploy Microsoft 365 Copilot and grouped those risks into two layers. Layer 1 focused on who can access Copilot—the identity and device conditions that determine whether a user can reach the service.  

If those identity and device conditions are weak, exposure may extend beyond a single workload across the user’s entire Microsoft 365 data surface. This post shifts from mapping risk to reducing it. 

Each of the six Layer 1 risks (R1–R6) is governed primarily by the identity and endpoints pillars of Zero Trust. The good news: customers with Microsoft 365 E5 already own the controls required to address these risks, including Microsoft Entra ID, Conditional Access, Microsoft Intune, and Microsoft Defender. The next job is configuring and scoping them deliberately before scaling deployment.

How to read this post 

Each section recaps one risk, describes the mitigation, names the Microsoft control that delivers it and indicates where to capture the supporting screenshot. These controls are additive. Conditional Access ties identity and device signals together, so several mitigations reinforce one another. 

R1—Unmanaged identity access 

Pillar: Identity 

Because Copilot operates across the full scope of a user's permissions, a compromised, shared, or orphaned account exposes far more than it would have before. Mitigation starts with disciplined identity lifecycle management so that accounts exist only when they should and belong to real users. 

What to do: 

• Automate joiner, mover, and leaver processes with Microsoft Entra Lifecycle Workflows so accounts are provisioned, re-scoped, and disabled on schedule rather than manually. 
• Run recurring access reviews on Copilot-licensed groups to identify stale or unnecessary accounts.
• Eliminate shared and generic accounts; require an individual, attributable identity for every Copilot user.
• Block or remove dormant accounts and monitor sign-in activity for privileged identities. 

The following examples show lifecycle workflows and access review configuration: 

Figure: Lifecycle Workflows—leaver workflow showing account-disable tasks

 

Figure: Access reviews—review scoped to the Copilot users group

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

R2—Weak or absent multi-factor authentication 

Pillar: Identity 

If MFA is inconsistent—or legacy authentication bypasses modern sign-in controls—an attacker may need only a stolen password to open a Copilot session that synthesizes data across services. Closing this gap means enforcing strong authentication consistently and shutting down the protocols that route around it. 

What to do: 

• Require MFA for all users with a Conditional Access policy; use Microsoft-managed policies as a baseline, then tighten. 
• Move to phishing-resistant authentication methods, such as FIDO2 security keys, Windows Hello for Business, or certificate-based authentication.
• Block legacy authentication protocols that don't support modern MFA.
• Turn on Microsoft Authenticator number matching and additional context to help resist MFA fatigue attacks. 

Figure: Conditional Access—require multifactor authentication policy

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: Authentication methods—phishing-resistant methods enabled

 

 

 

 

 

 

 

 

 

 

 

 

 

R3—Unmanaged or noncompliant devices 

Pillar: Endpoints 

Users can reach Copilot from any device where they can authenticate. Without endpoint protection, encryption, and compliance evaluation, sessions and their outputs can be stored or exfiltrated from untrusted devices. Mitigation pairs device compliance in Intune with a Conditional Access policy that enforces it. 

What to do: 

• Define Intune compliance policies that require disk encryption, minimum OS versions, endpoint protection (EDR/Defender), and no jailbreak or root status. 
• Use a Conditional Access grant control that requires devices to be marked compliant, or hybrid Microsoft Entra joined before accessing Microsoft 365 and Copilot.
• Feed Microsoft Defender for Endpoint device risk signals into compliance evaluation, so high-risk devices fall out of compliance automatically. 

Figure: Intune compliance policy—encryption, minimum OS, and Defender requirements

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: Conditional Access—require device to be marked as compliant

 

 

 

 

 

 

 

 

 

 

 

 

 

R4—License sprawl without role-based scoping 

Pillar: Identity and apps 

Broad pilot enrollment—licensing whole departments or floors—is itself a risk factor because it grants Copilot access to both well-governed and minimally governed users without an access review. Mitigation makes licensing deliberate: a reviewed group assigned through policy after each member's access is checked. 

What to do:

• Assign Copilot through group-based licensing tied to a named, security-reviewed pilot group—not by department or location. 
• Run an access review on each pilot member's permission posture and role sensitivity before granting the license.
• Phase rollout in cohorts and consider Restricted SharePoint Search during the pilot to limit the grounding surface. 

Figure: Microsoft 365 admin center—Copilot license assignment count

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

R5—Missing real-time risk evaluation at sign-in 

Pillar: Identity and endpoints 

Static controls grant or deny access once; they don't react to a session that turns risky. If Conditional Access doesn’t evaluate sign-in and user risk signals—impossible travel, anomalous tokens, Identity Protection alerts—a high-risk session can still reach Copilot before anyone responds. Mitigation makes access decisions risk-aware in real time. 

What to do:

• Turn on Microsoft Entra ID Protection (included in E5) to generate user risk and sign-in-risk signals. 
• Create risk-based Conditional Access policies: require MFA or a secure password change on elevated risk, and block on high risk.
• Add token protection to bind sign-in sessions to the device and reduce token replay exposure. 

Figure: Conditional Access—user risk condition set

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: Identity Protection—risky sign-ins dashboard

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: Conditional Access—require token protection session control

 

 

 

 

 

 

 

 

 

 

 

 

 

R6—App protection gap on mobile devices 

Pillar: Endpoints and apps 

On personal phones that aren't enrolled in MDM, organizations still need to govern the app. Without an application protection policy, users can copy Copilot output into unmanaged apps, and data on a lost device can't be wiped. Mobile Application Management (MAM) protects corporate data inside the app without managing the whole device. 

What to do:

• Deploy Intune App Protection Policies (MAM) for iOS and Android: require an app PIN, encrypt app data, and allow selective wipe of organizational data. 
• Restrict data egress: block copy/paste and 'Save As' to unmanaged locations, and block screen capture where the platform supports it (Android).
• Pair with a Conditional Access grant requiring an approved client app and an app protection policy for mobile access. 

Figure: Intune app protection policies—iOS and Android policy list

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: App protection policy—data protection, block copy/paste, and “Save As”

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure: Conditional Access—require approved client app and require App Protection Policy

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Layer 1 mitigations at a glance 

Each Layer 1 risk maps to a primary control and the Microsoft tool that delivers it. Conditional Access recurs because it is where identity and device signals are enforced together. 

Securing Copilot access isn't only about who can sign in—it's about validating the devices, conditions, and access patterns behind every session. The six controls above close Layer 1 gaps before risky access patterns scale across the organization. 

Governing Microsoft 365 Copilot risk: Next steps 

Microsoft 365 Copilot security starts before a prompt is ever entered. Identity, device, and session controls help verify that the right people are accessing Copilot from trusted devices under the right conditions. Closing Layer 1 gaps reduces the likelihood that compromised identities, risky sign-ins, or unmanaged devices can access organizational data. 

Controlling who can access Copilot is the first step. The next challenge is governing what Copilot can access once a user is authenticated. Strong access controls reduce the chances that the wrong person reaches Copilot. Layer 2 focuses on a different question: if the right person signs in, what information can they discover, summarize, and use? 

In the next post of this series, we'll shift from access controls to data controls and explore how organizations can reduce Layer 2 risk through SharePoint and OneDrive permissions management, sensitivity labels, data loss prevention (DLP), connector governance, and auditing capabilities. 

Before expanding your Copilot deployment, review the six Layer 1 controls covered in this article and identify any gaps in your identity, device, and access policies. You can also use the Zero Trust Workshop to assess your current security posture and prioritize remediation efforts. 

When you're ready, continue to Post 3 in this series: Governing Microsoft 365 Copilot data risk to examine how data governance controls help limit exposure after authentication and strengthen secure Copilot adoption. 

We’re excited to introduce a major upgrade to Copilot in Microsoft Forms - now featuring seamless integration with a Microsoft 365 Copilot chat experience.

This new experience builds on the familiar Copilot interactions users already know from Word, Excel, and PowerPoint, while adding Forms-specific intelligence to help you create, refine, and analyze forms more effectively. Copilot works alongside your form to deliver tailored suggestions and refinements, help configure settings, prepare your form for distribution, and turn responses into clear, actionable insights – all within a chat pane that you know and use across the Microsoft 365 suite.

Using the new Copilot experience in Forms

When you create or open a form or quiz in Microsoft Forms, you’ll see the Copilot icon in the lower-right corner. This Dynamic Action Button works the same way across Microsoft 365 apps - select it to access contextual assistance, such as improving your questions or analyzing results right where you’re working. When you open the chat pane, Copilot is automatically grounded to your form, and able to access specialized Forms features to help you edit, send, and analyze.

Here are some examples of how chat can improve your workflow:

• Review and suggest improvements to your form such as organizational layout, sectioning, missing questions, or settings that may conflict with your form’s purpose - such as enabling anonymous response or multiple responses per user.
• Complete bulk edits like replacing a placeholder name with an updated one throughout the form, or changing multiple questions to required or not required.
• Ask about specific drilldowns or summaries you’re seeking from your form results, to help you understand your data and unlock your next action.

What’s new

This new experience merges the benefits of the familiar Copilot chat experience with Forms specialization, building on your feedback and introducing key improvements:

• Smarter suggestions & refinements: Get targeted recommendations to improve your form’s structure, clarity, and effectiveness. Copilot can also apply refinements directly to the form, so you can save time making edits – just describe what you want, and watch Copilot make it happen.
• Deeper analysis: Copilot can now analyze your results in-depth to provide clear insights and actionable takeaways for you and your team. You can even ask follow-up questions to help parse and summarize your data and unlock your next step.
• More settings: Review and update form settings with ease, such as applying custom thank-you messages and close dates, so your form is ready to send. You can also adjust question settings in bulk, such as making questions required.
• Open-ended chat: Copilot chat gives you access to a broad world of capabilities, whether you’re seeking inspiration on survey topics or consulting on how to configure your form – the possibilities are broad with Copilot at your fingertips.
• Basic branching: Apply basic branching logic directly through the agent. (Note that some complex scenarios are not yet supported, and you should continue to review your branching logic prior to sending your forms.)

And some features that you use and love today are not changing at all – such as Draft with Copilot and on-canvas Copilot features like Rewrite, Add question, Answer explanations for quizzes, and more. These will continue to help you work with your form directly in the canvas.

Availability

The new Copilot in Forms is rolling out to worldwide users now, and will be available to users with Microsoft 365 commercial Copilot licenses. Consumer Copilot subscribers will continue to see the previous Copilot experience in Forms for now, which includes a Copilot refinement bar that supports AI-credit-based Copilot licenses. To try it for yourself, go to Forms.

 

This episode tackles the growing pains of AI-assisted development, from the struggle of reviewing thousands of lines of agent-generated code to the mounting technical debt when teams merge PRs without meaningful human review. Scott and Wes also dig into local models, whether jujutsu really beats git, how freelancers should price work in the AI era, and getting your team on board with external libraries.

Show Notes

• 00:00 Welcome to Syntax!
• 00:45 Understanding AI-Generated Code
• 06:24 The Challenges of Code Review in AI Development
• 11:21 What the heck are local models?
  • CJ’s Guide to Local AI
• 16:09 Exploring New Tools: Jujutsu and Beyond
• 20:35 Exploring Version Control Innovations
• 22:18 Pricing Strategies in the Age of AI
• 24:52 webkit-box-reflect not in the browsers.
• 27:44 The Angular vs. React Debate
• 31:46 Sick Picks & Shameless Plugs.

Sick Picks

• Scott: Huggingface Reachy Mini Robot
• Wes: Bose QC35

Hit us up on Socials!

Syntax: X Instagram Tiktok LinkedIn Threads

Wes: X Instagram Tiktok LinkedIn Threads

Scott: X Instagram Tiktok LinkedIn Threads

Randy: X Instagram YouTube Threads

Download audio: https://traffic.megaphone.fm/FSI8647581568.mp3

Aliu Adewale: When Everything Is a "Must-Have," Nothing Is—Prioritization for Real-World Teams

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

 

"Every yes to something unimportant is a no to what matters." - Aliu Adewale

 

Aliu's current challenge isn't from his day job—it's from a volunteer project for his local Parent-Teacher Association. The group wants to build a centralized app for school announcements, PTA updates, volunteer coordination, event reminders. The first meeting produced 250 ideas, all of them framed as must-haves, all of them needed before school resumes. The window: three months. Vasco names two traps that most Scrum Masters fall into. First, MoSCoW and similar frameworks aren't prioritization—they're categorization. The moment everything ends up in the "must" bucket, you're still stuck. Second, prioritizing a feature list assumes features are independent. They almost never are: a login blocks a dozen things downstream; front-end depends on back-end; dependencies decide the order more than desirability does. Aliu's experiment with the PTA group is a focusing constraint: stop asking "what do we need this year?" and start asking "what do we need in the first three months when school resumes?" The 50-item must-have list collapsed to five or six features. Vasco pushes it further with his own favorite question: "What's preventing us from releasing tomorrow?" That's the question that exposes what really matters—and it almost never returns a list of features.

 

Self-reflection Question: If your team had to release tomorrow, which of your "must-haves" would you actually need?

 

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

 

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

 

Buy Now on Amazon

 

[The Scrum Master Toolbox Podcast Recommends]

 

About Aliu Adewale

 

Aliu is an Agile Delivery Lead with over 10 years of experience empowering teams to unlock their potential and deliver meaningful value. As an author, Aliu simplifies Agile principles through real-life experiences, providing practical insights for professionals to apply Agile methodologies effectively in work and everyday life.

 

You can link with Aliu Adewale on LinkedIn.

 

You can also find Aliu and his book on agileinplainsight.com.

Download audio: https://traffic.libsyn.com/secure/scrummastertoolbox/20260708_Aliu_Adewale_W.mp3?dest-id=246429

Python’s agent-framework-orchestrations package is now 1.0.0. That puts Microsoft Agent Framework’s orchestration layer at 1.0 across Python and .NET.

Sequential, concurrent, group chat, handoff, and magentic orchestration are now stable in both SDKs. You can pick the coordination pattern that fits your problem instead of choosing around SDK maturity.

Magentic is the best example of why that matters. It is the least hand-wired pattern: you give it a goal, a manager, and a set of specialists, then the manager decides how the team should work.

At the workflow layer, Agent Framework lets you build the graph yourself. Executors do the work, edges route messages, and the workflow emits events as it runs. Those are the low-level primitives. The workflow docs cover that model in more depth.

The orchestration builders sit one level above those primitives. They use the same workflow model internally and return ordinary workflows you can run, stream, and compose.

That matters because coordination is the part many multi-agent apps otherwise reimplement. You choose the next agent, carry state between turns, detect stalls, and decide when the work is finished.

Magentic moves that coordination into the orchestration. A manager agent turns the task into a plan, assigns work to specialists, checks progress after each round, and revises the plan when the team stops moving.

The code below uses MagenticBuilder to create a workflow without wiring that graph by hand. You still choose the participants and guardrails, but the manager owns the round-by-round coordination.

import os

from agent_framework import Agent, AgentResponseUpdate
from agent_framework.foundry import FoundryChatClient
from agent_framework.orchestrations import MagenticBuilder
from azure.identity import AzureCliCredential

client = FoundryChatClient(
    project_endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
    model=os.environ["FOUNDRY_MODEL"],
    credential=AzureCliCredential(),
)

researcher = Agent(
    name="Researcher",
    description="Finds and gathers information",
    instructions="You research. You do not do quantitative analysis.",
    client=client,
)
coder = Agent(
    name="Coder",
    description="Writes and runs code to analyze data",
    instructions="You answer quantitative questions by writing and running code.",
    client=client,
    tools=client.get_code_interpreter_tool(),
)
manager = Agent(
    name="Manager",
    description="Coordinates the team",
    instructions="You coordinate the team to finish complex tasks.",
    client=client,
)

workflow = MagenticBuilder(
    participants=[researcher, coder],
    manager_agent=manager,
    max_round_count=10,
    max_stall_count=3,
    max_reset_count=2,
).build()

task = (
    "Compare the training and inference energy use of ResNet-50, BERT-base, "
    "and GPT-2, estimate the CO2 for each, and recommend the most efficient "
    "model per task type."
)

async for event in workflow.run(task, stream=True):
    if event.type == "output" and isinstance(event.data, AgentResponseUpdate):
        print(event.data.text)

The manager reads the task, decides the researcher should pull numbers first, hands the coder the math, checks a progress ledger each round, and synthesizes the final answer.

If the team stops making progress, the manager can reset and replan. The max_* values are the guardrails you set. Everything between the goal and the answer is the manager’s call.

More than magentic

Magentic is the sharpest example, but the release is broader. Handoff gives you routed specialist teams. Group chat gives you moderated collaboration. Sequential and concurrent cover pipelines and fan-out/fan-in work.

All of those orchestration patterns now have the same stable footing in Python and .NET. That matters when you are standardizing how agents work across services, teams, or languages.

Because the builders produce workflows, they do not close off the lower-level APIs.

If your team needs a different shape, take the parts that fit and build a custom workflow from the same primitives.

Try magentic on a task you would not trust to a hand-wired pipeline. Try handoff when the routing rules matter. Try sequential or concurrent when the workflow should stay deterministic.

Then tell us where the patterns fit, where they break, and what still feels too hard. Open an issue on GitHub when something is missing or surprising; that feedback shapes what comes next.

Get started with the magentic orchestration docs.

The full samples on GitHub show the other orchestration patterns too.

The post Agent Framework’s Orchestration Patterns Reach 1.0 appeared first on Microsoft Agent Framework.

Ryan is joined by Rosemary Wang, Developer Advocate at IBM, to explore what infrastructure as code looks like once AI starts writing and deploying it. ​​​​‌‍​‍​‍‌‍‌​‍‌‍‍‌‌‍‌‌‍‍‌‌‍‍​‍​‍​‍‍​‍​‍‌​‌‍​‌‌‍‍‌‍‍‌‌‌​‌‍‌​‍‍‌‍‍‌‌‍​‍​‍​‍​​‍​‍‌‍‍​‌​‍‌‍‌‌‌‍‌‍​‍​‍​‍‍​‍​‍‌‍‍​‌‌​‌‌​‌​​‌​​‍‍​‍​‍‌‍​‌‍‌‌​​‍‍‌​‌‌​‌‍​‌‌‍​‌‍‍‌‍‌‌‍‌‍‌‌‌​‍‌‍‌‍‌‍​‌‍‌‌​‍‍‌‍​‌‍​‍‌‍‍‌‌‍‍‌‌​‌‍‌‌‌‍‍‌‌​​‍‌‍‌‌‌‍‌​‌‍‍‌‌‌​​‍‌‍‌‌‍‌‍‌​‌‍‌‌​‌‌​​‌​‍‌‍‌‌‌​‌‍‌‌‌‍‍‌‌​‌‍​‌‌‌​‌‍‍‌‌‍‌‍‍​‍‌‍‍‌‌‍‌​​‌​‌‌‍‌‌‌‍​‍‌‍‌​​‌​‌‍‌‍‌​​​‍​‍‌‌‍​‌‍‌‌‌‍​‍‌‍​​‍‌​‌​‌‍​‍​‍​​‍​​‍‌​‍​​​‍‌‍‌‍​‍‌​‍‌​​‌‍‌​‌‍‌‍‌‍​‍​​‍‌‍​​‍​‌‍​‍‌‍​​‌‌‌‍​‌‍​‌​‍‌‌​‌‍‌‌​​‌‍‌‌​‌‌‍​‍‌‍​‌‍‌‍‌‌‌​​‌‍‌​‌‌​​‍‌​​‌‍​‌‌‌​‌‍‍​​‌‌‍‌‌‌‍​‌‍​‌‍‌‌‌​‍‌​​‌‌​​‌‍​‍‌‍​‌‌​‌‍‌‌‌‌‌‌‌​‍‌‍​​‌‌‍‍​‌‌​‌‌​‌​​‌​​‍‌‌​​‌​​‌​‍‌‌​​‍‌​‌‍​‍‌‌​​‍‌​‌‍‌‍​‌‍‌‌​​‍‍‌​‌‌​‌‍​‌‌‍​‌‍‍‌‍‌‌‍‌‍‌‌‌​‍‌‍‌‍‌‍​‌‍‌‌​‍‍‌‍​‌‍​‍‌‍‌‍‍‌‌‍‌​​‌​‌‌‍‌‌‌‍​‍‌‍‌​​‌​‌‍‌‍‌​​​‍​‍‌‌‍​‌‍‌‌‌‍​‍‌‍​​‍‌​‌​‌‍​‍​‍​​‍​​‍‌​‍​​​‍‌‍‌‍​‍‌​‍‌​​‌‍‌​‌‍‌‍‌‍​‍​​‍‌‍​​‍​‌‍​‍‌‍​​‌‌‌‍​‌‍​‌​‍‌‍‌‌​‌‍‌‌​​‌‍‌‌​‌‌‍​‍‌‍​‌‍‌‍‌‌‌​​‌‍‌​‌‌​​‍‌‍‌​​‌‍​‌‌‌​‌‍‍​​‌‌‍‌‌‌‍​‌‍​‌‍‌‌‌​‍‌​​‌‌​​‍‌‍‌​​‌‍‌‌‌​‍‌​‌​​‌‍‌‌‌‍​‌‌​‌‍‍‌‌‌‍‌‍‌‌​‌‌​​‌‌‌‌‍​‍‌‍​‌‍‍‌‌​‌‍‍​‌‍‌‌‌‍‌​​‍​‍‌‌