M365.FM - Modern work, security, and productivity with Microsoft 365

For decades, enterprise software followed a predictable financial model. Organizations purchased licenses, assigned them to users, and budgeted annual IT spending with confidence. AI changes that completely. Modern AI platforms are no longer sold purely as software—they're becoming consumption-based services where autonomous agents perform work on your behalf. Every action, every reasoning cycle, every orchestration task, and every AI workflow consumes credits instead of simply using a fixed license. This episode explains why Copilot Credits fundamentally change enterprise budgeting, why governance becomes more important than licensing, and how organizations must rethink identity, permissions, auditing, FinOps, and AI compliance before autonomous agents become part of everyday business operations.

FROM SOFTWARE LICENSES TO AI ECONOMICS
Traditional enterprise software was easy to budget. Organizations counted employees, purchased licenses, and forecasted annual costs with relatively little uncertainty. AI introduces a completely different financial model. Instead of paying only for access, organizations increasingly pay for work performed. Every autonomous action performed by an AI agent consumes credits based on:
Reasoning complexity
Runtime
Context size
Tool usage
Model selection
This transforms AI from a predictable software expense into an operational resource similar to cloud compute. The presentation argues that organizations are no longer purchasing software—they're purchasing autonomous labor, and that fundamentally changes IT economics.

THE COPILOT CREDIT TRAP
The biggest misconception surrounding Copilot Credits is that they simply represent another licensing model. They don't. Credits become the currency of AI work. A lightweight task may consume relatively few credits. Complex reasoning tasks involving multiple enterprise systems, long context windows, and autonomous orchestration consume dramatically more. Costs now scale according to:
Agent behavior
Task complexity
Organizational adoption
Workflow automation
rather than simply employee count. Organizations may believe they have predictable AI costs because licensing appears fixed, while actual consumption grows continuously behind the scenes. This hidden variability creates what the presentation describes as the Copilot Credit Trap.

WHY FINANCE CAN NO LONGER PREDICT COSTS
Finance departments have traditionally planned annual software budgets using fixed subscription pricing. Consumption-based AI disrupts that model. Instead of budgeting for employees, organizations must now forecast:
Daily agent activity
Departmental usage
Business workflows
Credit consumption
Seasonal demand
Automation growth
Small changes in adoption can produce disproportionately large cost increases. The challenge isn't simply higher spending. It's the loss of financial predictability. Variable AI consumption introduces volatility that traditional IT budgeting processes were never designed to manage.

VISIBILITY IS THE FIRST GOVERNANCE PROBLEM
Many organizations cannot accurately answer basic questions such as:
Which AI agents currently exist?
Which departments deployed them?
Which systems can they access?
Which business processes do they automate?
How much do they cost?
The presentation describes this as the visibility crisis. Shadow AI deployments appear through:
Copilot Studio
Power Automate
Departmental automation
Third-party AI integrations
Custom workflows
Without a complete inventory, governance becomes impossible because organizations cannot secure, monitor, or budget for systems they don't even know exist.

PERMISSIONS BECOME MULTIPLIED
One of the most significant risks discussed throughout the session is permission amplification. AI agents inherit the permissions of the identities under which they operate. If a user can access HR records, the agent can also access them. If a user can modify SharePoint documents, schedule meetings, or send emails, so can the agent. Unlike humans, however, agents perform these actions at machine speed and enterprise scale. This dramatically amplifies existing governance weaknesses, especially in environments suffering from years of permission creep and excessive data sharing. The presentation argues that AI doesn't create governance problems—it magnifies the ones organizations already have.

AUTONOMY REQUIRES NEW GOVERNANCE
Traditional software waits for users. Autonomous agents do not. Modern AI systems:
Send emails
Update records
Schedule meetings
Trigger workflows
Coordinate with other agents
often after only an initial approval. As conditions change during execution, agents adapt automatically. This makes traditional approval processes insufficient. Organizations must introduce:
Human approval gates
Escalation rules
Spending thresholds
Risk classifications
Continuous monitoring
Governance moves from documentation into active operational control.

THE EU AI ACT CHANGES EVERYTHING
One of the central themes of the presentation is the approaching regulatory landscape. Organizations deploying AI into HR, finance, customer services, or other sensitive business functions face increasing governance obligations under the EU AI Act. High-risk AI systems require:
Risk management
Technical documentation
Human oversight
Audit trails
Incident reporting
Continuous monitoring
Compliance is no longer simply about technology. It becomes an enterprise operating capability involving legal, compliance, security, and business leadership working together.

IDENTITY IS THE FOUNDATION
The presentation argues that autonomous agents require independent identities rather than sharing user accounts. Each agent should receive:
Dedicated identity
Scoped permissions
Least-privilege access
Independent audit trail
Lifecycle management
This enables organizations to distinguish human actions from autonomous agent behavior while improving accountability and reducing operational risk. Identity becomes the foundation upon which every other governance capability depends

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

Many AI agents start out fast, responsive, and surprisingly intelligent. But after a few months of real-world use, something changes. Response times increase, costs rise, prompts become enormous, and accuracy begins to decline. Organizations often respond by upgrading to larger models, expanding prompts, or adding more orchestration—but the underlying problem remains. The issue isn't the model. It's the architecture. This episode explains why monolithic prompts create what is known as the Context Tax, how modular Skills solve the problem through progressive disclosure, and why Skills are becoming the architectural foundation of modern AI agents across Microsoft Copilot Studio, GitHub Copilot, Claude Code, and the broader enterprise AI ecosystem.

THE CONTEXT TAX
Every enterprise AI project eventually faces the same challenge. At first, an agent contains a relatively small system prompt describing its role, tone, business rules, and guardrails. As the organization grows, more instructions are added:
Policies
Compliance rules
Business procedures
Examples
Edge cases
Department-specific workflows
Eventually the prompt becomes thousands of tokens long. Every user request forces the model to process every instruction—even when ninety-five percent of them are completely irrelevant. This hidden processing overhead is called the Context Tax. Rather than making agents smarter, larger prompts increase latency, raise inference costs, introduce reasoning noise, and gradually reduce answer quality. The presentation argues that the real problem isn't insufficient AI capability—it is forcing the model to continuously reason over information it doesn't actually need.

WHY AGENTS DEGRADE OVER TIME
Agent degradation is remarkably predictable. Organizations usually begin with one comprehensive instruction document that contains everything the AI should know. Initially this works well. Then new departments request additional functionality. Policies evolve. Compliance requirements expand. New workflows are added. Instead of restructuring the architecture, teams simply keep extending the same prompt. The result is context saturation. The model spends increasing amounts of effort searching through irrelevant guidance before finding the instructions that actually matter. This produces several side effects:
Higher token consumption
Slower responses
Increased hallucinations
More inconsistent reasoning
Higher operational costs
The AI hasn't become less intelligent. Its reasoning path has simply become overwhelmed by unnecessary context.

ALWAYS-ON GUIDANCE VS SITUATIONAL EXPERTISE
One of the most important architectural distinctions introduced in this session is separating always-on guidance from situational expertise. Always-on guidance includes information that applies to every conversation:
Agent identity
Tone of voice
Universal compliance rules
Security requirements
Core behavioral instructions
Situational expertise is different. It only matters when specific scenarios occur. Examples include:
Vendor onboarding
Leave eligibility
Tax regulations
Refund workflows
Regional compliance
Incident response procedures
Traditional agents mix both categories into one enormous prompt. Modern agent architectures separate them. Only universal guidance remains permanently loaded. Everything else becomes modular Skills that activate only when required.

WHAT IS A SKILL?
A Skill is much more than a prompt. It is a reusable package containing:
Structured instructions
Metadata
Trigger descriptions
Optional scripts
Reference documents
Templates
Supporting assets
The core of every Skill is the SKILL.md file. This file defines:
Name
Description
Purpose
Trigger conditions
Workflow
Procedural guidance
The orchestrator doesn't initially load the entire Skill. Instead, it evaluates only the metadata. When the user's request matches the Skill description, the complete instructions are loaded into context. This dramatically reduces unnecessary reasoning while keeping specialist knowledge available exactly when needed.

THE REASONING BOUNDARY
The presentation introduces another important architectural concept: Skills define reasoning boundaries. Rather than forcing an AI model to treat every instruction as universally relevant, Skills establish clear expertise domains. A leave management Skill applies only to leave requests. A procurement Skill activates only during purchasing workflows. A compliance Skill loads only when compliance questions arise. Each Skill becomes an isolated reasoning domain. Instead of thinking about every possible business process simultaneously, the model focuses exclusively on the knowledge required for the current task. This improves both precision and consistency. 

PROGRESSIVE DISCLOSURE
One of the core design principles behind Skills is Progressive Disclosure. Instead of loading every instruction at startup, agents maintain only a lightweight catalog containing Skill names and descriptions. When a matching scenario appears:
The orchestrator identifies the relevant Skill.
The Skill loads into context.
The task executes.
The Skill unloads after completion.
Everything else remains outside the context window. This significantly reduces:
Token usage
Latency
Compute requirements
Infrastructure costs
The architecture keeps the default state intentionally lean.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

For years, Microsoft's recommended architecture for connecting AI assistants like Claude Desktop to Dataverse relied on a local STDIO proxy. It was simple, easy to install, and perfectly suited for individual developers experimenting with AI-powered workflows. But enterprise AI has evolved. Organizations are no longer connecting a single assistant to a single application. They're connecting hundreds—or even thousands—of AI agents across multiple clients, platforms, and business systems. That architectural shift changes everything. This episode explains why the traditional proxy model has reached its limits, why Streamable HTTP fundamentally changes enterprise AI integration, and how Dataverse is evolving from the database behind Power Apps into the governed data backbone for the entire Agent Fabric.

WHY THE STDIO PROXY WAS CREATED
The original STDIO proxy solved a very specific problem. Early MCP clients like Claude Desktop needed a simple way to communicate with cloud services while running locally on a developer's machine. Instead of exposing an internet-facing endpoint, developers launched a local process that translated communication between the AI client and Dataverse. The advantages were obvious:
Simple installation
No HTTP server required
No certificates
Minimal infrastructure
Isolated execution per user
For individual developers, this architecture worked remarkably well. Every proxy was independent, failures affected only one user, and deployment required little more than installing a small application. The problem wasn't that the proxy stopped working. The problem was that enterprise AI completely outgrew the assumptions behind it.

THE PROXY SCALING PROBLEM
The proxy architecture assumes one developer. Modern enterprises operate very differently. Instead of one Claude Desktop instance, organizations now deploy:
Claude Desktop
Claude Code
GitHub Copilot
Copilot CLI
Custom orchestration services
Internal AI assistants
Each proxy creates:
Independent authentication
Separate connection pools
Individual infrastructure
Separate monitoring
Isolated failure domains
As organizations scale from ten developers to hundreds or thousands, operational complexity increases exponentially. Instead of managing one governed service, administrators find themselves maintaining hundreds of disconnected proxy processes with little centralized visibility or control. What began as a convenience gradually becomes operational debt.

THE LATENCY MYTH
One of the strongest arguments for STDIO has always been performance. Microbenchmarks show local inter-process communication taking only a few milliseconds, while HTTP introduces network latency and TLS negotiation. On paper, STDIO appears dramatically faster. However, those benchmarks ignore the actual workload. Most Dataverse operations spend hundreds of milliseconds—or even more than a second—executing business logic, security checks, and database queries. When those execution times are included, HTTP overhead becomes relatively insignificant. Even more importantly, enterprise HTTP deployments benefit from:
Connection pooling
Persistent sessions
Horizontal scaling
Long-lived services
Shared infrastructure
Meanwhile, every new proxy instance pays startup costs, authentication overhead, and process initialization repeatedly. The presentation argues that organizations measuring end-to-end performance often find properly optimized HTTP deployments outperform local proxy architectures despite their higher transport latency.

STREAMABLE HTTP CHANGES EVERYTHING
Instead of every AI client running its own proxy, Dataverse now exposes a single Streamable HTTP endpoint. Every supported AI client connects to exactly the same service. Examples include:
Claude Desktop
Claude Code
GitHub Copilot
VS Code
Custom AI orchestrators
Rather than multiplying infrastructure for every new user, organizations scale a single enterprise service. Additional capacity simply means adding more server instances behind a load balancer. Clients continue connecting to the same endpoint while the platform handles scaling transparently. The architecture shifts from isolated desktop utilities to enterprise-grade shared infrastructure.

PKCE ENABLES SECURE PUBLIC CLIENTS
Moving to HTTP introduces a new challenge: How do desktop applications authenticate without storing client secrets? The answer is PKCE (Proof Key for Code Exchange). Instead of embedding long-lived secrets inside client applications, PKCE generates temporary cryptographic values during authentication. This approach allows applications like:
Claude Desktop
Claude Code
GitHub Copilot
to authenticate securely using Microsoft Entra ID without exposing credentials. Authentication becomes:
Secret-free
User-based
Standards compliant
Automatically renewable
This security model enables enterprises to deploy multiple AI clients without distributing confidential application secrets to every workstation.

DATAVERSE BECOMES THE AGENT FABRIC
Perhaps the most important architectural shift is how Dataverse itself is positioned. Historically many organizations viewed Dataverse simply as the database behind Power Apps. The presentation argues that this perspective is obsolete. Dataverse now becomes the central business data platform for AI agents. Every supported AI client communicates through the same endpoint. Every request uses:
Shared governance
Shared authentication
Shared business logic
Shared security
Shared audit trails
Instead of building separate integrations for every large language model, organizations expose one governed platform that every compliant client can consume. This transforms Dataverse from an application database into enterprise AI infrastructure.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

For more than two decades, CI/CD pipelines have been the backbone of modern software delivery. Developers commit code, automated builds run, tests execute, security scans complete, someone approves the deployment, and production is updated. This model transformed software engineering and enabled DevOps to become the industry standard. But the world has changed. Cloud-native applications, Kubernetes, AI, multi-cloud architectures, and thousands of daily deployments have pushed traditional pipelines beyond what they were designed to handle. The real bottleneck is no longer automation—it's the fact that automation still revolves around human decision-making and linear workflows. This episode explores a radical shift: replacing sequential CI/CD pipelines with intelligent, autonomous AI agents that reason, collaborate, and adapt in real time. We'll examine why traditional pipelines are reaching their limits, how agentic systems fundamentally change software delivery, and why governance—not autonomy—is becoming the defining architectural challenge of the next generation of DevOps.

WHY THE TRADITIONAL PIPELINE IS BREAKING
Traditional CI/CD pipelines were designed around a simple assumption: Humans make the important decisions. A developer commits code. The pipeline builds. Tests execute. Security scans run. Then someone reviews. Someone approves. Someone decides whether deployment should continue. Every approval introduces waiting. Every handoff introduces latency. Every manual decision becomes another bottleneck. This worked perfectly when organizations deployed once every few weeks. Today's cloud-native organizations deploy hundreds or even thousands of times every day. At that scale, human approval is no longer primarily a safety mechanism. It becomes the slowest component in the entire delivery system. The pipeline itself isn't broken. Its underlying operating model is.

AUTOMATION ISN'T THE SAME AS INTELLIGENCE
Many organizations tried solving pipeline bottlenecks through automation. They built scripts. They created runbooks. They automated approvals. Initially this improved delivery speed. Eventually another problem appeared. Scripts only work inside predefined conditions. Whenever infrastructure changes, scripts begin failing. New Kubernetes versions... Changed APIs... Different deployment strategies... Updated security requirements... Every infrastructure evolution requires maintaining automation itself. Traditional automation has no understanding of context. It executes procedures. It doesn't reason. Organizations eventually spend enormous effort maintaining automation instead of benefiting from it. The presentation argues that static automation reaches a ceiling because modern infrastructure changes faster than rule-based systems can keep up.

AI AGENTS CHANGE THE MODEL
An AI agent is fundamentally different from a script. Scripts execute instructions. Agents reason. Instead of simply matching predefined rules, an agent continuously:
Observes system state
Understands context
Evaluates possible actions
Chooses the safest strategy
Learns from previous outcomes
Imagine a degraded service. A script simply restarts it. An AI agent first investigates. Is this really a service failure? Is memory leaking? Is traffic unusually high? Would a canary rollout be safer than a restart? Could restarting actually make the situation worse? Rather than following procedures, AI agents operate using policies and objectives. That distinction fundamentally changes software delivery because the system adapts instead of merely executing instructions.

FROM PIPELINES TO AGENT FABRICS
Perhaps the biggest concept introduced in this session is that the future isn't a faster pipeline—it isn't a pipeline at all. Traditional delivery is sequential. Commit. Build. Test. Deploy. Each stage waits for the previous one. Agentic systems replace this with an AI fabric. Multiple specialized agents operate simultaneously. One analyzes security. Another writes tests. Another validates performance. Another evaluates deployment strategy. Instead of waiting for sequential stages, agents continuously exchange information while reasoning together. Researchers increasingly describe this model as Continuous Agentic Continuous Deployment (CA/CD) where reasoning replaces stage gates. The result isn't simply faster deployment. It's an entirely different operating model built around collaboration rather than sequence.

THE SUPERVISOR-WORKER ARCHITECTURE
Production AI systems don't consist of one giant intelligent agent. Instead, they increasingly adopt the Supervisor-Worker architecture. A supervisor agent owns the business objective. Specialized worker agents focus on individual domains:
Security
Testing
Performance
Deployment
Compliance
Workers analyze their specific area. The supervisor coordinates the work, combines expert recommendations, and makes the final decision. This architecture provides several advantages:
Clear accountability
Easier auditing
Better scalability
Independent specialization
Easier maintenance
Rather than creating one enormous AI system responsible for everything, organizations compose smaller expert agents that collaborate through orchestration. Companies adopting this architecture are reporting significantly faster delivery cycles while maintaining stronger governance.

AUTONOMY ISN'T THE GOAL
One of the most important lessons throughout the presentation is that full autonomy is neither realistic nor desirable. Current AI agents still require frequent human correction. Rather than viewing this as failure, organizations should treat it as a natural safety mechanism. The goal becomes appropriate autonomy. Low-risk activities may execute completely automatically. Medium-risk actions require human confirmation. High-risk production deployments remain supervised. Authority expands gradually based on measured performance. Autonomy is earned—not assumed. Successful organizations build tiered governance where AI gains additional responsibility only after consistently demonstrating reliable decision quality.

GOVERNANCE BECOMES ARCHITECTURE
Traditional governance relied on documents and policies. Agentic systems require something much stronger. Governance becomes architecture. Instead of saying: "Agents should only deploy approved services." Organizations technically prevent any other deployment from happening. Every agent receives:
Cryptographic identity
Scoped permissions
Short-lived credentials
Policy validation
Continuous authorization
Complete audit logging
Every action is validated immediately before execution. Agents don't merely promise to follow policy. The architecture prevents them from violating it. This represents one of the largest architectural shifts introduced by autonomous software delivery-

MULTI-AGENT COMMITTEES
Some decisions are too complex for a single agent. The presentation introduces another emerging architectural pattern: The Multi-Agent Committee. Rather than relying on one AI model, multiple specialist agents independently evaluate the same decision. For example:
Security Agent
Performance Agent
Code Review Agent
Compliance Agent
Each produces an independent recommendation. The supervisor synthesizes their conclusions before approving deployment. This dramatically improves decision quality because multiple expert perspectives identify different classes of problems. When disagreement occurs, the system naturally escalates to a human instead of forcing artificial certainty. Collective reasoning becomes safer than relying on any individual model.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

At first glance, the numbers look incredible. Deployment frequency is increasing, pull requests are being merged faster than ever, AI is generating more code, and engineering teams appear dramatically more productive. Executive dashboards are filled with green indicators suggesting software delivery has entered a new golden age. But beneath those impressive metrics lies a very different reality. AI has accelerated code generation, but it hasn't eliminated engineering work. Instead, it has shifted the bottlenecks from writing code to reviewing, validating, governing, and understanding it. Organizations are producing significantly more code while simultaneously experiencing more incidents, higher cognitive load, greater technical debt, and increased developer burnout.

THE PRODUCTIVITY ILLUSION
The central message of this session is simple: More code does not automatically mean more productivity. AI has dramatically increased engineering output, but many organizations are confusing output with value. According to the presentation:
AI now generates a significant portion of production code.
Pull request throughput has nearly doubled.
Developers save substantial time on repetitive coding tasks.
Yet production incidents, code churn, review times, and cognitive load have all increased.
Rather than removing engineering constraints, AI has simply moved them further downstream into review, testing, operations, and governance. The dashboard still reports success—but the engineering system itself is becoming increasingly fragile.

WHY TRADITIONAL KPIs ARE FAILING
Many engineering organizations still rely heavily on classic DevOps metrics such as:
Deployment Frequency
Lead Time
Change Failure Rate
Mean Time To Recovery (MTTR)
These metrics were designed for a world where humans wrote nearly all production code. AI fundamentally changes that assumption. Today's bottleneck is no longer writing software. It is understanding software. Deployment frequency may increase while review queues explode. Lead time may decrease while technical debt grows. Change failure rates may appear acceptable while code requires constant rewrites. The presentation argues that traditional engineering dashboards measure activity, not system health.

WHEN MORE CODE CREATES MORE PROBLEMS
One of the strongest themes throughout the presentation is the unintended consequence of AI-generated software. Developers can now create thousands of lines of code within minutes. Human reviewers, however, still need to verify every important architectural, security, and business decision. As pull requests become larger and more complex:
Review times increase dramatically.
Senior engineers become bottlenecks.
Production incidents rise.
Technical debt accumulates faster.
More code requires future maintenance.
Instead of removing engineering work, AI shifts effort toward verification and understanding. The engineering organization appears faster while becoming increasingly overloaded.

THE COGNITIVE LOAD CRISIS
Perhaps the most important concept discussed is cognitive load. AI reduces the effort required to write code. It dramatically increases the effort required to understand that code. Developers now spend increasing amounts of time:
Reviewing AI-generated implementations.
Understanding unfamiliar logic.
Switching between contexts.
Verifying correctness.
Explaining code the AI never documented.
The presentation distinguishes between productive engineering effort and unnecessary mental overhead. Instead of solving business problems, engineers increasingly spend their cognitive capacity validating machine-generated output. The result is lower developer satisfaction despite higher apparent productivity.

THE TOXIC KPI TRAP
Organizations naturally optimize whatever they measure. The problem arises when the metrics themselves no longer represent organizational health. Examples include:
Maximizing AI-generated code percentage.
Increasing deployment frequency.
Optimizing story points.
Reducing review duration.
Maximizing pull requests per developer.
Each metric improves individually. Meanwhile:
Rework increases.
Stability declines.
Technical debt grows.
Review quality drops.
Engineers burn out.
The presentation argues that these KPIs encourage organizations to optimize motion instead of meaningful outcomes. Good numbers do not necessarily represent healthy engineering systems.

FROM ACTIVITY TO FLOW
A major recommendation is replacing activity-based thinking with flow-based measurement. Instead of asking: "How much did we ship?" Organizations should ask: "How efficiently does work move through the system?" Important flow metrics include:
Flow efficiency
Queue age
Review cycle time
Work in Progress (WIP)
Bottleneck identification
Rework rate
These metrics reveal where work actually becomes blocked rather than simply counting completed deployments. The presentation argues that AI has shifted engineering constraints from development toward review and verification, making flow measurement far more valuable than raw throughput metrics.

DORA 5 AND REWORK RATE
One of the most practical recommendations is expanding traditional DORA metrics with a fifth dimension: Rework Rate. Rather than simply measuring deployment speed, organizations should track how much recently written code must be rewritten shortly afterward. High rework indicates:
Weak verification
Poor code durability
Fragile architectures
Inadequate reviews
Incorrect AI usage
Rework becomes a much stronger indicator of long-term engineering quality than deployment frequency alone. The presentation positions this as one of the most valuable indicators for AI-assisted software development.

BURNOUT IS A SYSTEM METRIC
Another major insight is that burnout should be viewed as an engineering metric—not merely an HR concern. The presentation connects rising cognitive load with:
Developer dissatisfaction
Increased context switching
Longer review cycles
Night and weekend work
Higher attrition
Lower software quality
When developers spend most of their day reviewing AI-generated code rather than solving meaningful business problems, engineering quality gradually declines. Organizations that ignore these signals risk losing their most experienced engineers while dashboards continue reporting "improved productivity."

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.