At Microsoft Digital, the company’s IT organization, we’re using a set of employee councils and connected capability groups to guide and accelerate how we deploy and adopt AI across our enterprise. Our goal is to focus our energy on the AI-enabled scenarios that matter most, reducing duplication, strengthening accountability, and making sure our investments create measurable value.

“Our AI decisions and direction must be grounded in business strategy. AI councils provide guidance and enablement for our organization, ensuring that our investments in AI generate tangible benefits to our business. It’s not just developing technology and then looking for a problem to solve with it—we start with the opportunity.”

Don Campbell, principal group technical program manager, Microsoft Digital

That focus matters, because AI success doesn’t come from usage alone. It comes from connecting strategy, enablement, data readiness, responsible AI, continuous improvement, change management, and measurement into one driving force.

That’s how we’re moving from experimentation to repeatable outcomes and from AI enthusiasm to AI accountability.

“Our AI decisions and direction must be grounded in business strategy,” says Don Campbell, principal group technical program manager in Microsoft Digital. “AI councils provide guidance and enablement for our organization, ensuring our investments in AI generate tangible benefits to our business. It’s not just developing technology and then looking for a problem to solve with it—we start with the opportunity.”

Our council-based approach is helping us accelerate our Frontier Firm transformation. The councils work together to set direction for AI adoption at Microsoft Digital, ensuring that our business needs drive solution development that can keep up with the pace of AI change. This work includes building visibility into all our AI solutions, including agents and Model Context Protocol (MCP) servers, while establishing governance and proven practices; developing training and learning pathways; and connecting teams together that are working on similar solutions across the enterprise.

We’re excited for a future where our employees use intelligent agents and human judgment together to work smarter, move faster, and unlock new value for Microsoft and our customers.

Why we use councils to guide internal AI efforts

Effective AI needs both enterprise guidance and business-owned direction. That’s why we’re using councils and connected capability groups as the operating model for our AI deployment.

Each group has a distinct role, and none of them work alone. Together, they help us connect the strategy for AI to the work currently happening across Microsoft Digital.

• Our strategy council sets priorities by aligning AI work to business goals, identifying top scenarios, prioritizing investments, and keeping KPIs and value in focus.
• Our enablement council uses our AI Center of Excellence to turn strategy into action through technical guidance, proven practices, ideation, learning, knowledge sharing, culture, and governance.
• Our data council strengthens the AI foundation via data strategy, governance, access, quality, literacy, and prioritization.
• Our process council drives continuous improvement through operational excellence, problem solving, prioritization, value realization, coaching, and learning.
• Our compliance council applies Responsible AI principles to ensure compliance, inclusiveness, fairness, transparency, and reliability.
• Measurement ties it all together by tracking both business outcomes and engineering artifacts, ensuring we can clearly demonstrate real-time value realization.  

These councils help us see across the business landscape through the lens of AI. They enable us to reduce duplication, scale what works, and make better decisions about where AI can create value. That allows our teams to keep moving fast without letting activity get ahead of accountability.

Aligning AI strategy to business value

Our strategy council helps us decide which AI-enabled scenarios deserve the most attention, which investments align to our business priorities, and how we’ll know whether the work is creating value. It gives leaders a practical way to look across the portfolio and keep our AI work tied to the outcomes we’re accountable for.

“Business strategy defines the what and the why. AI defines the how, enabling execution of the strategy and delivering real value. We should use AI to advance our business strategy, not the other way around.”

Qingsu Wu, principal group product manager, Microsoft Digital

This is important, because broad experimentation is useful early on in your AI journey. It helps teams learn and build momentum. But experimentation has to mature into focus. Without that shift, organizations can end up with too many different agents, agent skills, MCP servers, and other artifacts, without a clear view of what’s actually impacting the business.

We’re using the strategy council to keep that from happening.

“Business strategy needs to lead the AI strategy,” says Qingsu Wu, a principal group product manager in Microsoft Digital and an influential member of the strategy council. “Business strategy defines the what and the why. AI defines the how, enabling execution of the strategy and delivering real value. We need to use AI to advance our business strategy, not the other way around.”

That principle shapes how we work. We use the strategy council to identify our top AI-enabled scenarios, clarify the value we expect to create with each one, and connect that work to a monthly operating rhythm. Product owners still manage delivery and the council keeps the portfolio focused, visible, and aligned.

Tuning strategy into repeatable execution

Our AI Center of Excellence (CoE) is at the heart of our approach to enablement. It helps us translate enterprise AI priorities into practical guidance and execution support for teams building AI-enabled solutions.

“We can see patterns that a single team can’t. We’re translating AI CoE strategy and enterprise priorities into clear execution plans that work in each organization’s context. That allows us to align priorities and make sure our biggest bets are actually landing.”

Ria Khetan, senior program manager, Microsoft Digital

The AI CoE extends the reach of the strategy council. It gives teams what they need to build, govern, reuse, and scale what matters, while the strategy council assists us in deciding where to focus.

That connective role is central to the broader council model. The strategy council identifies the top AI-enabled scenarios. The AI Center of Excellence connects strategy to execution across the organization, operating as a cross-functional coordination layer that sets direction and creates shared accountability.

“We can see patterns that a single team can’t,” says Ria Khetan, a senior program manager in Microsoft Digital, who is a member of the council. “We’re translating AI CoE strategy and enterprise priorities into clear execution plans that work in each organization’s context. That allows us to align priorities and make sure our biggest bets are actually landing.”

The COE helps teams move those scenarios forward with answers to important questions:

• What initiatives are in flight?
• What initiatives bring the most return on investment?
• Where is there potential duplication?
• Where do we need clearer guidance?
• Where do we need stronger governance?

It also helps reduce fragmentation. When teams build in isolation, they can solve the same problem in different ways. They can choose different patterns, interpret standards differently, or create solutions that don’t scale beyond a single context. Enablement gives us a shared way to look across that activity and ask better questions.

“We use the CoE to bring consistency to how AI work gets done,” Campbell says. “It gives us a way to step back and ask whether we’re solving the right problems and whether we’re set up to scale.”

“High-quality, well-governed data is essential to accelerate AI implementation and adoption, and to ultimately unlock its full value. Data quality, accessibility, and governance are imperatives for AI systems to be reliable, scalable, and business-critical. Recognizing this principle is propelling our data strategy.”

Miguel Uribe, principal PM manager, Microsoft Digital

Building AI on trusted data

Our AI scale depends on trusted and reliable data. That makes our data council central to our council-based approach. This council makes sure our teams work with data that’s governed, discoverable, accessible, and ready for AI.

“High-quality, well-governed data is essential to accelerate AI implementation and adoption, and to ultimately unlock its full value,” says Miguel Uribe, a principal PM manager in Microsoft Digital and member of the data council. “Data quality, accessibility, and governance are imperatives for AI systems to be reliable, scalable, and business-critical. Recognizing this principle is propelling our data strategy.”

We’re applying a data mesh mindset to balance domain ownership with enterprise consistency. Teams stay close to the data that they know best. Shared standards for governance, quality, metadata, and compliance provide a framework to make that data useful across Microsoft Digital.

Microsoft Fabric and Microsoft Purview are key to that approach. Microsoft Fabric unifies our siloed data in a shared data mesh. Microsoft Purview enables governance and best practices to ensure that we manage our data responsibly through discovery, classification, protection, and monitoring.

Our goal is AI-ready data that’s available, complete, accurate, and high quality. Our data council also works with the AI Center of Excellence to strengthen data and AI fluency through learning pathways, operational practices, and community programs.

“Our capacity to drive process improvements has been crucial to our AI transformation as a company. We’ve adopted a ‘CI before AI’ approach to ensure that we don’t end up automating inefficient processes.”

David Laves, director of business programs, Microsoft Digital

Improving the process before applying AI

AI works best when it’s applied to the right problem. That’s why continuous improvement is part of our council-based approach. Before teams automate a workflow or build an agent, we want them to understand the process, identify waste, and decide where AI can create measurable value.

“Our capacity to drive process improvements has been crucial to our AI transformation as a company,” says David Laves, director of business programs in Microsoft Digital and a member of the Continuous Improvement Center of Excellence. “We’ve adopted a ‘CI before AI’ approach to ensure that we don’t end up automating inefficient processes.”

Continuous improvement helps teams make sure the underlying work is worth scaling. That’s when a continuous improvement approach can help. It encourages practices like Gemba walks, Kaizen events, bowler cards, and monthly business reviews that allow our teams to understand where work gets stuck and where AI can help.

Continuous improvement keeps the council model grounded in real work. We’re applying it where the process is understood, the value is clear, and the outcome can be measured.

Scaling AI responsibly

Our compliance council encourages the application of Responsible AI, so our teams can move faster with confidence. As our AI work scales across Microsoft Digital, responsible AI has to connect directly to the same council ecosystem that guides strategy, enablement, data, process, and measurement. That connection helps teams understand what they’re accountable for before they build too far, too fast.

Our responsible AI work focuses on compliance, inclusiveness, fairness, transparency, reliability, privacy, security, and accountability. It’s grounded in the Microsoft Responsible AI Standard and supported by responsible AI champions who help teams apply those expectations in real development workflows.

This approach gives teams structure. It allows them to assess impact, identify risks, document decisions, and bring in the right reviewers. It also creates consistency, as more AI agents and solutions move from experimentation into enterprise use.

The goal is to enable AI project teams to move in the right direction with the right safeguards. Responsible AI gives the strategy council, the AI Center of Excellence, the data council, and product teams a shared standard for trust—to turn ambition into accountable execution. It also makes sure the AI systems we scale are worthy of the trust that employees, customers, and the company place in them.

Measuring our AI outcomes

Our councils choose the right AI work, support teams as they build, strengthen the data foundation, apply responsible AI, and improve processes before we scale. But we still need to answer the most important question: What changed because of the AI investment?

That’s why we have built a common value measurement framework across Microsoft Digital. Our teams use the framework to define expected value before they build. With it, they can establish a baseline, track results, and review what they learn with the right business and AI owners.

We organize AI value across six areas: Revenue impact, productivity and efficiency, security and risk management, employee and customer experience, quality improvement, and cost savings. Not every initiative needs to deliver value in every category. The point is to create a shared language that leaders and teams can use to compare investments, make tradeoffs, and understand progress.

Measurement also pushes us past simple savings claims.

If AI saves time, reduces cost, improves quality, or increases coverage, we want to know what happens next. Did teams reinvest that capacity? Did service improve? Did risk go down? Did quality increase?

AI accountability depends on that full loop. We define value, measure results, review progress, and adjust. Then we use what we learn to guide the next round of decisions.

Operating as one connected AI system

Our AI councils make a difference because each group has a different focus.

“What got us here won’t get us to where we need to go next. We started with broad experimentation—getting teams excited and building—but now we’re evolving as an organization to think about scale, alignment to business goals, and making sure our investments are driving the right outcomes.”

Myron Wan, principal group product manager, Microsoft Digital

Strategy assists us in choosing the right priorities. Enablement helps our teams to build with shared patterns. Data readiness gives AI systems a trusted foundation. Responsible AI allows us to move faster with confidence. Continuous improvement makes sure we’re improving the work before we automate it. Measurement tells us whether the investment changed anything meaningful.

Together, this system means we can operate AI as a business-driven enablement system.

“What got us here won’t get us to where we need to go next,” says Myron Wan, a principal group product manager in Microsoft Digital. “We started with broad experimentation—getting teams excited and building—but now we’re evolving as an organization to think about scale, alignment to business goals, and making sure our investments are driving the right outcomes.”

There’s more work ahead. We need to keep scaling enablement, improving data readiness, increasing high-value use cases, showcasing measurable impact, and tightening alignment across teams.

We also need to keep asking the hard questions: Where should we invest? Where are we reducing risk? Are we reinvesting the value that AI creates?

Our council-based model allows us to answer those questions with discipline. It helps us connect AI ambition to business outcomes and move from experimentation to repeatable enterprise value. And it provides a practical model that other IT organizations can adapt as they guide their own AI deployment.

The post Guiding our AI deployment with a set of employee councils appeared first on Inside Track Blog.

That’s why, as part of our broader approach to AI at Microsoft, we—Microsoft Digital, the company’s IT organization—are building a framework to measure the impact of the AI investments we’re making on behalf of the company.

“If we want to measure the business impact of AI, the conversation quickly moves toward identifying the agents or AI efforts that are driving the most value and satisfying business outcomes. We know that those conversations can be complex, so we use a value measurement framework to capture and assess the signals we have available.”

Don Campbell, principal group technical program manager, Microsoft Digital

Our framework is helping us move from AI enthusiasm to AI accountability. It creates a common way for us to talk about value across our different initiatives, teams, and business processes. It also helps us ask a harder, more specific question every time we assess the impact of AI at Microsoft Digital: If AI saves time, reduces costs, improves quality, or lowers risk, what changes are we making to take advantage of that?

We don’t have the full answer yet—we’re still improving the way we measure. Some of our signals are instrumented, some rely on strong hypotheses, and some need better telemetry. But we’re not waiting for perfect results to start learning.

“If we want to measure the business impact of AI, the conversation quickly moves toward identifying the agents or AI efforts that are driving the most value and satisfying business outcomes,” says Don Campbell, a principal group technical program manager in Microsoft Digital. “We know that those conversations can be complex, so we use a value measurement framework to capture and assess the signals we have available.”

Building a framework for AI business value

AI value doesn’t show up the same way everywhere. One investment we make might help employees complete a task faster, while another might improve quality, reduce risk, increase coverage, or lower operational costs. Some of that value can be measured directly, while in other cases it starts as a hypothesis that needs to be tested. That range is why we needed a common framework instead of a single metric.

Our value measurement framework helps our Microsoft Digital teams answer three basic questions before and after they build:

• What kind of value do we expect this AI investment to create?
• How will we measure that value?
• What will we do with what we learn?

We organize the answers to those questions around six value areas:

Revenue impact: How an AI investment contributes to our business growth, sales activity, customer targeting, or deal velocity.

Productivity and efficiency: How AI helps our people complete tasks faster, increase throughput, optimize processes, or automate work.

Security and risk management: How AI helps us identify, prevent, or manage security vulnerabilities, risk exposure, or Responsible AI compliance.

Employee and customer experience: How AI improves satisfaction, engagement, or the quality of a product or service experience.

Quality improvement: How AI improves deliverables, accuracy, confidence in outputs, or process quality.

Cost savings: How AI reduces our operational cost, improves our resource allocation, or helps us avoid future cost.

Our framework doesn’t require every AI investment that we make to create value in all six areas. In fact, that rarely occurs. A support automation scenario might focus primarily on productivity, employee experience, and cost avoidance. A security scenario might involve risk reduction, vulnerability coverage, or the ability to address more issues than a team could handle manually. A process quality scenario might relate to measures that are specific to a particular workflow and be harder to roll up into a single number.

“Measurement sources vary based upon the type of AI initiative. The six value areas give us a framework for measurement, but we need to observe and collect information where measurement starts to become practical. Teams need to understand the processes affected, including how long work takes, how many resources are involved, and what the workflow looks like before and after AI.”

David Laves, director business programs, Microsoft Digital

The framework creates consistency in how we talk about value, while giving teams room to measure what actually matters for their scenario. Some measures roll up easily, including cost savings, time savings, and certain risk measures. Others are more specific to the process being improved. Those measures still matter because they help business owners understand whether AI is changing the work in a meaningful way.

“Measurement sources vary based upon the type of AI initiative,” says David Laves, a director of business programs in Microsoft Digital. “The six value areas give us a framework for measurement, but we need observe and collect information where measurement starts to become practical. Teams need to understand the processes affected, including how long work takes, how many resources are involved, and what the workflow looks like before and after AI.”

Our framework also helps us make better investment decisions. Before we commit to an AI scenario, we can map the opportunity to the value areas that matter most, estimate the value we think it can create, and decide what needs to be measured. After implementation, we can compare results against the baseline, review the data with the right business and AI owners, and adjust the work based on what we’re seeing.

That last step is critical. Our framework creates a way for us to create an operating rhythm around AI value. It helps us take a promising scenario and prove its worth (or lack thereof) by establishing expected value, evaluating what is being measured, and deciding what to change because of the results.

It’s a continual evolution of business value measurement that prioritizes progress over perfection, and it’s helping ensure that our AI approach stays grounded in the outcomes that are most meaningful to our business.

Turning measurement into an operating rhythm

A framework only matters if teams use it to make decisions. For us, that means moving measurement out of one-off reporting and into a regular management cadence. We track our highest-business-value AI initiatives by priority and business function, then review the KPIs that show whether those investments are creating the value expected.

Some KPIs roll up cleanly. Our cost savings, time savings, and certain risk measures can be summarized across initiatives and discussed at a leadership level. Other KPIs stay closer to the individual scenario because they’re tied to a specific workflow, process, or business outcome. We need both. Our rollup metrics help our leaders see broad progress, while the scenario-level metrics help our teams understand what’s changing inside their work.

“We actually create monthly targets and end-of-year targets for every top AI-enabled initiative,” Campbell says. “Then we basically reiterate every single month with our leadership team to look at the value we’re driving and have conversations about it.”

That monthly rhythm helps us proactively manage AI value. If a measure is trending positively, we look at what’s working and where else the pattern might apply. If a measure is off track, teams can dig into the supporting data, review the assumptions, and decide whether they need to adjust the solution, the measurement, or the operating process around it.

This process supercharges prioritization. Our team here in Microsoft Digital has a large set of AI opportunities, and not every idea can move at the same pace. By mapping initiatives to value areas, estimating expected impact, and tracking results over time, we can have a more grounded conversation about where to invest, where to scale, and where to keep learning.

That discipline becomes more important as AI moves deeper into business processes. We don’t want teams to measure only adoption or usage if the real goal is a better business outcome. Usage matters, but it doesn’t tell the whole story. A tool can be used often and still fail to improve the process it was meant to change.

Applying the framework: Global Support

Consider the following example of applying the framework from our Global Support team. This team is currently examining how AI can help automate specific pieces of the ticket management process.

“In Global Support, the processes that often matter most from a value perspective are the ones with high repetition. If a process runs thousands of times a month and can operate autonomously, without human input, that’s where AI can deliver meaningful, measurable impact.”

David Finney, principal program manager, Microsoft Digital

As part of this effort, we examined a support process that depended on manual follow-up. In this process, after a Global Support team member marks an issue as resolved, the team waits for the user to confirm that the ticket can be closed. If the user doesn’t respond, the agent must follow up once a day for up to three days. After the third attempt, the agent simply closes the ticket.

This user flow gave us a practical way to test the value framework. It has repetition, because it runs often; it has autonomy potential, because the steps are deterministic and rule-driven; and it has a clear time-savings opportunity, because a human agent spends time checking the ticket, writing the follow-up, and sending the message. It also has a measurable implementation effort, because the data exists in the ticket process but the solution still needs to integrate with ServiceNow.

“In Global Support, the processes that often matter most from a value perspective are the ones with high repetition,” says David Finney, a principal program manager in Microsoft Digital. “If a process runs thousands of times a month and can operate autonomously, without human input, that’s where AI can deliver meaningful, measurable impact.”

Finney estimated that about 5,000 tickets a month execute this process. Because each ticket can require up to three follow-ups, that can create up to 15,000 manual email follow-ups a month. At about three minutes per follow-up, that’s roughly 750 hours of productivity spent on one small piece of the process each month.

The framework helps us look at that work through both value and effort. On the value side, we can evaluate repetition, autonomy potential, and time savings. On the effort side, we can assess whether the data exists, how complex the solution is, whether engineering work or system integration is required, and how long implementation may take.

“We started to evolve our conversation to, ‘So what?’” Campbell says. “You saved money, you saved hours. What did you do with it? Where did the actual business outcome sit?”

Don Campbell, principal group technical program manager, Microsoft Digital

That structure matters because a high-value opportunity still needs the right implementation path. In this case, the process is part of the ticket workflow, so the needed data exists. The complexity comes from integrating the automated agent with ServiceNow so it can interact with the ticket, check whether the user responded, send follow-ups, and resolve the ticket according to the defined process.

Instead of trying to automate all of support at once, the team identifies specific subprocesses where AI has a clear role and the value can be measured. “It’s taking a sort of bite-sized approach to AI rather than trying to solve for everything in one big go,” Finney says.

That’s the kind of practical example the framework is designed to surface. It helps us find work that’s frequent enough to matter, structured enough for automation, and measurable enough to prove whether the AI investment changed the process.

Moving from savings to reinvestment

Measuring value starts the next conversation. If an AI investment saves time, reduces cost, increases coverage, or improves quality, we need to know what happens next. The number is relevant, but the business outcome is more important.

“We started to evolve our conversation to, ‘So what?’” Campbell says. “You saved money, you saved hours. What did you do with it? Where did the actual business outcome sit?”

That’s the harder part of AI value measurement. A team might use AI to reduce time spent on repetitive work, but the real value depends on how that recovered capacity gets used. In some cases, the reinvestment path is clear. A team can point to more programs delivered, more backlog reduced, more issues reviewed, or faster service delivery.

In other cases, the value is harder to trace. Some AI improvements return small amounts of time to many employees. Those minutes matter, but it’s difficult to prove exactly where each person reinvested them.

We’re careful when it comes to measuring ROI. We know our leaders will ask for it, and it belongs in the broader value conversation. But we don’t want ROI at the center of the story before we have the right cost model, telemetry, and approved data to support it.

For now, we’re focused on the operating discipline: Define expected value, baseline the current state, instrument the AI-enabled process, track results, review the data, and act on what we learn. That discipline is teaching us a number of practical lessons:

• Measurement needs to be built into the design of the AI investment, not added after launch.
• Teams need a baseline for the current process, so they can compare it with the AI-enabled process.
• Teams need to pick measures that fit the scenario.
• Data must have clear ownership, because uncertain data weakens the conversation with business owners and leaders.

Consistency matters as much as the metric itself. When our teams review value on a regular rhythm, they can see trends, test assumptions, and adjust the solution or the process around it. Some measures will be mature, and others will be directional. Some will need better instrumentation. The point is to keep improving the quality of the measurement while keeping the conversation focused on business value.

We’re continuing to build our value measurement muscle across Microsoft Digital. We’re not looking for one perfect formula for every AI investment. Instead, we’re creating a repeatable way to define value, measure it, review it, and use it to guide our next action.

As our AI investments and overall strategy mature, that framework helps us stay honest about what we know, clear about what we still need to learn, and focused on the outcomes that AI is designed to improve.

Key takeaways

Here are five actions you can take to help measure the impact of AI investments at your organization, based on what we’ve learned in our own efforts:

• Start with business outcomes. Define the business result you want first, so you can measure whether the AI investment creates real value.
• Choose metrics that fit the scenario. Select measurement areas that match the workflow, such as time saved, cost reduced, quality improved, or risk lowered.
• Establish a baseline before launch. Capture current performance before implementation, which will enable you to compare results and show what changed.
• Review results on a regular rhythm. Check performance consistently with the relevant stakeholders so that you can spot trends and adjust quickly.
• Reinvest gains intentionally. Use the time, savings, or capacity that AI generates to deliver clear value and ROI, instead of treating efficiency as the final goal.

Try it out

Get started with Microsoft Agent 365.

Related links

• Learn how a data council is powering our unified data strategy at Microsoft.
• Discover how a Center of Excellence is powering the technical veracity of AI at Microsoft.
• Explore how we’re reshaping Microsoft with continuous improvement and AI.
• Find out why Responsible AI matters and how we’re infusing it into our internal AI projects at Microsoft
• Read about the enterprise tools and solutions at Microsoft AI.
• Check out more details about Responsible AI at Microsoft.
• Learn more about the opportunity for AI in the Microsoft 2026 Work Trend Index Annual Report.

The post Measuring the impact of our AI investments in IT at Microsoft appeared first on Inside Track Blog.

At Microsoft Digital, the company’s IT organization, we’re using a set of employee councils to guide how we deploy and adopt AI across our organization. We took this approach for a simple reason: We need a model that can keep pace with technological change while staying grounded in business value.

Our baseline expectation for AI at Microsoft is practical.

Our AI initiatives need to deliver value every quarter, and we track progress through KPIs reviewed monthly at the leadership level. That standard creates healthy pressure. It also exposes a common gap many organizations experience in the beginning stages of their AI efforts: It’s easy to generate a lot of activity without producing business results.

“Our strategy council is how we separate signal from noise in our AI acceleration. It identifies the top scenarios with the greatest enterprise leverage, sharpens our executive focus on what truly matters, and enforces a one-to-one alignment between the work we resource and the outcomes we’re accountable to deliver.”

Don Campbell, principal group technical program manager, Microsoft Digital

In our council-based approach to AI, different councils focus on different needs. Together, they help us move from experimentation to repeatable, enterprise-grade outcomes. We think of these councils as building blocks that we can combine and evolve as the technology, the business, and our operating model change.

In this model, AI strategy needs its own council to help guide the overall approach and align our efforts across the enterprise. At the highest level, the strategy council is where we prioritize what matters most, decide how it maps to the outcomes we’re accountable for, and determine how we’ll judge progress month over month.

“Our strategy council is how we separate signal from noise in our AI acceleration,” says Don Campbell, a principal group technical program manager in Microsoft Digital. “It identifies the top scenarios with the greatest enterprise leverage, sharpens our executive focus on what truly matters, and enforces a one-to-one alignment between the work we resource and the outcomes we’re accountable to deliver.”

Strategy keeps our AI conversation at Microsoft from getting bogged down in discussions of tools and technology and forces us to keep our focus on the main goal: What are we trying to change in the business, and how will we know if we’ve succeeded?

“We need a single cohesive story to bring together what’s happening across the organization and how those efforts contribute to real impact. The goal is to stitch that story together and solve for redundancies—if one part of the org has already solved a problem, another team shouldn’t have to reinvent the solution.”

Mohit Chand, principal group engineering manager, Microsoft Digital

AI strategy in action: Focus, alignment, and a monthly cadence

As our AI work at Microsoft accelerates, we continuously balance two truths at the same time. We want broad experimentation, because it’s how teams and employees learn fast. At the same time, we want our people to focus on what matters most to our enterprise and to ensure we are identifying and reducing potential redundancy.

Maintaining this balance is the core work of our AI strategy council. It helps us identify the AI-enabled scenarios that will deliver the most value, then keeps us honest about whether we’re delivering against the outcomes we’ve committed to.

“We need a single cohesive story to bring together what’s happening across the organization and how those efforts contribute to real impact,” says Mohit Chand, a principal group engineering manager in Microsoft Digital. “The goal is to stitch that story together and solve for redundancies—if one part of the org has already solved a problem, another team shouldn’t have to reinvent the solution.”

We have a detailed process that relies on engaging with our subject matter experts to keep the most impactful AI portfolio visible and actionable. We use it to summarize and track our top scenarios. Our AI strategy council views this process as work that’s always in process—a living view that changes as products ship and priorities shift. Delivered items come off, emerging bets go on, and the continuing discussion stays anchored to our goals.

“The pace right now is incredible. There’s a lot of excitement, but there’s also a risk if it’s not sustainable. A big part of our focus is figuring out how to take churn out of the system and make this work long‑term—for the business and for our people.”

Myron Wan, principal group product manager, Microsoft Digital

A tight rhythm and monthly cadence ensures that our conversations stay focused on whether the biggest bets are moving the needles we care about. That cadence helps us answer the questions leaders and customers are asking on a regular basis:

• Where are you investing?
• Why?
• What’s working?
• What would you do differently next time?
• What did you learn along the way?
• Where are we reinvesting and creating additional agency or capabilities for our employees?

When these questions frame the conversation, the outcomes naturally align to the direction our enterprise wants to go.

Structuring strategy and execution

To make our strategy council effective, we needed more than just a monthly meeting. We needed a way to organize work, assign accountability, and compare progress across very different teams without forcing everyone into the same mold.

We use three practices to accomplish this:

• Group work into clear focus areas
• Rely on product owners to drive execution
• Use a shared approach for measuring value

“The pace right now is incredible,” says Myron Wan, a principal group product manager in Microsoft Digital. “There’s a lot of excitement, but there’s also a risk if it’s not sustainable. A big part of our focus is figuring out how to take churn out of the system and make this work long‑term—for the business and for our people.”

Working into focus areas

When we started to scale our initial AI efforts, our first challenge was simple: Everyone is building, but not always toward the same destination. That’s why we split the work into two primary focus areas that match how an IT organization operates. These areas include:

• AI for corporate functions. Our AI work supports teams like finance, legal, and HR. We focus on removing friction from core processes and helping people make faster, better decisions.
• AI for IT. We support AI initiatives across our IT operations in several areas:
  • Network and devices. We’re using AI for faster network device lifecycle management, more efficient incident management and remediations, and lower costs
  • Employee experience. We want to enable Microsoft employees to contribute real business value and enjoy how they do it.
  • Support. We’re reducing tickets, resolving issues faster, and helping support teams stay ahead instead of reacting.
  • Tenant management and security. Our AI investments strengthen how we run and protect our Microsoft 365 tenant.

From there, we map AI initiatives into those focus areas so we can see what’s happening across the landscape and spot gaps, overlaps, and opportunities to reuse what already exists.

“We operate a council which helps set direction, but product management oversees execution of the solutions. Without product management’s ownership, our council would degrade into just a low-level approval step, which quickly makes us a roadblock instead of an enabler.”

Bill O’Brien, principal group product manager, Microsoft Digital

This step sounds basic, but it changes the conversation. It moves us away from a list of disconnected projects and toward a portfolio view, where we can figure out which scenarios matter most, where we have duplication, and where we need to invest more.

Keeping execution with product owners

While our AI strategy council sets direction, execution lies strictly with our product owners. A strategy council can’t run delivery. If it tries, it slows everything down. We avoid that trap by separating direction from doing.

“We operate a council which helps set direction, but product management oversees execution of the solutions,” says Bill O’Brien, a principal group product manager in Microsoft Digital. “Without product management’s ownership, our council would degrade into just an approval step, which quickly makes us a roadblock instead of an enabler.”

This clarity on roles and responsibilities helps teams work fast and ensures the council remains strategic. Product owners can prioritize week by week, learning from usage, adjusting product features, and shipping value. The council can stay focused on the portfolio and which bets rise to the top, what tradeoffs to make, and how we communicate progress and business outcomes to leadership.

“The first part of our strategy was all about getting people to a point where they could identify what they were trying to accomplish and report on how they’re getting there. We created a value measurement framework in partnership across multiple key players to give teams an idea of what’s valuable to the organization.”

Keith Bunge, principal software engineer, Microsoft

Using a common value framework

Once we can see the portfolio and have identified clear ownership, we still need one more thing: A shared language for determining value. Early in our journey, we were tempted to declare success simply based on activity—how many pilots we launched, how many tools we built, or how many demos we could show.

That activity is critical for innovation, but it doesn’t help us understand and drive business value. We needed teams to define the value they expect to deliver, explain why, and show how they’ll measure it.

“The first part of our strategy was all about getting people to a point where they could identify what they were trying to accomplish and report on how they’re getting there,” says Keith Bunge, a principal software engineer at Microsoft. “We created a value measurement framework in partnership across multiple key players to give teams an idea of what’s valuable to the organization.”

That framework helps in two ways:

1. It forces upfront discipline: Teams clarify what value they’re chasing and how they’ll prove they’ve achieved it.
2. It allows for fair comparison across very different initiatives: Everyone is describing impact in consistent categories, rather than inventing a new scorecard each time.

As our approach matures, we’re also pushing past raw savings metrics to the harder question: What did we do with the time or money we saved, and how did this create increased agency or capabilities?

Combining strategy and execution: A practical example

Here’s how that looks when we apply this approach to a real-world scenario.

Say one of our teams is proposing an AI solution to automate energy management in buildings. On day one, the idea sounds great: use signals from internal temperature and movement sensors to automatically adjust HVAC usage across large buildings. But the role of the strategy council isn’t just to approve great ideas. We ask for a clear value claim and a measurement plan.

Bunge provides a solid value claim for the example above.

“I’m going to come up with an automation that allows me to automatically turn off air conditioning in a building based on signals that we have from our internal sensors,” he says. “I think I’m going to be able to save $100,000 a quarter with this project because of my usage projections overlaid on the HVAC costs over the past five years.”

That kind of statement is useful, because it’s specific. It also forces the next question: How do you prove it? We’re asking teams to explain what data they’ll use as a baseline, what counts as savings, and how they’ll report progress over time.

We’re also raising the bar as the program matures.

Early on, teams may be able to prove that they saved time or reduced effort. As we get more rigorous, we’re pushing the “so what” conversation: What happens with the time saved, and what changes in the business as a result? It’s all part of moving from value measures to business outcomes, including what gets reinvested and where impact actually accrues.

Connecting AI strategy to the rest of our councils

Our AI strategy council is not the final measure or a standalone solution. We use it as the front door to a broader ecosystem that helps us move AI from ideas to enterprise outcomes.

“Business strategy needs to lead the AI strategy. Business strategy defines the ‘what and why.’ AI defines the ‘how’ to get the business strategy implemented with real value. We need to use AI to help us achieve the business strategy, not the other way around.”

Qingsu Wu, principal group product manager, Microsoft Digital

Here’s how it fits together in practice. We use the strategy council to set our direction, and we keep a short list of top scenarios visible. Then we rely on complementary councils and capability groups to make those scenarios real: teams are building skills and patterns through enablement, strengthening foundations through data readiness, and applying Responsible AI practices so solutions scale safely.

We use process improvement and change management to drive adoption, because a strong model doesn’t matter if people don’t change how they work. And we use metrics and value tracking to keep the entire system accountable.

We’re also keeping a clear principle at the center: Business strategy leads, AI follows.

“Business strategy needs to lead the AI strategy,” says Qingsu Wu, a principal group product manager in Microsoft Digital. “Business strategy defines the “what and why.” AI defines the ‘how” to get the business strategy implemented with real value. We need to use AI to help us achieve the business strategy, not the other way around.”

That distinction matters as AI capabilities keep expanding and as teams continue to move faster.

Moving forward

As this work matures, one thing is clear: Strategy isn’t something we finish and move on from. It’s something we’re actively maintaining as AI adoption accelerates.

What we’ll do next is consistent with that mindset.

We plan to keep scaling what works while tightening and improving the system around it. We’re strengthening alignment across teams, pushing for more consistent measurement of impact, and sharpening how we choose the right approach for the right problem. We’re also treating strategy as a living motion, not an annual document, because business and technology are constantly changing.

We know that what got us here isn’t going to get us where we need to go next. We’re excited about the continued evolution of AI strategy here at Microsoft Digital as we focus on scale, alignment to real business problems, and making sure the pace is sustainable for our business.

Key takeaways

Leaders who are scaling AI across IT can apply these lessons from our experience to stay focused, move faster, and deliver measurable business impact.

• Treat strategy as an ongoing practice. We’re revisiting priorities regularly to keep our AI work aligned with changing business goals.
• Separate direction from execution. We’re using a small strategy group to set focus and expectations while product teams remain accountable for delivery.
• Create a shared language for value. A consistent way to describe impact helps leaders compare initiatives, make tradeoffs, and explain progress with confidence.
• Let experimentation mature into focus. Early exploration builds capability, but scaling requires narrowing attention to the AI scenarios that matter most.
• Design for scale and sustainability. We’re paying as much attention to reuse, data readiness, and team sustainability as we are to speed and innovation.

Try it out

New to Microsoft 365 Copilot? Check it out!

Related links

• Check out how our data council is powering our unified data strategy at Microsoft.
• Learn how we’re powering the technical veracity of AI at Microsoft with a Center of Excellence.
• Find out how we’re reshaping Microsoft with continuous improvement and AI.
• Learn more about our approach to Responsible AI at Microsoft.
• Read about the enterprise tools and solutions at Microsoft AI.
• Learn how Azure AI apps and agents can help you build enterprise-scale AI solutions.

The post Visualizing success: Steering your AI deployment with a strategy council appeared first on Inside Track Blog.

Imagine a facilities service technician responding to a high‑priority heating issue. The service ticket has the right building, floor and space, but no clear indication of where in the space the problem exactly is—this can be a particularly challenging problem when dealing with large spaces like we do here at Microsoft. Making matters more complicated, the technician might also need specialized schematics that are behind walls and ceilings.

In the past, it might have taken that technician a long time to get that necessary context.

Not anymore.

Thanks to a solution we created that is internal to Microsoft, our indoor maps are now always current. (And while this solution isn’t presently available to customers, we’re sharing our story around it in hopes that you can learn from our approach.)

With these maps available, the service ticket mentioned above now includes a visualization of the floor plan, which immediately indicates the correct room and highlights the faulty equipment’s exact location (if already on the floor plan).

The technician can now diagnose the problem in minutes. This can be done on their equipment, without the need to understand how to use specialized software or having knowledge of the building’s layout.

This shows the value of indoor maps when they work correctly. But our maps here at Microsoft didn’t always work this way.

A long-standing map gap

For years, facility service technicians at Microsoft could access floor plans that were stored in a central repository but needed specialized software to view them. Our floor plan files came from a wide variety of vendors, with different naming conventions and drawing standards.

Initially, we created indoor maps using this data for some buildings requiring a lot of manual work. As a result, updates to the maps were slow and expensive. As soon as a map slipped out of sync with reality, teams stopped relying on it.

“Enterprises have struggled for years to maintain accurate indoor maps. The heart of this struggle is ultimately standards that are applied inconsistently to the source material.”

Vishu Admal, program and product lead, AI indoor maps initiative, Microsoft Digital

These issues had a real impact on our day‑to‑day operations:

• Our facilities teams didn’t have the spatial context in their work order to understand exactly where problems were happening, because they didn’t have convenient access to detailed map layers that indicated the precise location of building elements (such as plumbing, or heating and cooling systems).
• Our security teams couldn’t easily overlay incident data on floor plans.
• Our IT teams couldn’t map device locations to the real world with confidence and relied on PDF version of maps.

“Enterprises have struggled for years to maintain accurate indoor maps,” says Vishu Admal, our program and product lead for our AI indoor maps initiative here in Microsoft Digital, the company’s IT organization. “The heart of the struggle is ultimately standards that are applied inconsistently to the source material.”

Recently, we’ve developed an intriguing solution: An AI‑driven mapping data pipeline—with out-of-the-box large language models (LLMs)—that recognizes patterns, identifies inconsistencies, and produces updated indoor maps every day, as the floor plans evolve and change.

Today, that data pipeline is keeping our indoor maps up to date for more than 500 buildings around the world. It supports the systems and teams that keep our campuses operating every day—facilities, space management, security, and IT.

And more importantly, this solution makes sure that when someone has a high-priority need for an indoor map, it’s completely accurate and current.

“The problem has always been tripping up on the varying quality and consistency of the AutoCAD files. This is especially true at enterprise scale, where drawings come from different firms and have different standards.”

I.M. Ndimubanzi, engineering manager, Microsoft Digital

From CAD to operational maps: Finding a solution

Some indoor mapping projects start with a simple assumption: The floor plan is already structured data.

Our project didn’t have that. What we had was computer-aided design (CAD) geometry, plus text, plus years of vendor variation.

Different architecture and construction partners drew buildings in different ways. Labels, layers, symbols, and even basic conventions (like how rooms were “closed” in a drawing) weren’t consistently followed. That inconsistency is what broke any attempts at automation.

“The problem has always been tripping up on the varying quality and consistency in the AutoCAD files,” says I.M. Ndimubanzi, an engineering manager in Microsoft Digital who is the technical lead for our indoor maps initiative. “This is especially true at enterprise scale, where drawings come from different firms and have different standards.”

So, we built a data pipeline that assumes the input will be messy, but it can still produce a reliable output, time and again.

Converting CAD geometry into render-ready maps

We split this work into three stages. In brief, these can be labeled as: parse, interpret, and serialize.

1. Parse CAD input into machine-usable signals

We start by extracting raw geometry and text from CAD using open-source parsing libraries. That gives us the basic data we can feed into downstream steps without forcing every file to look identical first.

2. Use AI for interpretation and hygiene

The hardest part of the work isn’t reading the CAD file. It’s interpreting what the drawing means when dealing with variations in room names, abbreviations, and other conventions (which may differ by vendor, region, or even building).

This is where we use AI-driven large language models to transform the extracted CAD signals into structured data.

Instead of manually cleaning and translating each file, we use AI models to ingest CAD drawings directly and interpret what the data represents. Walls become walls, rooms become rooms. Doors, elevators, and fixtures are identified as distinct, usable elements rather than raw line work.

That same approach helps solve a long‑standing data hygiene issue: inconsistent naming. For example: across the portfolio, the same type of space can appear as “Conference Room,” “Conf. Rm.,” “MPR,” or “Multi‑Purpose Room.”

The AI helps normalize those variations into standardized space categories, turning messy labels into consistent, structured data that can be reused across systems.

3. Serialize to GeoJSON with proven tooling

Once AI produces a structured representation, we convert the data into GeoJSON—a popular spatial data exchange and rendering format—using open-source tooling.

GeoJSON gives us a clean, reliable data source for our mapping tools. This keeps the final output consistent and predictable, which is critical for rendering at scale and integrating into other applications.

Note that this design is intentional: AI does the interpretation, while deterministic tooling does the formatting. This separation is what makes the pipeline stable.

“As long as they can add this SDK in their application or interface, they can connect to our databases. It gives them access to our map library.”

Amr Dawood, senior software engineer, Microsoft Digital

Creating an SDK that makes maps usable everywhere

A mapping pipeline is only valuable if other teams can use the results without becoming mapping experts. That’s why we paired the mapping pipeline with a software development kit (SDK) that makes indoor maps embeddable inside operational tools.

“As long as they can add this SDK in their application or interface, they can connect to our databases,” says Amr Dawood, a senior software engineer in Microsoft Digital. “It gives them access to our map library. They can use predefined functions to choose the buildings, the layers they want to render, and how they want to display and order those layers.”

We built this SDK so product teams can treat the new indoor maps like any other UI component:

• Drop it into a web app and connect to our map storage without building custom integration
• Choose buildings and floors using built-in selectors and navigation patterns
• Toggle layers to show only what matters for the scenario, including specialized operational layers
• Overlay operational data on top of the floor plan, so teams can visualize work in spatial context, not just in tables
• Make the map interactive by adding pins, polygons, and other spatial annotations directly in the app experience

Under the hood, the SDK is built on MapLibre, and open-source toolset for interactive maps and geospatial visualization. It gives the team a mature rendering foundation without locking them into a bespoke mapping stack.

We also built the SDK for “plug and play” adoption. That means providing examples, tutorials, and guidance so teams can embed maps quickly and consistently, instead of reinventing the same integration patterns across multiple apps.

This is the part of the solution that turns the pipeline into a platform. It’s how we move from “we have maps” to “any team can build with maps.”

Turning floor plans into user interfaces

We’re currently integrating indoor maps directly into several of our facilities processes and applications. As we do, we’ve noticed an important change: Employees stop treating the floor plan as reference material and start treating it as the user interface for detailed building information.

“Managing a physical space through tables and charts only gets you so far. It’s much more powerful when that information is visualized through a floor plan.”

Harris Thamby, integration lead, Microsoft Digital

Take our LiveCampus app, for example.

Live Campus is an internal app used by the Microsoft Facilities team to aggregate all operational information about Microsoft buildings into a single, comprehensive view. It simplifies facilities management by integrating various data points and presenting them on a visual floor plan.

Historically, building data lived in tables, tickets, and dashboards scattered across multiple systems. None of it was spatially oriented by default. If something broke, you read a text description, then tried to figure out the location.

With our new indoor map solution, location comes first, and it’s bringing life to Live Campus.

Instead of navigating through multiple systems to gather information, Facilities employees can access everything they need in one place. The floor plan serves as the primary interface, allowing users to overlay different types of information, such as facility tickets, service issues, and role-based employee data.

This visual approach helps facility managers quickly identify and address problems, improving operational efficiency.

“Everything is aggregated and presented as a building view,” says Harris Thamby, who leads integration work for Live Campus in Microsoft Digital. “But managing a physical space through tables and charts only gets you so far. It’s much more powerful when that information is visualized through a floor plan.”

Live Campus uses the latest AI‑generated maps through our SDK. That means facilities teams always see the current layout, not a snapshot from months ago.

And because the map is up-to-date, teams can trust what they’re seeing.

We’re also making big changes to FacilityLink, our internal implementation of Dynamics 365 Field Service. The new indoor maps solution is becoming the center of the technician experience.

“Our facilities teams will use the same maps in Dynamics 365 Field Service. They can turn layers on and off to see exactly what they need. Where are the tickets? Where are people sitting? What areas are impacted?”

Sonaly Choudary, program manager, Microsoft Digital

As the integration progresses, technicians will be able to open a work order and see the associated indoor map alongside the request, either in FacilityLink on the web or through Microsoft Dynamics 365 Field Service Mobile on a phone or tablet.

From the same screen where they read the details of the issue, they can also visualize the exact floor, room, and surrounding spatial context of the problem. This will reduce the need to switch between systems or return to a desk to look up drawings, helping technicians diagnose issues faster and with more confidence while they are already on site.

That spatial context—available on a mobile device instantly—changes how work gets prioritized.

“Our facilities teams will use the same maps in Dynamics 365 Field Service,” says Sonaly Choudary, a program manager with Microsoft Digital. “They can turn layers on and off to see exactly what they need. Where are the tickets? Where are people sitting? What areas are impacted?”

“When a technician responds to a work order, every minute matters. Historically, they had to jump between systems to find drawings, interpret layouts, and understand what was behind walls or ceilings. We’re eliminating that friction and giving technicians the spatial context they need to diagnose and fix issues faster.”

Michelle Schaefer, principal program manager, Microsoft Digital

Instead of scanning lists of open issues, facilities managers and technicians can see clusters of problems on a single floor.

They can spot patterns and determine when a single issue is affecting multiple teams or when a problem is isolated.

“When a technician responds to a work order, every minute matters,” says Michelle Schaefer, a principal program manager in Microsoft Digital. “Historically, they had to jump between systems to find drawings, interpret layouts, and understand what was behind walls or ceilings. By embedding AI‑generated indoor maps directly into FacilityLink, we’re eliminating that friction and giving technicians the spatial context they need to diagnose and fix issues faster.”

The result?

It’s faster and easier for facilities teams to understand where an issue is, what assets are involved, and how to act—without leaving the system they already depend on. Indoor maps become a practical extension of FacilityLink, embedding spatial awareness directly into day‑to‑day facility operations. If a service ticket is opened, it’s no longer just text; it’s a pin on the map.

Outcomes and what’s next

As our maps become reliable and embedded into daily workflows, the solution stops being a mapping project. It becomes a platform with the potential for impact beyond facilities operations.

The most immediate outcome has been scale. We’re moving from selectively supporting a limited set of buildings to supporting the entire real estate portfolio. Maps will be onboarded, updated, and maintained automatically, without the manual effort that had slowed previous approaches.

That automation changed the economics.

Instead of paying for one‑off conversions or ongoing vendor updates, the mapping pipeline runs continuously. As layouts change, the maps are automatically updated. That consistency is what allows downstream systems to depend on the data.

We’re continuing to refine the mapping pipeline as models improve and standards evolve. The SDK can be expanded to support more scenarios and platforms. And additional layers and integrations will unlock new operational use cases across facilities, IT, and security.

As teams across Microsoft have learned more about AI indoor maps, the excitement and adoption potential keeps growing. When spatial data is accurate, current, and reusable, teams stop asking whether they can visualize a problem and start asking what else they can do with it.

That’s the real outcome of this work: Not just better maps, but better decisions, built on a shared, trusted source of spatial truth.

Key takeaways

Use these lessons to help you with your own efforts to produce indoor maps you can trust and embed in day-to-day operations:

• Start by standardizing your source drawings and naming conventions. Inconsistent CAD layers, labels, and symbols are the main blockers to automation, so define what “good input” looks like before you scale.
• Design your pipeline to expect messy input, not perfect files. Separate the work into clear stages (for example: parse, interpret, serialize) so you can improve each step without rebuilding everything.
• Use AI for interpretation and deterministic tooling for formatting. Let models infer meaning from CAD files, then convert to a stable format, such as GeoJSON, with proven conversion tools for predictable rendering.
• Build (or adopt) an SDK, so other teams can add maps to tools without becoming mapping experts. Provide common user interface patterns (building/floor lection, layer toggles, overlays, annotations) to standardize implementations across apps.
• Make maps useful by embedding them inside the tools people already use. Adoption accelerates when maps show up in tickets, dashboards, and mobile field workflows.
• Plan for automatic and continuous updates, governance, and trust. Daily automatic refresh, clear ownership, and validation checks keep maps aligned to reality and avoid drift.

Try it out

Learn more about the Dynamics 365 Field Service mobile app.

Related links

• See how we’re reimagining campus support at Microsoft with the Employee Self-Service Agent.
• Explore documentation for Azure Digital Twins, a Microsoft solution for modeling real-world spaces.
• Discover our strategies for making Microsoft transportation systems seamless with the power of data and AI.
• Dive into full details on Azure Machine Learning pipelines.
• Read about how to create an interactive search map with Azure Maps.

The post Transforming facility operations at Microsoft with AI maps appeared first on Inside Track Blog.

Our teams across Microsoft Digital—the company’s internal IT organization—leaned in. We built tools, workflows, and AI enabled solutions at speed. Momentum followed, along with real enthusiasm and growth.

“We did a lot of good work building community and excitement. But at some point, we needed to evolve and put more structure around what we’d built.”

Qingsu Wu, principal group product manager, Microsoft Digital

But increasing scale required us to evolve our approach.

As adoption accelerated, we began to see duplication, uneven governance, and growing gaps between strategy and delivery. What helped us move fast early on wasn’t enough to sustain impact over time.

“We did a lot of good work building community and excitement,” says Qingsu Wu, a principal group product manager who leads the AI CoE at Microsoft Digital. “But at some point, we needed to evolve and put more structure around what we’d built.”

AI agents and solutions began appearing across Microsoft Digital. Different teams solved similar problems. Standards were interpreted differently. Reporting was inconsistent, and in many cases manual.

The question was no longer, “How do we help teams try AI?” It became, “How do we turn AI into consistent, measurable outcomes at scale?”

Answering that question required a change in how our CoE operated.

Rather than acting primarily as an advisory group, the AI CoE evolved into an execution‑focused function. Its role expanded from guidance to coordination, helping set priorities, define guardrails, and connect AI work directly to business outcomes.

The goal wasn’t to slow AI innovation down, but to help it move in the correct direction with more agility and better scalability.

Evaluating AI for Microsoft

The AI CoE connects AI strategy to execution across Microsoft Digital. It operates as a cross‑functional coordination layer that sets direction and creates shared accountability for how AI work gets done.

“We can see patterns that a single team can’t. We’re translating AI CoE strategy and enterprise priorities into clear execution plans that work in each organization’s context. That helps us align priorities and make sure the biggest bets are actually landing.”

Ria Khetan, senior program manager, Microsoft Digital

The CoE brings our leaders and practitioners together from AI, data, responsible AI, and operations to answer questions collectively. We use that cross‑disciplinary view to operate above individual projects without losing touch with day‑to‑day reality.

The CoE looks across the organization and answers questions individual teams can’t answer on their own.

• What AI initiatives are already in flight?
• Which ones matter most to the business?
• Where are teams duplicating effort?
• Where do we need clearer standards or stronger governance?

“We can see patterns that a single team can’t,” says Ria Khetan, a senior program manager in Microsoft Digital who helps lead program management for the AI CoE. “We’re translating AI CoE strategy and enterprise priorities into clear execution plans that work in each organization’s context. That helps us align priorities and make sure the biggest bets are actually landing.”

We’ve designed the AI CoE to act as the connective tissue between leadership intent and execution on the ground. It helps ensure that AI work across Microsoft Digital moves forward with purpose, consistency, and measurable impact.

Building transformation on core pillars

The AI CoE establishes a common structure that helps our teams work toward the same outcomes, even when they are building different solutions.

“We use the CoE to bring consistency to how AI work gets done. It gives us a way to step back and ask whether we’re solving the right problems and whether we’re set up to scale.”

Don Campbell, principal group technical program manager, Microsoft Digital

The operating model is intentionally simple.

AI initiatives are reviewed against shared pillars that help teams think beyond individual projects. These lenses ensure the work aligns to business priorities, can scale safely, has a clear delivery path, and supports responsible adoption.

“We use the CoE to bring consistency to how AI work gets done,” says Don Campbell, a principal group technical program manager who leads AI strategy here in Microsoft Digital. “It gives us a way to step back and ask whether we’re solving the right problems and whether we’re set up to scale.”

Our CoE uses these four pillars to guide our work:

• Strategy. We work with product and feature teams to determine what we want to achieve with AI. They define business goals and prioritize the most important implementations and investments.
• Architecture. We enable infrastructure, data, services, security, privacy, scalability, accessibility, and interoperability for all our AI use cases.
• Roadmap. We build and manage implementation plans for all our AI projects, including tools, technologies, responsibilities, targets, and performance measurement.
• Culture. We foster collaboration, innovation, education, and responsible AI among our stakeholders.

These pillars are the common language that helps us connect strategy to execution and make decisions across all teams and scenarios at Microsoft Digital.

Strategy

Our CoE strategy team’s role is to step back and create clarity.

Our strategy is driven from the organization’s top level, and executive sponsorship is crucial to executing our implementation well. When our transformation mandate comes from the organization’s leader, it resonates in every corner of the organization, every piece of work, and every task. We also encourage and welcome ideas from every level of the organization, empowering individuals to contribute their AI insights.

We maintain a centralized view of AI initiatives across Microsoft Digital, including agents, workflows, and AI‑enabled solutions. That visibility allows our CoE team to identify duplication, surface opportunities to scale successful ideas, and align investments to enterprise priorities. This creates a shared intake and prioritization model.

One of our CoE strategy team’s most significant responsibilities is prioritizing the idea pipeline for AI solutions. All employees can feed ideas into the pipeline through a form that records important details. The strategy team then evaluates each idea, analyzing two primary metrics:

• Business value. How important is the solution to our business? Potential cost reduction, market opportunity, and user impact all factor into business value. As our business value increases, so does the idea’s position in the pipeline priority queue.
• Implementation effort. We focus on clearly defining the problem statement—what the problem is, why it matters, who the customer is, the baseline metrics, and the plan to attribute value pre‑production. This ensures we prioritize AI for the most critical business problems and can measure impact before and after deployment.

By anchoring AI work in business outcomes from the start, the strategy pillar helps ensure the organization’s energy is spent on the work that matters most.

Architecture

Our architecture pillar defines how we help teams scale AI solutions without creating security gaps, compliance issues, or technical debt they’ll have to unwind later.

“The CoE introduces a framework to enable design reviews in the early development phase. We help make sure teams are choosing the right platforms and thinking about security and compliance from the beginning.”

Qingsu Wu, principal group product manager, Microsoft Digital

Before solutions move into broader use, our architecture team helps think through data readiness, platform alignment, and governance requirements. The goal isn’t to prescribe a single architecture, but to make sure foundational decisions won’t limit scale or create risk down the line. Many times, this means doing things before development, while other times it means making improvements after the initial development is done and the product or scenario is launched and being used. We also track our efforts with measurable metrics like usage.

One common pitfall is that teams may gravitate toward the most flexible platforms with full control, without fully understanding the associated security and compliance implications. To address this, we publish clear guidance to help teams choose the right platform—one that strikes the appropriate balance between flexibility and the security and compliance effort required.

Our architecture pillar helps prevent that by reinforcing a set of common expectations. Teams still build locally and move fast, but they do so within a framework that supports reuse, interoperability, and responsible operation built on enabling teams and employees to experiment with guardrails that keep our production systems safe.

“The CoE introduces a framework to enable design reviews in the early development phase,” Wu says. “We help make sure teams are choosing the right platforms and thinking about security and compliance from the beginning.”

Teams are encouraged to build on recommended platforms and services that support enterprise‑grade security, observability, and lifecycle management. This helps ensure solutions can be monitored, governed, and supported over time.

Security and compliance are never treated as downstream checkpoints. Architectural guidance reinforces the need to design with identity, access controls, auditability, and responsible AI principles from the start.

When solutions prove valuable, we look for opportunities to reuse architectural patterns, components, or services rather than rebuilding them in isolation. This reduces duplication and accelerates future work.

Roadmap

Our CoE roadmap team examines our employee experience in the context of our AI solutions and governs how we achieve the optimal experience in and throughout AI projects. It focuses on how our employees will interact with AI. Getting the roadmap right ensures user experiences are cohesive and align with our broader employee experience goals.

We’ve recognized AI’s potential to impact how our employees get their work done.

Their experiences and satisfaction levels with AI services and tools are critical. Our roadmap pillar is designed to encourage experiences across all these services and tools that are complementary and cohesive.

We’re focusing on the open nature of AI interaction.

“We’re surfacing AI capabilities and information when the user needs them, according to their context,” Campbell says. “It makes the user experience and user interface for an AI service less important than how the service allows other applications or user interfaces to interact with it and harness its power.”

A key part of this approach is disciplined experimentation.

Rather than treating every idea as a long‑term commitment, the roadmap pillar helps teams validate value early. Our teams know when they’re in an experimental phase and when they’re expected to operationalize. This gives our leaders a more consistent view of progress and risk. The net result is that dependencies between teams surface earlier, when they’re easier to resolve.

Culture

Our culture pillar ensures that AI adoption across Microsoft Digital is intentional, responsible, and sustainable.

Culture underpins everything we do in the AI space. Ensuring our employees can increase their AI skillsets and access guidance for using AI responsibly are critical to AI at Microsoft.

“We’re driving a shift from ad‑hoc AI usage to intentional, outcome‑driven adoption,” Khetan says. “That requires clarity, education, and shared expectations.”

In practice, that means the culture pillar defines how our teams are expected to adopt AI and integrate it into their work, not just what tools they can use.

Our culture team works with AI champions across the organization to translate enterprise AI priorities into local execution. Those champions act as two‑way conduits, bringing real‑world feedback and blockers back to the CoE and carrying guidance, standards, and learnings back to their teams.

Without this structure, AI adoption tends to fragment as teams experiment in isolation.

Our culture team has published training, recommended practices, and our shared learnings on next-generation AI capabilities. We work with individual business groups at Microsoft to determine the needs of all the disciplines across the organization. That work extends to groups as diverse as engineering, facilities and real estate, human resources, legal, sales, and marketing, among others. 

Responsible AI is embedded throughout that work.

The CoE reinforces responsible AI practices as part of everyday decision‑making—during design, experimentation, and scale. Teams are expected to understand not just what they’re building, but the implications of how they build it.

In the AI CoE, culture isn’t abstract. It shows up in how teams propose ideas, how they design solutions and how they measure success.

Fostering agent innovation

The true value of the AI CoE is evident when strategy, architecture, roadmap, and culture come together around real work.

A clear example of that is how we addressed the rapid growth of AI agents across the organization.

“That’s the core problem we’re trying to solve. In the past, admins had to go to multiple portals just to understand how many agents exist, and they all give different answers.”

Garima Tiwari, principal product manager, Microsoft Digital

Our teams were building agents in different platforms, for different scenarios, and at very different levels of maturity. That flexibility accelerated innovation, but it also made it difficult to answer basic questions.

• How many agents exist today?
• Which ones are in production?
• Which ones touch sensitive data?

The strategy lens helped clarify what mattered most. Our goal wasn’t to inventory every experiment. It was to gain visibility into agents that were active, scaling, or depended on by others, and to ensure those agents aligned to business priorities and Responsible AI expectations.

Architecture quickly followed.

As the CoE looked at how agents were built, we quickly discovered that information about agents was fragmented across tools. Different platforms showed different numbers. Ownership wasn’t always clear. And governance signals were hard to reconcile.

“That’s the core problem we’re trying to solve,” says Garima Tiwari, a principal product manager in Microsoft Digital leading our internal strategy and adoption of Agent 365. “In the past, admins had to go to multiple portals just to understand how many agents exist, and they all give different answers.”

This is where Agent 365—which we use to govern agents here at Microsoft—became a critical enabler.

Agent 365 brings together signals from multiple agent‑building platforms into a single, consolidated view. That visibility allows the CoE and administrators to understand agent inventory, ownership, lifecycle state, and governance posture in one place.

“Agent 365 is really about accurate inventory and observability,” Garima says. “It provides one number we can trust and a way to see how agents are behaving, who they’re interacting with, and whether they’re compliant.”

That architectural clarity changed how decisions were made.

Instead of guessing what was safe to scale, the CoE could see which agents were production‑ready, which needed remediation, and which should remain in experimentation. Security, privacy, and compliance considerations moved to earlier in the lifecycle.

“We can’t scale what we don’t understand,” Wu says. “Agent 365 helps us see what’s actually running so we’re not scaling something blindly.”

The roadmap lens then brought structure to execution.

“What changed was the mindset. Teams started thinking about manageability, security, and scale much earlier, not after an agent was already deployed.”

Don Campbell, principal group technical program manager, Microsoft Digital

Rather than standardizing everything at once, the CoE helped teams sequence work. Some agents stayed in pilot. Others moved toward broader rollout, informed by architectural and governance signals surfaced through Agent 365.

Culture and enablement ran alongside that work.

Teams began factoring operational readiness into design decisions instead of treating governance as a final checkpoint. Agent 365 isn’t positioned as a control tool at the end of the process, but as part of building agents the right way from the start.

“What changed was the mindset,” Campbell says. “Teams started thinking about manageability, security, and scale much earlier, not after an agent was already deployed.”

The outcome wasn’t a single standardized solution.

It was a repeatable approach within a shared CoE framework, supported by platforms like Agent 365, that made scaling AI more visible, more manageable, and more intentional.

That’s what the AI CoE enables at Microsoft Digital.

Key takeaways

If you’re just starting to consider AI usage at your organization, or if you’re already creating a standardized approach to AI, consider the following:

• Start with outcomes, not tools. AI work scales faster when teams align on the business problem first and select technology second.
• Design for scale from day one. Early architectural decisions around data, security, and platforms determine whether solutions can grow—or need to be rebuilt.
• Make experimentation disciplined. Clear paths from prototype to production help teams move fast without committing to ideas that haven’t proven value.
• Treat governance as an enabler, not a gate. Visibility and manageability, supported by platforms like Agent 365, make it easier to scale AI responsibly.
• Create shared accountability. Standard metrics and automated reporting turn AI activity into measurable progress.

Try it out

Learn more about how Microsoft Agent 365 enables agent governance and manageability.

Related links

• Discover, create, and onboard an agent in Agent 365.
• Use and collaborate with agents in Agent 365.
• Learn about responsible AI at Microsoft.

The post Powering the technical veracity of AI at Microsoft with a Center of Excellence appeared first on Inside Track Blog.

AI acceleration, cloud adoption, and rapid growth of enterprise apps have dramatically expanded the attack surface. Every new app introduces a new identity. Every identity carries permissions. Over time, those permissions accumulate, often without clear ownership or regular review.

“An app is another form of identity. In a cloud-first, Zero Trust world, identity becomes the primary security perimeter, and access is governed by the principle of least privilege. Whether it is a user, an app, or an agent, when permissions are overly broad or elevated the blast radius expands dramatically, increasing risk exponentially.”

B. Ganti, principal architect, Microsoft Digital

Inside Microsoft Digital—the company’s IT organization—we recognized this early. Many of our highest‑risk security scenarios didn’t start with malware or phishing. They started with access. Specifically, apps running with permissions beyond what they required.

“An app is another form of identity,” says B. Ganti, principal architect in Microsoft Digital. “In a cloud-first, Zero Trust world, identity becomes the primary security perimeter, and access is governed by the principle of least privilege. Whether it is a user, an app, or an agent, when permissions are overly broad or elevated the blast radius expands dramatically, increasing risk exponentially.”

Traditional security approaches such as periodic reviews, best‑practice guidance, and point‑in‑time hardening weren’t enough in an environment that changes daily. Configurations drift, new apps appear, and risk grows quietly in places that are hard to see at scale.

That reality forced a mindset shift internally here at Microsoft. Security couldn’t be optional. It couldn’t be advisory. And it couldn’t be static.

Our team operates one of the largest enterprise environments in the world, with tens of thousands of apps and a culture built on self‑service and autonomy. That scale drives innovation, but it also amplifies risk.

Our application identities became one of the most complex governance challenges we faced. Our ownership wasn’t always clear. Our permissions were often granted broadly to avoid disruption. And once approved, access rarely came under scrutiny again.

“As a self‑service organization, we empower people to move fast,” Ganti says. “But that also means apps get created, permissions get granted, and not everyone always remembers why.”

The rise of AI‑powered apps and agents—often requiring access to large volumes of data—increased our risk further.

“We’re using Microsoft Baseline Security Mode to move security from guidance to enforcement. It establishes secure‑by‑default configurations that scale across our environment, so teams can innovate quickly without inheriting unnecessary risk.”

Brian Fielder, vice president, Microsoft Digital

We needed a system to reduce that risk systematically, not one app at a time.

Microsoft Baseline Security Mode (BSM) became that system—a prescriptive, enforceable baseline that defines what “secure” means and keeps it that way.

“We’re using Microsoft Baseline Security Mode to move security from guidance to enforcement,” says Brian Fielder, vice president of Microsoft Digital. “It establishes secure‑by‑default configurations that scale across our environment, so teams can innovate quickly without inheriting unnecessary risk.”

Defining Microsoft Baseline Security Mode

BSM is more than just a checklist of recommended settings. It’s an enforced security baseline built directly into the Microsoft 365 admin center, designed to reduce attack surface by default across core Microsoft 365 workloads.

It was developed and then deployed internally at Microsoft, with our team in Microsoft Digital serving as a close design and deployment partner throughout the process.

“The settings in the Microsoft Baseline Security Mode were informed by years of experience in running our planet-scale services, and by analyzing historical security incidents across Microsoft to harden the security posture of tenants. The team identified concrete security settings that would prevent or significantly reduce known security vulnerabilities.”

Adriana Wood, principal product manager, Microsoft 365 security

At a technical level, BSM establishes a minimum required security posture by applying Microsoft‑managed policies and configuration states across services including Exchange Online, SharePoint Online, OneDrive, Teams, and Entra ID. The focus is on eliminating common misconfigurations, rather than theoretical or edge‑case risks.

“The settings in the Microsoft Baseline Security Mode were informed by years of experience in running our planet-scale services, and by analyzing historical security incidents across Microsoft to harden the security posture of tenants,” says Adriana Wood, a principal product manager for Microsoft 365 security. “The team identified concrete security settings that would prevent or significantly reduce known security vulnerabilities. The resulting mitigation controls were implemented and validated in Microsoft’s enterprise tenant, with Microsoft Digital evaluating operational impact, rollout characteristics, and failure modes before making it more broadly available to our customers.”

Legacy baselines rely on documentation and manual implementation. Administrators interpret guidance, apply settings where feasible, and revisit them periodically. In dynamic cloud environments, that model breaks down fast. Configurations drift, exceptions accumulate, and security degrades.

“Before enforcement, administrators can use reporting and simulation tools to understand how a baseline will affect users, apps, and workflows. That visibility allows teams to identify noncompliant assets, prioritize remediation by risk, and avoid unexpected disruptions.”

Keith Bunge, principal software engineer, Microsoft Digital

BSM replaces that approach with policy‑driven enforcement.

Now our controls are applied consistently across the tenant and continuously validated. When our configurations fall out of compliance, our risk surfaces immediately—it’s not discovered months later in an audit. The model is simple: get clean, stay clean.

Another key capability of BSM is impact awareness.

“Before enforcement, administrators can use reporting and simulation tools to understand how a baseline will affect users, apps, and workflows,” says Keith Bunge, a principal software engineer in Microsoft Digital. “That visibility allows teams to identify noncompliant assets, prioritize remediation by risk, and avoid unexpected disruptions. Our team in Microsoft Digital partnered closely with the product group to ensure these capabilities were practical for real enterprise deployments, not just greenfield environments.”

BSM is also not static.

The baseline evolves on a regular cadence to reflect changes in the threat landscape, new Microsoft 365 capabilities, and lessons learned from operating at scale.

From our perspective, BSM is not just a feature. It’s a security operating model. It shifts the default from “secure if configured correctly” to “secure by default.” Security decisions move out of individual teams and into a consistent, centrally enforced baseline. The question is no longer whether a control should be applied, but whether an exception is truly necessary—and how the associated risk will be mitigated.

That shift is what makes BSM sustainable at scale. And it’s why apps—where identities, permissions, and data access converge—became the next focus area for us in Microsoft Digital.

Addressing apps and high-risk surfaces

When we evaluated risk across our environment, one pattern was clear: Our apps represented both our most concentrated and least governed attack surface.

Apps are identities. They authenticate. They’re granted permissions. And unlike human users, they often operate continuously, without reassessment or visibility.

In a large, self‑service environment like ours, apps are created constantly by engineering teams, business groups, and automation workflows. Over time, many of those apps could accumulate permissions beyond what they actually needed, particularly within our Microsoft Graph. Our delegated permissions were especially risky, because they allow apps to act on our employees’ behalf at machine speed across massive data sets.

“As a user, I might not know where all my data lives,” Ganti says. “But an app with delegated permissions doesn’t have that limitation. It can search everything, everywhere, all at once.”

The challenge wasn’t just volume—it was inconsistency.

Our ownership was often unclear. Our permission reviews were infrequent or manual. And once we granted elevated access, we had few systemic controls in place requiring it to be revisited.

Microsoft Baseline Security Mode addresses this directly by treating apps explicitly as identities that must conform to least‑privilege principles.

We started with visibility. We inventoried apps and analyzed permission scopes, authentication models, and potential blast radius. Our apps with broad Microsoft Graph permissions, access to large volumes of unstructured data, or unclear ownership were prioritized. In some cases, we reduced permissions to more granular scopes. In others, we rearchitected apps to use delegated access more safely—or we retired them altogether.

This work was intentionally structured as a burndown, not a one‑time cleanup.

Removing our excess permissions was only half the equation. Preventing them from coming back was just as critical. BSM introduced guardrails earlier in the app lifecycle, to surface and control elevated permission requests before they reached production. New or updated apps requesting high‑risk permissions now trigger consistent review, and in many cases are blocked outright unless they meet strict criteria.

Moving from ‘get clean’ to ‘stay clean’

Reducing risk once is hard. Keeping it reduced is harder.

After our initial application burndown, we quickly learned that cleanup alone wouldn’t scale. Even as we reduced permissions and remediated high‑risk apps, new apps continued to appear. Existing apps evolved, teams changed, and without structural controls, the same risks would inevitably return.

BSM enabled us to shift from remediation to sustainability.

It started with visibility.

We needed a reliable way to detect when apps drifted out of compliance. That meant continuously monitoring permission changes, new consent grants, and scope expansions across our tenant. Instead of periodic reviews, we moved to continuous validation tied directly to the baseline.

Next came risk‑based prioritization.

Not every noncompliance carries equal impact. Our apps with broad Microsoft Graph permissions, access to large volumes of data, or unclear ownership were surfaced first. This ensured our security teams focused on material risk, rather than treating every deviation as equal.

It was equally important for us to control how new risk entered the system.

BSM introduces guardrails earlier in the application lifecycle. Our elevated permission requests are surfaced sooner and reviewed more consistently. In many cases, high‑risk permissions are blocked by default unless clear justification and mitigation are in place. Known‑bad patterns are stopped before our teams build or update apps.

Over time, this enforcement model fundamentally changed the operating posture.

Instead of recurring cleanup campaigns, we moved to continuous alignment. Our environment stays closer to the baseline by default. Our deviations are treated as exceptions that require explicit action, not silent drift.

This “stay clean” capability also reduced operational overhead.

As enforcement and validation moved into Microsoft Baseline Security Mode, we retired custom scripts, dashboards, and manual review processes that were difficult to maintain at scale. Our baseline became the source of truth for application security posture, not a snapshot taken after the fact.

Most importantly, we proved that BSM could scale.

“This isn’t limited to Microsoft 365. This is Microsoft, and it expands over time as more services come into scope.”

Jeff McDowell, principal program manager, OneDrive and SharePoint product group

By combining continuous validation, risk‑based prioritization, and enforced guardrails, we established a repeatable model for sustaining security improvements over time.

That model now serves as our foundation for extending BSM to additional workloads and security surfaces across the enterprise.

“This isn’t limited to Microsoft 365,” says Jeff McDowell, a principal program manager in the OneDrive and SharePoint product group. “This is Microsoft, and it expands over time as more services come into scope.”

Operationalizing Microsoft Baseline Security Mode

Defining a baseline is only the first step. Making it work day‑to‑day is the real challenge.

For us in Microsoft Digital, operationalizing BSM meant embedding it directly into how we run security. That required clear ownership, repeatable processes, and tight integration with our existing workflows.

Governance came first.

BSM creates a clear line between what is centrally enforced and what individual teams can influence. The baseline is owned and managed centrally to ensure consistency across the tenant. Our application owners and engineering teams still make design decisions, but within defined guardrails aligned to enterprise risk tolerance.

This clarity reduces friction.

Instead of debating security settings app by app, our teams start from a shared default. Our security conversations shift away from “Can we make an exception?” to “How do we meet the baseline with the least disruption?”

Operationally, BSM is integrated into our application lifecycle.

New apps are evaluated against baseline requirements early, before permissions are broadly granted or dependencies are established. Changes to existing apps, such as new permission requests or expanded scopes, are surfaced automatically and reviewed in context, rather than discovered months later during audits.

In an environment where apps are constantly being created, updated, and retired, automation is essential. Without policy‑driven enforcement, our security teams would be managing a perpetual backlog of reviews. BSM allows us to focus on true exceptions instead of revalidating the baseline itself.

That baseline is also embedded into our ongoing operations.

Our security posture is monitored continuously, not through periodic snapshots. When our configurations drift or new risks appear, we identify them early and address them while the blast radius is still small. Over time, this reduces both our operational effort and incident response overhead.

Perhaps our most important change was cultural.

BSM normalizes the idea that security defaults are foundational. Our teams still innovate and move quickly—but they do so in an environment where secure is expected, enforced, and sustained.

Embracing the feedback loop as Customer Zero

From the start, our team in Microsoft Digital deployed Microsoft Baseline Security Mode as Customer Zero: We applied early versions in our live, large‑scale enterprise environment, where we fed our real‑world learnings back to the product group. That feedback loop became central to how the platform evolved.

Running BSM at Microsoft scale quickly exposed challenges that don’t appear in smaller tenants. Visibility was one of the first. With thousands of apps and constantly changing permissions, it was difficult to pinpoint which apps violated least‑privilege principles and where security teams should focus first.

Those gaps directly shaped the product. Reporting and analytics were refined to better surface elevated permissions, risky scopes, and noncompliant apps, helping teams move from investigation to action more quickly.

Scalability was another critical lesson.

Controls that worked for dozens of apps didn’t automatically work for thousands. Our team needed policies that were opinionated, enforceable, and operationally sustainable without constant adjustment. That pushed BSM toward clearer defaults and stronger enforcement boundaries.

“What made the collaboration work is that Microsoft Digital was deploying this in a real tenant with real consequences,” Wood says. “Their feedback helped us understand what enterprises actually need to adopt these controls successfully, not just what looks good on paper.”

Over time, this became a virtuous cycle. Our team surfaced friction and risk through deployment. The product group translated those insights into product improvements. We then adopted those same improvements to replace custom tooling and manual processes.

For customers, this matters. The controls in BSM are shaped by operational reality, tested under scale and refined so other organizations don’t have to learn the same lessons the hard way.

What’s next for Microsoft Baseline Security Mode

Future iterations of BSM will expand coverage beyond traditional collaboration services to additional platforms and services, while maintaining the same opinionated approach. The goal is not to restrict environments indiscriminately, but to ensure new capabilities are introduced with security baked in from the start.

As compliance requirements grow more complex and more global, organizations need a consistent, defensible security baseline. BSM provides a Microsoft‑managed standard informed by real‑world attack patterns and enterprise deployment realities.

Controls evolve. Scope expands. Feedback loops remain active. As new risks emerge, the baseline adapts, without requiring organizations to redefine their security posture from scratch.

It’s a foundation designed to support whatever comes next.

Key takeaways

If you’re ready to strengthen your organization’s security posture with Microsoft Baseline Security Mode, consider these immediate actions:

• Establish clear ownership. Assign responsibility for baseline security management to ensure consistency and accountability.
• Implement repeatable processes. Develop standardized procedures to evaluate and enforce baseline requirements throughout the app lifecycle.
• Integrate with existing workflows. Embed security controls into daily operations to reduce friction and streamline compliance.
• Prioritize automation and monitoring. Use automated enforcementand continuous validation for early risk detection and response.
• Foster a security-first culture. Normalize secure defaults and encourage teams to innovate within defined guardrails.
• Design for evolution. Design your baseline to adapt as new services, platforms, and compliance needs arise.

Try it out

Learn how to access and implement Microsoft Baseline Security Mode.

Related links

• Read more about how we’re hardening our digital defenses with Microsoft Baseline Security Mode.
• Announcing Microsoft Baseline Security Mode.
• Increase application security with the principle of least privilege.

The post Deploying Microsoft Baseline Security Mode at Microsoft: Our virtuous learning cycle appeared first on Inside Track Blog.

As our ecosystem of AI tools expands, so does our responsibility and opportunity. We have to guide the process with the right structure, clarity, and confidence.

“With Agent 365, IT leaders can confidently embrace this innovation through a unified control plane that provides the capabilities that enterprises need to ensure agents are governed, observable, and secure—regardless of which tools, frameworks, or models were used to create them.”

Brian Fielder, vice president, Microsoft Digital

We approach the governance of AI as a task we’re shaping in real time while observing the different ways our people are using AI in their daily work.

That’s the advantage of being Customer Zero here in Microsoft Digital, the company’s IT organization. We’re living this transformation across Microsoft 365 every day, evolving our governance model alongside the evolution of AI and agents.

“With Agent 365, IT leaders can confidently embrace this innovation through a unified control plane that provides the capabilities that enterprises need to ensure agents are governed, observable, and secure—regardless of which tools, frameworks, or models were used to create them,” says Brian Fielder, vice president of Microsoft Digital.

Our governance approach is built around two complementary control planes: Microsoft Agent 365 for agents and Copilot controls for Microsoft 365 Copilot.

“We’ve seen the rapid pace of innovation firsthand. As Copilot evolves and agents expand, the control planes we use must evolve also. New AI and agent capabilities raise the bar for governance and management, so at Microsoft Digital, we’re working with our product teams to evolve the management to keep the company secure, informed, and ready for whatever comes next.”

David Johnson, principal architect, Microsoft Digital

These control planes are supported by the four fundamental concepts that we apply to every enterprise system we operate: security, governance, management, and observability.

“We’ve seen the rapid pace of innovation firsthand,” says David Johnson, principal architect in Microsoft Digital. “As Copilot evolves and agents expand, the control planes we use must evolve also. New AI and agent capabilities raise the bar for governance and management, so at Microsoft Digital, we’re working with our product teams to evolve the management to keep the company secure, informed, and ready for whatever comes next.”

This model gives us a consistent way to support new capabilities, encourage responsible experimentation, and help our employees adopt AI and agents with fewer hurdles.

Expanding our AI governance practices

As AI use evolves within our organization, we’re seeing clear patterns emerging. Copilot goes well beyond chat. It can execute tasks, create and modify content directly inside apps, connect systems, and coordinate multi‑step work through agents. The AI ecosystem is becoming more effective at boosting productivity with model choices, agent-to-agent orchestration, and agent mode within applications that leverage natural language to complete tasks.

These patterns are exciting, move fast, and expand how we think about governance.

The shift became clear as teams across Microsoft began experimenting with new AI capabilities in the last few years. Accelerating Copilot usage showed us how quickly people adopt tools to help them work better and faster. Rapid agent growth showed us how much value workers get when AI takes on more complex, multi‑step tasks. These expansions pushed us to evolve our security, governance, and management approaches alongside the technology.

That’s what led us to define two complementary control planes for Copilot and agents—not because one replaces the other, but because they serve complementary roles in the ecosystem. Copilot goes beyond chat, surfacing intelligence directly inside apps, workflows, and context to help people work smarter in the flow of their apps. Agents take on broader responsibilities across services, teams, and data boundaries.

By recognizing the different types of work that Copilot and agents do, we’re better equipped to manage and govern them. We can apply consistent principles, tailor the controls to each type of tool, and give employees a clearer understanding of how each AI capability behaves. It’s an approach that grows with technology, instead of forcing everything into a single frame.

Building governance on foundational pillars

As Copilot and agents expand across Microsoft 365 and the rest of our product offerings, we’ve anchored our approach on the fundamentals of security, governance, management, and observability. These principles have shaped our enterprise systems for years. What’s changing is how we apply them to a fast‑moving AI ecosystem.

Security and governance

Security and governance are the baseline for us at Microsoft. Every new capability—whether it’s Copilot helping you draft, find, or create content, or an agent running an automated workflow—must adhere to security and governance principles.

“The Microsoft 365 admin center is becoming the place where controls come together. Policies, observability, and configuration are in a single experience, so admins don’t have to hunt across multiple portals. That consolidation makes it easier for us to understand how AI is behaving in our tenant and what controls we have available to guide it.”

Mike Powers, senior systems engineer and AI admin, Microsoft Digital

Products like Microsoft Purview and Defender allow us to better understand what data our AI tools are accessing, for how long, and where additional guardrails might be needed as features and usage evolve.

Management

Management completes the foundation, and measurement is how we track our progress.

As AI tools take on more responsibility, we needed a unified way to manage access, lifecycle, and configuration. Agent 365 is evolving the Microsoft Admin Center to serve as a central focal point for agent management and observability. Agent 365 brings together agent information and controls that were previously scattered across different admin experiences and puts them in one coherent place.

“The Microsoft 365 admin center is becoming the place where controls come together,” says Mike Powers, a senior systems engineer and AI admin in Microsoft Digital. “Policies, observability, and configuration are in a single experience, so admins don’t have to hunt across multiple portals. That consolidation makes it easier for us to understand how AI is behaving in our tenant and what controls we have available to guide it.”

It’s how we track adoption, quality, and business value like time saved and reduction in operational costs. It’s how we identify what’s working, where to invest next, and how we can guide product teams with real‑world insights. We look carefully at active agents, usage patterns, assisted hours, sentiment, and the outcomes our people achieve with AI. Different audiences share the same goal: using telemetry to make AI better.

Together, these principles allow us to evolve our governance model without slowing innovation. They give us a steady foundation in a rapidly expanding environment—one where Copilot and agents will continue to grow, intersect, and unlock new ways of working.

Observability with Microsoft Agent 365

The widespread use of agents is an accelerating trend here at Microsoft. We use them to automate multi‑step tasks, build applications in plain language, connect systems, and streamline work that previously depended on manual coordination.

As the number of agents grows and becomes more autonomous, we need a management approach that matches their scale and autonomy. That’s what Microsoft Agent 365 gives us—a control plane designed for AI and agentic workloads that operate across platforms and traditional admin boundaries.

Agent 365 provides a registry for agents that lets us discover and understand how agents behave across Microsoft 365. It shows us who built them, who can use them, and what data they can access. From a single admin console, we can observe and manage agents created across different platforms. Day to day, Agent 365 gives AI admins agent observability we didn’t have before, and a way to connect insight to action.

“Agents represent a significant and growing workload that tenant administrators manage as part of day‑to‑day operations,” Powers says. “Agent 365 helps bring clarity to a diverse and rapidly scaling agent population by providing a centralized place to observe and manage how agents operate. This centralized approach is bringing together admin teams like never before so we can apply broad expertise to agent management.”

That clarity matters.

Agents behave differently than Copilot experiences. They can run continuously, trigger processes automatically, and touch systems across organizational boundaries. By treating them as advanced workloads, we can apply governance that supports experimentation without losing control over the ecosystem.

Agent 365 gives teams the confidence to build agents, knowing there’s a clear, consistent framework behind them. It helps ensure agents scale responsibly, are discoverable, and align to the enterprise patterns that keep Microsoft secure and productive.

Keeping track of Copilot controls

We rely on Copilot controls to give us a unified way to govern how different Copilot experiences show up for employees.

Copilot controls aren’t a single product. It’s a fabric of controls, insights, and guardrails that help us guide Copilot usage as it grows. It brings together settings, reports, and policies that once lived across separate admin surfaces and connects them into one coherent system.

“Copilot controls bring everything into one place, so admins don’t have to jump across different reports. It gives them a holistic view of Copilot health. That includes licenses, sentiment, usage, and recommendations. It’s everything they need to understand how Copilot is working in our tenant.”

Amy Ceurvorst, direct of business programs, Microsoft Digital

At its core, Copilot controls help us manage three things:

• Who has access
• How the experience is configured
• How we measure adoption and value

It’s how we track whether licenses are assigned as expected, whether teams are using Copilot regularly or occasionally, and where configuration gaps may exist. It also recommends changes that can make Copilot more effective and secure.

As Copilot evolves, our Copilot controls will evolve with it. New features, security patterns, and use cases all plug into the same foundation. That gives admins a rhythm they can rely on, even as the technology continues to move rapidly.

It also gives business leaders clearer visibility into how Microsoft 365 Copilot helps people work—how often it’s used, what tasks it supports, and where impact shows up.

“Copilot controls bring everything into one place, so admins don’t have to jump across different reports,” says Amy Ceurvorst, a director of business programs in Microsoft Digital. “It gives them a holistic view of Copilot health. That includes licenses, sentiment, usage, and recommendations. It’s everything they need to understand how Copilot is working in our tenant.”

That clarity is critical. It helps us guide Copilot responsibly without slowing its momentum. It gives our admins confidence in how the experience behaves. It gives our engineering teams the feedback they need to keep improving the platform. And it gives our employees a secure, well‑governed environment where they can adopt Copilot at their own pace.

Applying Agent 365 and Copilot controls as Customer Zero

We use Agent 365 and Copilot controls every day. They help us understand what AI is doing inside Microsoft, how these tools are evolving, and where we need to focus our efforts next.

These systems give us visibility we didn’t have a year ago, as well as a way to move faster without losing alignment across security, IT, and business teams.

“Measurement tells us what’s really happening. It shows us where people are finding value and where they need help. We can see the friction points, the successful patterns, and the opportunities that aren’t obvious from the surface. Having that level of insight lets us give the product team clear, actionable feedback.”

Tanya Roberts, senior business program manager, Microsoft Digital

Understanding how agents perform in the real world is essential. With Agent 365, we look at what’s being created, what’s actively being used, and which workflows people rely on most. We review how agents are scoped and published, and we check whether they’re operating as expected. These signals help us see emerging patterns—what’s gaining traction, what’s causing confusion, and where we need clearer controls.

The same applies to Copilot.

Copilot controls give us a consolidated view of how Copilot appears across the tenant—licenses, usage, sentiment, and recommended configuration changes. We use that data to advise product groups, flag issues early, and help business teams to adopt Copilot in ways that make sense for their work. Internally, these insights reduce friction. Externally, they help shape the product.

Cross‑team collaboration is essential. Security teams watch for data exposure risks. IT teams manage configuration and rollout. Business units surface scenarios they want to enable. We coordinate across all these groups so Copilot and agents can scale smoothly.

Measurement ties it all together.

“Measurement tells us what’s really happening,” says Tanya Roberts, a senior business program manager in Microsoft Digital. “It shows us where people are finding value and where they need help. We can see the friction points, the successful patterns, and the opportunities that aren’t obvious from the surface. Having that level of insight lets us give the product team clear, actionable feedback. We can connect the dots between what people are trying to do and what the technology needs to support next.”

This is how we make AI real and practical. We learn from what happens in production, evolve the controls, and feed those lessons back into the product. It’s an ongoing cycle that grows stronger as adoption increases.

Looking forward

The AI landscape isn’t slowing down. Copilot will keep getting smarter and more broadly used across other apps and services. Agents will take on more complex work. And the boundaries between them will continue to blur as new capabilities emerge across Microsoft 365. That’s why our governance model has to evolve alongside the technology.

We’re designing for a future where AI spans more systems, touches more data, and supports more business processes. That means deeper integration between Agent 365 and our Copilot controls; more connected signals across security, management, and measurement; and governance patterns that hold up no matter how AI capabilities shift.

We expect the control planes we use will continue expanding in ways that give admins even more clarity. We’re looking forward to seeing richer telemetry across Copilot and agents. We plan to develop simpler ways to scope, publish, and update AI workloads. And we anticipate more advanced governance features, which will help organizations understand not just what AI is doing, but why it’s doing it.

Our work with Microsoft product teams as Customer Zero will continue to shape this evolution. As part of this process, we can provide real‑world insights about how AI behaves at enterprise scale. That feedback is already influencing how controls show up in the Microsoft 365 admin center and how Agent 365 is expanding to support new workloads. These feedback loops will only get stronger over time.

We’re building our AI management approach into a living system that adapts to new capabilities, new risks, and new opportunities. A system that supports innovation instead of slowing it down. And one that keeps Microsoft—and our customers—confident as the AI stack keeps changing.

Key takeaways

If you’re establishing governance for Copilot and AI agents in your organization, consider these actions to drive responsible, scalable adoption:

• Start with governance fundamentals. Use security and governance, management, and observability as your pillars before layering in other tools or processes. Many of the same fundamentals that unblock Copilot provide the reason why a tenant can be comfortable with knowledge-only agents. 
• Understand the unique and intersecting governance paths for Copilot and agents. Both have some of the same fundamentals but Copilot and agents have distinct AI controls, with different responsibilities, risks, and oversight needs.
• Use measurement to guide decisions. Track usage, value, sentiment, and friction to understand how AI is performing and where you need to refine the experience.
• Make governance a shared responsibility. Bring together security, IT, business leaders, and product teams to ensure clarity, alignment, and end‑to‑end control.
• Design governance that evolves. Adopt controls that can adapt as Copilot grows, agents mature, and new AI capabilities enter the stack.
• Prioritize clarity for builders and admins. Keep patterns simple, make guidance visible, and ensure that controls are easy to understand so your teams can adopt AI confidently.
• Invest in the AI admin role. Create space for a dedicated AI admin role and skill up AI Admins with deep, cross‑platform expertise, including SharePoint, Power Platform, Azure AI Foundry, Entra identity, and Exchange. Yes, agents will soon have their own mailboxes. In the evolving world of agents, effective administration depends on knowing how agent lifecycle is tied to the platforms where they are created and operate. 

Try it out

• Get started with Microsoft Agent 365 at your company.
• Learn more about Copilot controls.

Related links

• Learn more about our Microsoft Agent 365 product launch. 
• Check out our story announcing our internal rollout of Microsoft Agent 365 here at Microsoft.
• Find out more about how we’re tackling Copilot governance internally at Microsoft.
• Learn more Control controls security and governance.
• Find out how we’re riding the wave of agents washing over Microsoft with good governance.
• Use Agent 365 in the Microsoft 365 admin center.
• Manage Microsoft 365 Copilot scenarios in the Microsoft 365 admin center.
• Explore the tools, practices, and policies regarding Responsible AI at Microsoft.

The post Shaping AI management at Microsoft with Agent 365 and Copilot controls appeared first on Inside Track Blog.

There was excitement, curiosity, skepticism, and no shortage of questions about what this technology meant for the future of IT.

At Microsoft Digital—the company’s IT organization—we didn’t start with a grand transformation plan. Instead, we started with a realization: AI wasn’t just another tool to roll out. It was a fundamental shift in how engineering work could happen.

For years, our IT teams have been focused on scale, reliability, and operational excellence. Those priorities didn’t change. What changed were the possibilities.

Suddenly, engineers could draft code in seconds, summarize complex systems instantly, or automate work that had once consumed hours or days. It was an opportunity to take the skills and capabilities of our people and amplify them with AI.

That realization forced us to step back and ask harder questions.

How do you help thousands of engineers understand what AI can actually do to impact their day-to-day work? How do you move from experimentation to trust? And how do you adopt AI in a way that strengthens engineering fundamentals instead of eroding them?

The answer came in the form of a phased journey grounded in people, culture, and continuous learning.

Phase 1: Awareness and access

It might sound surprising when speaking about engineering processes, but our first challenge wasn’t technology; it was understanding.

When generative AI entered the conversation, most engineers saw the headlines and dabbled in various tools, but few understood fully what it meant for their work. Some were excited, others were wary. Many simply didn’t know where to start. That gap between awareness and practical value was the first barrier we had to address.

We realized early that top-down mandates wouldn’t work. Telling engineers to “use AI” without context or relevance would only deepen skepticism. Instead, we focused on something both simpler and more difficult: Exposure.

We started by making AI visible and accessible in the tools engineers already used. GitHub Copilot. Microsoft 365 Copilot. Early copilots embedded directly into engineering workflows. The goal wasn’t immediate productivity gains. It was familiarity. Letting engineers see, firsthand, what AI could and couldn’t do.

“We encouraged tool usage and adoption so people would at least play around with AI. And once they did, they started seeing the value. That’s when the mindset shifted from ‘AI might replace me’ to ‘AI can be my companion.’”

Mukul Singhal, partner group engineering manager, Microsoft Digital

Just as important, we talked openly about limitations.

AI wasn’t perfect. It hallucinated. It made confident mistakes. And that honesty mattered. By framing AI as an assistant, we reinforced the role of engineering judgment. Engineers didn’t need to fear losing control. They needed to understand how to stay in control.

We also made experimentation safe.

No quotas. No forced adoption metrics. Engineers were encouraged to try AI on low‑risk tasks: summarizing documentation, generating test cases, or exploring unfamiliar codebases. Small wins built confidence, confidence built curiosity, and curiosity drove organic adoption.

As that experimentation took hold, the mindset began to shift.

“We encouraged tool usage and adoption so people would at least play around with AI,” says Mukul Singhal, a partner group engineering manager in Microsoft Digital. “And once they did, they started seeing the value. That’s when the mindset shifted from ‘AI might replace me’ to ‘AI can be my companion.’”

Over time, conversations changed from ‘Should we use AI?’ to ‘Where does AI help most?’

Engineers began sharing prompts, tips, and lessons learned with one another. What started as individual exploration turned into community learning. Awareness gave way to momentum.

Phase one was about providing access to explore, to question, and to learn. And that foundation made everything that followed possible.

Phase 2: Culture shift

Access created awareness and awareness created curiosity.

As more engineers began experimenting with AI, we noticed a pattern. Some teams were moving faster, learning faster, and reducing friction in their day‑to‑day work. Others stalled after initial trials. The difference wasn’t technical skill or capability, it was mindset.

“People started shifting from the mindset of ‘Will AI work?’ to ‘AI is working for me.’ I think that was a very transformational shift, to where I believe a lot of engineers in the organization started believing in AI.”

Veera Mamilla, principal group engineering manager, Microsoft Digital

To move forward, we had to shift how AI was perceived from something optional or experimental to something that was simply part of how modern engineering gets done.

That meant normalizing AI as a trusted partner in the engineering process.

Leaders played a critical role in that shift. Rather than positioning AI as a productivity shortcut, they framed it as a way to strengthen engineering fundamentals: clearer design discussions, better documentation, faster feedback loops, and more time for deep problem‑solving. The message was intentional and consistent. Using AI wasn’t about cutting corners, it was about reimagining how work gets done.

We also had to address a fear that surfaced early: that AI adoption was a signal of replacement rather than empowerment.

“People started shifting from the mindset of ‘Will AI work?’ to ‘AI is working for me,’” says Veera Mamilla, a principal group engineering manager in Microsoft Digital. “I think that was a very transformational shift, to where I believe a lot of engineers in the organization started believing in AI.”

That framing mattered.

As engineers incorporated AI into their workflows, success stopped being measured by output alone. The focus shifted to outcomes. Did AI help you understand a system faster? Did it surface risks earlier? Did it free up time to focus on higher‑value work?

Over time, AI stopped feeling like a novelty. It became part of the engineering fabric. We reinforced it through leadership modeling, peer learning, and shared success stories. Teams no longer asked whether AI belonged in their workflows. They asked how to use it responsibly and effectively.

Phase 3: Upskilling and role evolution

Once AI moved from curiosity to expectation, the challenge of skill building became unavoidable.

From the start, we made a deliberate choice: This would be an upskilling and reskilling journey, not a wholesale replacement of roles. The goal wasn’t a new workforce. It was an investment in the one we had.

That decision shaped everything that followed.

Early upskilling efforts focused on practical entry points. Prompt engineering. Tool literacy. Understanding how copilots and early agents behaved in real engineering workflows. We treated these as something every engineer needed to experiment with, regardless of discipline.

But it quickly became clear that skills alone weren’t the full story. Roles themselves were starting to evolve.

“Your title might still be software engineer or principal engineer. But if you’re acting like an AI engineer, what does that actually mean? That question helped us start defining how these roles were evolving.”

Ragini Singh, partner group engineering manager, Microsoft Digital

Across software development, service engineering, and cloud network engineering, the work was shifting from manual execution toward orchestration and oversight. Engineers were no longer expected to do every task end‑to‑end by hand. Instead, they were learning how to guide AI, review its output, and decide where automation made sense and where it didn’t.

As part of this shift, we began researching how the industry itself was redefining engineering roles. Leaders examined emerging job descriptions from across the market and compared them with Microsoft’s own role frameworks. At the time, there was no formal “AI engineer” role in the internal job library. Rather than creating a new title, the focus stayed on evolving expectations within existing roles.

The idea of an “AI‑native engineer” emerged not as a job description, but as a mindset.

An AI‑native engineer still understands systems, architecture, and risk. What’s different is how that expertise gets applied. Routine tasks are delegated to AI. Judgment, design, and accountability stay with the human. Engineers move from doing all the work themselves to supervising work done in partnership with AI.

“Your title might still be software engineer or principal engineer,” says Ragini Singh, a partner group engineering manager in Microsoft Digital. “But if you’re acting like an AI engineer, what does that actually mean? That question helped us start defining how these roles were evolving.”

This evolution looked different across disciplines. Software engineers focused on AI‑assisted coding, test generation, and spec‑driven development. Service engineers leaned into AI for incident response, knowledge capture, and operational decision support. Cloud network engineers began moving from manual intervention toward intelligent orchestration and agent‑assisted troubleshooting. The common thread wasn’t identical tooling, it was a shared shift toward higher‑order work and reduced toil.

Phase 4: Embedding AI across the engineering lifecycle

By this phase, we knew individual productivity gains were simply the starting point for larger and broader benefits.

Early on, most AI usage showed up in familiar places: Code suggestions, documentation summaries, quick answers. Useful, but fragmented. The bigger opportunity emerged when we stepped back and asked a harder question: What would it look like if AI were embedded across the entire engineering lifecycle, not just used at isolated moments?

We stopped thinking in terms of tools and started thinking in terms of flow. Design. Build. Test. Deploy. Operate. Improve. AI needed to show up across all of it, in ways that reinforced how engineers already worked.

“If AI is only showing up at one step, you don’t get the full value. The real impact comes when it’s integrated across the lifecycle, where engineers can design, build, operate, and learn faster as a system.”

Sudhakar Sadasivuni, principal group engineering manager, Microsoft Digital

In software engineering, that meant pulling AI earlier into the process. We began using it to help draft requirements, reason through design options, and review code with broader system context to accelerate how quickly we could get to informed decisions. Coding assistance mattered, but it was no longer the center of gravity.

Testing and quality followed a similar pattern. AI supported test generation, defect analysis, and code review, reducing repetitive effort and helping issues surface sooner. That gave engineers more time to focus on quality and architecture instead of cleanup.

In service engineering, we embedded AI into incident management and operational workflows. Engineers used it to summarize incidents, surface relevant knowledge, and analyze signals across systems. In cloud network engineering, AI helped shift work away from manual intervention toward orchestration and intelligent troubleshooting. Across disciplines, the principle stayed the same: AI should reduce friction, not introduce it.

As we scaled this approach, one thing became clear. Embedding AI wasn’t just a technical exercise. It was a systems change.

“If AI is only showing up at one step, you don’t get the full value,” says Sudhakar Sadasivuni, a principal group engineering manager in Microsoft Digital. “The real impact comes when it’s integrated across the lifecycle, where engineers can design, build, operate, and learn faster as a system.”

As AI became part of core workflows, engineers remained accountable for outcomes. AI output was reviewed, tested, and validated like any other engineering input. Embedding AI didn’t lower the bar for rigor. It raised expectations around judgment, oversight, and data quality. We became more deliberate about responsibility and governance.

Over time, these integrations created compound benefits.

Faster design cycles reduced downstream rework. Better testing lowered operational noise. Improved operational insight shortened recovery times. AI stopped being something we used occasionally and became something the engineering system itself was built around.

Phase 5: Eliminating toil and accelerating outcomes

At some point, every AI story hits the same test. Does it actually make engineers’ days better? For us, that proof showed up fastest in elimination of toil.

Across Microsoft Digital, engineers have always spent time on work that was necessary but draining. It included tasks such as manual troubleshooting, repetitive diagnostics, log analysis, and routine operational tasks that kept systems running but didn’t move the organization forward.

AI gave us a chance to change that.

“Toil reduction is the biggest thing. That’s where engineers’ eyes light up. If we can eliminate toil, people engineers will flock to use AI. I really believe it.”

Beth Garrison, principal cloud network engineer, Microsoft Digital

In cloud network engineering, for example, troubleshooting used to require manually reconstructing what happened, such as logging into devices, chasing configurations, and piecing together context after the fact. As we began introducing agents and machine learning into these workflows, that work shifted. Instead of spending time assembling the picture, engineers could generate the views they needed faster and focus on resolving issues.

The same shift showed up in how we used operational data.

Rather than reacting to incidents after impact, we started using machine learning to analyze logs, identify patterns, and surface anomalies earlier. That moved teams from reactive response toward proactive monitoring and prevention.

One thing became clear very quickly: Toil reduction wasn’t just a benefit; it was the catalyst for adoption.

“Toil reduction is the biggest thing. That’s where engineers’ eyes light up,” says Beth Garrison, a principal cloud network engineer at Microsoft Digital. “If we can eliminate toil, people engineers will flock to use AI. I really believe it.”

Service engineering followed a similar arc.

Across governance, operations, productivity, and cost management, we began applying agents and automation to simplify complex work and reduce manual review cycles. Governance and compliance workflows became faster and more consistent. Operational processes benefited from guided remediation and earlier insight. Knowledge capture improved as documentation and remediation guidance could be generated and updated automatically.

When we removed repetitive work such as manual triage, rote diagnostics, endless documentation cleanup, we transformed how engineers spent their time. More focus on design. More proactive problem‑solving. More energy directed toward improving systems instead of just maintaining them.

Toil reduction made the value of AI tangible. It’s the moment AI stopped being interesting and became indispensable, and our engineering teams started asking where else we can apply it next.

Measuring what matters

By the time AI was embedded across our engineering lifecycle, a new question came into focus: “How do we know it’s working?”

In the early days, we paid close attention to usage. Which tools engineers were trying, where adoption was growing, or where it stalled. Those signals mattered and adoption was the leading indicator that people were getting comfortable and starting to integrate AI into real work.

“Adoption was always the starting point. But we were clear from the beginning that usage isn’t the destination. The real goal is impact; more time for engineers to focus on the work that truly matters.”

Ullas Kumble, principal group software engineering manager, Microsoft Digital

But using AI doesn’t automatically mean better outcomes. So, we shifted the conversation and started asking, “What’s different now that our engineers are using AI?”

That change reframed how we thought about measurement. We began looking beyond tool activity to understand impact across the engineering system. Faster design cycles. Earlier defect detection. Reduced time spent on repetitive operational work. Shorter incident resolution. Clearer documentation. Fewer handoffs. Less rework.

These weren’t abstract metrics. They showed up in the flow of work.

We were intentional about not forcing a single definition of value across every role. Software engineers, service engineers, and cloud network engineers experience impact differently. What mattered was that each team could point to tangible improvements in how work moved through the system.

That perspective shaped how leadership talked about success.

“Adoption was always the starting point,” says Ullas Kumble, a principal group software engineering manager at Microsoft Digital. “But we were clear from the beginning that usage isn’t the destination. The real goal is impact; more time for engineers to focus on the work that truly matters.”

Over time, this approach changed the quality of our conversations. Instead of debating whether AI was worth the investment, teams talked about where it was removing friction and where it still wasn’t delivering enough value. Measurement became a tool for learning and prioritization.

Moving forward

Looking ahead, one lesson stands out: this journey isn’t complete.

AI tools will continue to evolve. Agents will become more capable. Roles will keep shifting. What it means to be an engineer will continue to change. And that means our approach must stay grounded in the same principles that guided us from the start: invest in people, reinforce fundamentals, embed AI into real workflows, and stay honest about what’s working and what isn’t.

We didn’t set out to build an AI‑driven engineering organization overnight, we built it phase by phase.

By meeting engineers where they were
By reshaping culture before redefining roles.
By embedding AI across the lifecycle, not bolting it on.
By reducing toil and measuring impact where it mattered most.

The result is better engineering: powered by AI, guided by human judgment, and built to keep evolving.

Key takeaways

Here’s a set of approaches you can take to establish AI-led engineering for your organization:

• Start with access and understanding. Give engineers safe, easy access to AI in the tools they already use so curiosity and confidence can develop organically before you push for outcomes.
• Frame AI as a partner, not a replacement. Position AI as an assistant that strengthens engineering judgment and fundamentals rather than a shortcut or a threat to roles.
• Normalize experimentation without pressure. Encourage low‑risk experimentation and peer sharing instead of mandates, allowing adoption to grow through visible, practical wins.
• Invest in upskilling. Focus on evolving skills and expectations within existing roles so engineers learn how to guide, review, and stay accountable for AI‑assisted work.
• Embed AI across the full engineering lifecycle. Look beyond isolated productivity gains and integrate AI into design, build, test, operate, and improve workflows to unlock system‑level impact.
• Measure impact where engineers feel it. Move past usage metrics and track outcomes like reduced toil, faster feedback, and improved flow so teams can see where AI is truly making work better.

Try it out

Try GitHub Copilot.

Related links

• Learn how an AI-led SDLC builds an end-to-end agentic software development lifecycle with Azure and GitHub.
• Discover why developers will lead AI transformation across the enterprise.

The post Powering the new age of AI-led engineering in IT at Microsoft appeared first on Inside Track Blog.

For years, we supported email‑based communities internally here at Microsoft whose very existence depends on anonymity. These include employee resource groups, confidential project teams, and other sensitive audiences where simply revealing who belongs can create real‑world risk.

Traditional distribution groups make membership discoverable by default. Owners can see members. Admins can see members. In some cases, other users can infer membership through directory queries or tooling.

That model doesn’t work when anonymity is a requirement.

“When the SFI wave hit, it was made clear to us that we needed to keep our people safe, and to do that, we needed to build a new hidden memberships group MVP. We needed to raise the bar with modern groups, and we needed to do it in six months or miss meeting our goals.”

Brett Reifers, senior product manager, Microsoft Digital

For over 15 years, we relied on a custom, on‑premises solution that enabled employees to send and receive messages through groups with fully hidden memberships.

The system worked, but we were deprecating the Microsoft Exchange servers that it ran on. At the same time, we were also deploying our Secure Future Initiative (SFI), which required us to reassess legacy systems that could expose sensitive data or slow incident response, including hidden membership groups.

The system wasn’t broken, but it represented concentrated risk simply by existing outside our modern cloud controls and monitoring.

“When the SFI wave hit, it was made clear to us that we needed to keep our people safe, and to do that, we needed to build a new hidden memberships group MVP,” says Brett Reifers, a product manager in Microsoft Digital, the company’s IT organization. “We needed to raise the bar with modern groups, and we needed to do it in six months or miss meeting our goals.”

The mandate was clear. Preserve anonymity, eliminate on‑premises dependencies, and do it quickly.

“Our solution would enable us to deprecate our legacy on-premises Exchange hardware while maintaining the privacy of our employee groups, and it would do so in a cloud-first manner.”

Nate Carson, principal service engineer, Microsoft Digital

Instead of retrofitting hidden membership into standard Microsoft 365 groups, we asked a different question: What if the group lived somewhere else entirely? What if users interacted with a simple, secure front end, while all membership expansion and mail flow occurred in a locked‑down tenant built specifically for this purpose?

That idea became the foundation for Hidden Membership Groups: A new cloud‑first architecture that would separate user experience, leverage first‑party Microsoft services, and keep our group memberships hidden from everyone—including owners and administrators—by design.

“Our solution would enable us to deprecate our legacy on-premises Exchange hardware while maintaining the privacy of our employee groups, and it would do so in a cloud-first manner,” says Nate Carson, a principal service engineer in Microsoft Digital.

Once we settled on a solution, our next step was to get support for solving a problem not many people thought much about.

“Not everyone was aware of how serious of a situation we were in,” Carson says. “We had to show everyone what was at stake, and to share our solution with them.”

After taking their plan on the road, the team got the buy in it needed, and that’s when the real work started.  

Planning to solve business problems with security built-in

Before we designed anything, we had to be clear about what success meant.

Hidden Membership Groups aren’t just another collaboration feature. They support scenarios where anonymity wasn’t optional—it’s foundational. That reality shaped every requirement that we built into our solution, including:

1. Absolute privacy

Group membership couldn’t be immediately visible to users, group owners, or administrators–under any circumstances. That requirement immediately ruled out standard group models.

2. Cloud only

Any new solution had to live entirely in our cloud, use first‑party services, and align with modern identity, security, and compliance practices. On‑premises infrastructure wasn’t an option.

3. Scale

Some groups had a handful of members. Others had tens of thousands. Membership changed frequently, and those changes had to propagate safely and predictably without exposing data or degrading performance.

4. Separation of concerns

User interaction and membership truth couldn’t live in the same place. Employees needed a simple way to discover groups, request access, and manage participation, without ever interacting with the system that stored or expanded membership.

5. Self‑service with guardrails

The solution needed to reduce operational overhead, not introduce a new bottleneck. Group lifecycle management had to be automated, auditable, and secure, while still giving teams flexibility.

6. Simple to use

Employees shouldn’t need special training. They shouldn’t need to understand tenants, identity synchronization, or mail routing. The experience needed to be intuitive, consistent, and accessible—without compromising security.

Once those requirements were clear, our solution started to emerge. Incremental changes wouldn’t be enough. A traditional group model wouldn’t work. The solution required a new architecture—one designed around isolation, automation, and intentional limitation.

That’s when we started the engineering work.

Creating a cloud-first architecture

Designing for hidden membership meant eliminating ambiguity. If any surface could reveal membership, even indirectly, it didn’t belong in the design.

That constraint led us toward a model built on strict isolation, explicit APIs, and intentionally narrow interfaces. The result is straightforward to use, but deliberately difficult to interrogate.

Two tenants, with sharply separated responsibilities

At the foundation of the solution is a two‑tenant model.

Our primary Microsoft 365 tenant is where employees authenticate, discover groups, and initiate actions. A secondary, isolated tenant hosts the distribution lists and performs mail expansion for Hidden Membership Groups.

“Tenant isolation is what makes the privacy guarantee real. By moving membership expansion to a tenant that users and owners can’t access, we removed the possibility of accidental exposure. The system simply doesn’t give you a place where membership can be seen.”

Chad Mace, principal architect, Microsoft Digital

That separation matters because the secondary tenant isn’t designed for interactive use. Only Exchange and the minimum directory constructs required for mail routing and expansion are enabled.

Operationally, when an employee sends email to a Hidden Membership Group, they send to a mail contact visible in the corporate tenant. That contact routes to the corresponding distribution group in the isolated tenant, where membership expansion occurs. Expanded messages are then delivered back in recipients’ inboxes in the corporate tenant, so sent and received mail lives where users already work.

“Tenant isolation is what makes the privacy guarantee real,” says Chad Mace, a principal architect in Microsoft Digital. “By moving membership expansion to a tenant that users and owners can’t access, we removed the possibility of accidental exposure. The system simply doesn’t give you a place where membership can be seen.”

Identity without interactive access

This isolated tenant only works if it can resolve recipients. To enable that, our development team used Microsoft Entra ID multi‑tenant organization identity sync to represent corporate users in the secondary tenant.

These identities are treated as business guest identities, and we disable sign‑in to prevent interactive access. The tenant can perform expansion, but nothing more.

However, complete isolation wasn’t technically possible. Privileged access always exists at some level. The design response was to minimize that exposure. Access to the isolated tenant is tightly restricted, and membership changes flow through automation rather than broad UI-based administration.

The goal: reduce exposure to the smallest viable operational group.

API-first automation as the control plane

With tenancy and identity model established, the team needed a single, consistent way to create groups, connect objects across tenants, and manage changes without introducing new administrative workflows. That’s where the APIs come in.

“We split the backend into multiple APIs so the system could scale without becoming fragile. That let us separate everyday operations from high-volume membership work and keep performance predictable.”

John Pena II, principal software engineer, Microsoft Digital

The backend is intentionally modular, split into three distinct APIs:

• The control API handles group creation, configuration, and cross‑tenant coordination.
• The membership API handles standard add and remove operations.
• The bulk membership APIs handle large‑scale operations involving tens of thousands of users, with services designed to run long‑lived jobs, manage throttling, and recover from partial failures.

“We split the backend into multiple APIs so the system could scale without becoming fragile,” says John Pena II, a principal software engineer in Microsoft Digital. “That let us separate everyday operations from high-volume membership work and keep performance predictable.”

The APIs run as PowerShell-based Azure Functions and use managed identity patterns, including federated identity credentials, to securely connect across tenants.

Creating the user experience with PowerApps

For the front end, we built a Canvas app in Power Apps, backed by Dataverse. The goal was speed and flexibility, without compromising strict privacy boundaries.

By using Power Apps as the primary interaction layer, we deliver a secure, modern experience without unnecessary custom infrastructure. The Canvas app provides a single, focused surface for discovering, joining, and managing hidden membership groups, while all sensitive operations remain behind controlled APIs and tenant boundaries. This separation allows the team to iterate quickly on experience design without weakening the privacy guarantees that the solution depends on.

Power Platform also simplifies how security is being enforced across the solution. Dataverse enables fine‑grained, role‑based access, ensuring users only see data they’re entitled to see—while keeping sensitive membership information entirely out of the client layer. That reduces long‑term maintenance overhead and makes it easier to evolve the solution as requirements change.

“From the beginning, we designed everything with security roles and workflows in mind,” says Shiva Krishna Gollapelly, senior software engineer in Microsoft Digital. “Dataverse let us control who could see or change data without building additional APIs or storage layers, and keeping everything inside the Power Apps ecosystem saved us a lot of maintenance over time.”

Dataverse plays a precise role here: it maintains the datastore the app needs to function without becoming a secondary membership repository.

“Using the Power Platform let us move fast, integrate deeply with Microsoft identity, and enforce security without building a full web stack from scratch.”

Bita Amanishahrak, software engineer II, Microsoft Digital

From a security posture perspective, Dataverse security is used intentionally to restrict what different users can see and do, and the Power App was developed with security roles and workflows in mind.

Short version: the app brokers intent, the APIs execute it, and all the pieces that need to stay separate do exactly that.

“Using the Power Platform let us move fast, integrate deeply with Microsoft identity, and enforce security without building a full web stack from scratch,” says Bita Amanishahrak, a software engineer in Microsoft Digital.

The architectural intent is consistent throughout—isolate the sensitive plane and ensure the user plane operates only through controlled interfaces.

Benefits and impact

The most important outcome of the new architecture is also the simplest: Hidden membership stays hidden.

Anonymity isn’t enforced by policy. It’s enforced by architecture. Membership data never appears in the user experience or administrative tooling, and it doesn’t surface as a side effect of scale.

“We’re no longer asking people to trust that we’ll handle sensitive membership carefully through process,” Reifers says. “The system makes exposure structurally impossible.”

The impact was immediate.

At launch, we migrated more than 2,200 hidden membership groups, representing over 200,000 users, from the legacy on‑premises system into the new cloud‑first architecture. Groups ranged from small, tightly controlled communities to audiences with tens of thousands of members, all supported without special handling.

“Some of these groups are massive,” Pena says. “We knew from the beginning we were dealing with memberships in the tens of thousands, which is why we designed bulk operations as a first‑class capability instead of an afterthought.”

The separation between routine APIs and bulk‑membership APIs proved critical, enabling large migrations and ongoing changes without degrading day-to-day performance.

Operationally, moving to a cloud‑only model reduced both risk and complexity. Decommissioning the on‑premises Exchange infrastructure eliminated specialized maintenance requirements and improved monitoring, auditing, and access controls alignment with our modern cloud standards.

Delivery speed also mattered. Driven by Secure Future Initiative urgency and strong executive sponsorship, the team designed and delivered a minimum viable product in less than six months.

“That timeline forced discipline,” Reifers says. “We focused on what mattered: Security, privacy guarantees, scale, and a UX that wouldn’t disrupt group owners and/or members that had relied on a 15-year old tool.”

Everything else was secondary.

“Most users never think about tenants or APIs. They just see a clean experience that does what they need, without exposing anything it shouldn’t.”

Shiva Krishna Gollapelly, senior software engineer, Microsoft Digital

From an employee perspective, the experience became simpler and safer. Users now interact through a Power Platform app consistent with the rest of Microsoft 365.

Discovering a group, requesting access, or leaving a group no longer requires understanding the architecture behind it.

“Most users never think about tenants or APIs,” Gollapelly says. “They just see a clean experience that does what they need, without exposing anything it shouldn’t.”

The result is sustainable. The platform protects anonymity at scale, simplifies operations, boosts resiliency, and can evolve without reopening core privacy questions.

Moving forward

Delivering the initial solution was only the beginning.

The team sees Hidden Membership Groups as more than a single solution. It’s a reusable pattern for sensitive collaboration in a cloud‑first world: isolate what matters most, automate everything else, and design experiences that don’t require trust to be safe.

As adoption grows, the team plans to support additional anonymity-sensitive scenarios while maintaining the same underlying model.

“We don’t want every sensitive scenario inventing its own workaround,” Mace says. “This gives us a pattern we can reuse confidently.”

Future priorities include improving lifecycle and ownership experiences, strengthening auditing and reporting for approved administrators, and enhancing self‑service workflows—without compromising membership privacy. If it risks exposing membership, it doesn’t ship.

With the legacy system fully retired, Reifers reflects on what the team accomplished to get here.

“We shipped a new enterprise pattern in six months using our first party tools,” Reifers says. “We achieved this because a stellar team cared about the mission. That’s the takeaway.”

Key takeaways

Use these tips to strengthen your privacy, simplify your operations, and future-proof your organization’s collaboration systems:

• Prioritize privacy by design. Embed privacy considerations from the start to protect sensitive information in all collaboration scenarios.
• Architect for scale. Treat bulk operations to support large groups efficiently as a first-class capability.
• Automate and modernize workflows. Replace legacy systems with cloud-native solutions to reduce risk, improve transparency, and enable continuous improvement.
• Streamline user experience. Provide intuitive, consistent interfaces that make it easy for users to access, join, or leave groups without requiring technical knowledge.
• Enforce strict access and auditing controls. Align monitoring and administration with modern cloud standards to maintain security and accountability.
• Create reusable patterns. Establish and share successful privacy patterns to avoid reinventing solutions for each new case.
• Focus on operational simplicity and resilience. Design systems that are easy to maintain and improve, freeing up teams to concentrate on innovation rather than upkeep.

Try it out

Discover how to make the most of Microsoft Power Platform products with online training courses, docs, and videos covering product capabilities and how-to guides.

Related links

• Learn more about Power Apps.
• Explore Exchange Online.
• Review our guidance on designing secure, cloud‑first architectures aligned with Zero Trust principles.
• Learn more about Privacy at Microsoft.

The post Protecting anonymity at scale: How we built cloud-first hidden membership groups at Microsoft appeared first on Inside Track Blog.

For years, we stitched together insights across multiple tools, wrote custom queries, and maintained fragile reports just to answer basic questions. This approach slowed investigations and delayed patch targeting.

We needed a faster, stronger, cloud-native path.

We’re investing in AI-powered predictive maintenance and intelligent troubleshooting to reduce friction in device management.”

Daniel Manalo, principal service engineer, Microsoft Digital

The advent of generative AI changed the way we manage our devices. Not only were we able to ask better questions and get targeted help right from the start, we also got faster and more relevant answers from across our entire device management estate.

It’s simpler. It’s faster. It scales with our environment. And we’re doing it natively in the cloud.

“We’re investing in AI-powered predictive maintenance and intelligent troubleshooting to reduce friction in device management,” says Daniel Manalo, a principal service engineer in Microsoft Digital, the company’s IT organization.

AI and machine learning help us find errors faster and fix them autonomously, in many cases. It reduces our downtime, prolongs lifespans of our devices, and ensures our employees have a consistent and productive experience with their devices.

Today, we’re applying this approach to everyday operations: Speeding investigations, simplifying updates, and tightening the loop from detection to remediation. The overarching goal remains consistent—reduce workloads, improve clarity, and move our discoveries to earlier in the risk window.

The role of Customer Zero in evolving modern device management

We serve as the company’s Customer Zero for our products here in Microsoft Digital. We run early capabilities in our own tenant, pressure‑test them at Microsoft scale, and feed what we learn straight back to engineering. The goal is simple: Turn good ideas into reliable features that any enterprise can use.

“We use our collective learnings from our internal deployments to improve our products, which makes them better for our employees and for our customers.”

 Senthil Selvaraj, principal group product manager, Microsoft Digital

Our Microsoft Digital teams work side-by-side with the Intune product group to modernize our device management approach. The Intune group builds and operates the platform, while we bring real‑world scenarios, signals, and guardrails. Together, we help develop, test, and deploy a better cloud-native product for our customers.

“We use our collective learnings from our internal deployments to improve our products, which makes them better for our employees and for our customers,” says Senthil Selvaraj, a principal group product manager in Microsoft Digital.

For the same reasons, we work hard to make sure that we deploy our tools and services in the same way our customers do.

“That enables everyone at the company to have good visibility into the experiences our customers will have when our products get to them,” Selvaraj says. “This makes us more accountable to our customers and helps us move quickly when improvements are needed.”

Customer Zero for device management spans more than Intune.

We partner across teams responsible for Microsoft Purview, Microsoft 365 Copilot, Microsoft Defender, Windows (Autopatch and Hotpatch), GitHub, and Microsoft Azure to produce comprehensive device management capabilities. These are the surfaces where we test, learn, and refine the end‑to‑end device management experience.

The loop is tight. We identify a need, prototype a solution with the product groups, roll it out to targeted rings, measure impact, and iterate. Those learnings inform what ships in Intune—from data-driven insights to built‑in prompts that surface device health data as a conversation, rather than a simple query.

“Using natural language reduces the time it takes us to figure out what’s going on. We are able to ask Security Copilot questions naturally, which allows us to hear the signals that need our immediate action faster.”

Mohit Malhotra, product manager, Microsoft Digital

The result is a safer, faster path to value with AI-driven device management, including clear ownership, faster remediation, and features that arrive tested against operational reality.

We’ve learned a lot as Customer Zero, and we’re passing those lessons on to you.

Modern device management: Seven tips

Here are seven important tips that we’ve compiled to help with your device management efforts.

Tip 1: Ask natural-language questions with Microsoft Security Copilot

We use the generative AI capabilities in Microsoft Security Copilot to query device and vulnerability data in plain language and get a unified answer that we can act on.

This allowed us to replace bespoke reports with targeted questions.

“Using natural language reduces the time it takes us to figure out what’s going on,” says Mohit Malhotra, a product manager in Microsoft Digital. “We are able to ask Security Copilot questions naturally, which allows us to hear the signals that need our immediate action faster.”

Security Copilot lets us ask about device posture, app versions, cybersecurity vulnerabilities (known as Common Vulnerabilities and Exposures, or CVEs), and exposure across Microsoft Defender and Intune, without stitching the data together by hand. We get the context we need and move faster from finding to fixing.

How we use it

• Scope impact: “List Windows devices running <app/version> that are vulnerable, with owners and deployment rings.”
• Prioritize work: “Group affected devices by business unit and model; show counts and severity.”
• Verify reach: “Confirm which devices received <policy/package> in the last 48 hours; flag failures.”

Prompts we rely on

• “Show devices affected by <CVE/app version> and summarize recommended remediation steps.”
• “Break down exposure by ring and list top 5 models with highest risk.”
• “Identify outliers that failed the last policy sync and provide reasons.”

Why it helps

• Less toil: No custom pipelines to maintain.
• Faster triage: Discovery and scoping happen in one interaction.
• Clear next steps: Results align to our Intune targeting and scheduling paths.

Best practices

• Start specific: Name the product, version, and time window, then broaden as needed.
• Keep follow‑ups short: Quick pivots like “group by region” or “add owner emails” maintain momentum.
• Act on the output: Use the device lists to target updates or policies in Intune, then validate results with a final check.

Note

• We align usage with least‑privilege access and established approval paths so insights come from authoritative sources and actions land through the right channel.

Tip 2: Find knowledge fast with Microsoft 365 Copilot

We use Microsoft 365 Copilot to pull device context from email, chats, and documents, allowing us to troubleshoot issues faster and easier using generative AI.

Incidents start with questions, not dashboards, e.g. “Who owns this package? When did we change that policy? Where did we discuss the driver rollback?”

The answers to those questions live in mail threads, Teams chats, and planning docs. Before Copilot, we were forced to sift through these materials manually, which cost us time. Now we ask one question and get a summary with sources, people, and links. That keeps the investigation moving and reduces handoffs.

“Copilot helps scan noisy logs and points us to likely causes. Our old process of opening logs, interpreting opaque error strings, and validating a hunch took too long. Getting faster answers matters when incidents stack up.”

Michael Griswold, principal service engineering manager, Microsoft Intune

This also helps us during the coordination phase. We can surface the approver for a change, the engineer who ran the last mitigation, and the runbook section that explains the rollback steps. We make better decisions because we see the history and the intent, not just the current state. Then we line up the action in Intune with the right stakeholders already looped in.

How we use it

• Asking for recent context on a device model, configuration, or app to see decisions and outcomes in one place.
• Retrieving owners, approvers, and on‑call contacts named in Outlook and Teams messages related to the issue.
• Pulling change notes and runbook updates tied to a policy or package before we request an update in Intune.

Prompts we rely on

• “Summarize recent emails and Teams messages about <device model/app version> and list owners mentioned.”
• “Find the change note or runbook update for <policy/package> from the last 14 days.”
• “Show known issues linked to <KB/app> and who resolved the last occurrence.”

Why it helps

• Less hunting: We replace ad hoc inbox and wiki searches with a single query.
• Faster coordination: We identify the right stakeholders and prior decisions immediately.
• Better decisions: We confirm history and context before proposing changes in Intune.

Best practices

• Keep prompts scoped. Include product, version, and a timeframe to focus your results.
• Respect boundaries. Align usage with least‑privilege access and existing approval and auditing paths.
• Capture outcomes. Link summaries, owners, and key docs back to the incident record so future searches return richer context.

Note

• Copilot gets better as more decisions and runbooks live in Microsoft 365, since that’s where the signals come from.

Tip 3: Accelerate log triage with GitHub Copilot, Visual Studio Code, and Log Analytics

We use GitHub Copilot in Visual Studio Code with Azure Monitor Log Analytics to explain errors, draft KQL, and shorten device log investigations.

“Copilot helps scan noisy logs and points us to likely causes,” says Michael Griswold, a principal service engineering manager with the Microsoft Intune product group. “Our old process of opening logs, interpreting opaque error strings, and validating a hunch took too long. Getting faster answers matters when incidents stack up.”

Now we keep the entire loop in one workspace. AI in GitHub Copilot interprets the event, proposes likely causes, and generates KQL to confirm or rule out scenarios. We move from symptom to validated pattern without bouncing across tools.

How we use it

• Connect VS Code to your Log Analytics workspace and load the tables you need (e.g., inventory and update events).
• Paste a minimal log sample with timestamps and device identifiers, so Copilot has context.
• Ask Copilot to summarize the error, suggest probable causes, and produce KQL to test each path.
• Run the query, review clusters and outliers, and request an alternate query or grouping if noise is high.

Prompts we rely on

• “Explain this error in a device‑management context and list three validation checks.”
• “Write KQL to find matching failures in the last 24 hours and group by model and policy.”
• “Join device inventory with update events for device and surface anomalies.”

Why it helps

• Faster pattern recognition: Proposed queries get us to evidence quickly.
• Less context switching: Analysis and validation happen inside VS Code.
• Cleaner handoff: Results map to our Intune actions for targeted remediation.

Best practices

• Keep inputs tight: Provide a small, representative log snippet, the affected device attributes, and a precise time window.
• Iterate on queries: Ask for different filters, joins, or time ranges when results are noisy.
• Close the loop: Use the device list to drive policy or update changes in Intune and confirm fixes with a final query.

Note

• This workflow is broadly repeatable with GitHub Copilot, Visual Studio Code, and Azure Monitor Log Analytics.

Tip 4: Keep firmware and drivers current with Intune update management

We use Intune firmware and driver update management to identify, approve, and deploy our OEM updates at scale.

“Staying current on firmware and drivers keeps devices stable and secure. With Intune, we stage updates, watch the rollout, and adjust before issues spread.”

Taqui Mohammad, senior service engineer, Microsoft Digital

Firmware and driver releases don’t land on a predictable schedule. Different vendors ship on different timelines, and a single environment can span hundreds of models.

Tracking this manually slows responses and leaves risk on the table. Intune centralizes the view so we can see what’s applicable, choose the right targets, and roll out updates with the same discipline we use for OS patches.

“Staying current on firmware and drivers keeps devices stable and secure,” says Taqui Mohammad, a senior service engineer in Microsoft Digital. “With Intune, we stage updates, watch the rollout, and adjust before issues spread.”

How we use it

• Review applicability: Open the firmware and driver updates view to see available updates grouped by make and model.
• Select a pilot: Target a small ring first (model, business unit, or region) and set short deadlines.
• Plan time windows and restarts: Align deployments with maintenance windows and communicate expected reboots.
• Monitor, then expand: Track success and failure signals, remediate issues, and scale to broader rings.

Configuration tips

• Standardize categories: Separate firmware from drivers in policies so reporting and rollbacks are clean.
• Use device tags consistently: Model, region, and business unit tags make scoping and expansion straightforward.
• Define rollback steps: Document how to revert a driver or hold firmware for a specific model when needed.

Success checks

• Compliance trend: Increased percentage of devices on the latest approved firmware and driver versions after each wave.
• Incident correlation: Fewer support tickets related to device stability and peripherals on updated models.
• Deployment reliability: Decreased failure rates as pilots catch issues before broad rollout.

Best practices

• Pair with risk signals: Prioritize models tied to active vulnerabilities or incident clusters before broad rollout.
• Keep rings small and fast: Validate quickly, then scale; long pilots hide issues and delay benefits.
• Document exceptions: If a model needs a temporary hold due to app or peripheral compatibility, record the reason and set a review date.
• Verify outcomes: Confirm update levels on target devices and scan for regressions in support queues.

Notes

• Expect uneven arrival patterns across vendors and models; a weekly review cadence helps catch new updates without creating noise.
• Treat firmware and drivers as first‑class updates; include them in regular compliance reports and reviews so they get consistent attention.

“Autopatch Update Readiness catches and resolves common blockers before deployment begins. What used to require manual checks and troubleshooting is now handled upfront, giving us smoother updates and a far more reliable experience for our employees.”

Dave Rodriguez, principal product manager, Microsoft Digital

Tip 5: Speed updates with Windows Autopatch, Hotpatch, and Auto Remediation Update Readiness

We use Windows Autopatch and Hotpatch to reduce disruptions and keep our devices current, and we pair them with automated readiness and remediation so our changes land safely and quickly.

Autopatch handles orchestration for quality updates and feature releases. We define rings that reflect business risk and user impact, then let the service pace deployments as health signals arrive.

“Autopatch Update Readiness catches and resolves common blockers before deployment begins,” says Dave Rodriguez, a principal product manager in Microsoft Digital. “What used to require manual checks and troubleshooting is now handled upfront, giving us smoother updates and a far more reliable experience for our employees.”

Where Hotpatch is available, we apply security updates without a reboot, which cuts downtime and helps us move faster on critical fixes. An automated readiness layer checks prerequisites, fixes common blockers, and confirms that devices are ready before rollout.

How we use it

• Enroll eligible devices in Autopatch and map them to the right scope so ownership, reporting, and break‑glass procedures are clear.
• Build rings that reflect business priority and user profiles (e.g., VIP laptops, frontline kiosks, engineering workstations, and lab devices).
• Enable Hotpatch on supported SKUs and confirm policy alignment so security updates apply without restarts where possible.
• Run readiness checks that verify update agent health, policy state, storage and battery requirements, VPN reachability, and available maintenance windows.
• Auto‑remediate common blockers such as stale update caches, missing prerequisites, paused services, or conflicting policies before a device enters the next ring.
• Start with small cohorts, monitor early signals like install rate and post‑update stability, validate rollback paths, then expand the scope deliberately.

Operational checks

• Ring coverage ensures eligible devices are actually assigned to a ring and not stranded outside the managed flow.
• App and driver smoke tests validate business‑critical apps, kernel drivers, and peripherals on pilot cohorts before broad rollout.
• Safeguard holds and known‑issue tracking are able to watch for vendor or service flags, which can pause or throttle a ring until a fix is available.
• Rollback readiness confirms who owns the decision, what steps they follow, and how telemetry proves the rollback succeeded on affected devices.

Why it helps

• Continuous movement shortens exposure windows because healthy rings advance without waiting for a fixed date.
• Fewer interruptions improve user experience, as Hotpatch removes the need for restarts on supported devices.
• Higher success rates come from automated readiness and remediation, removing predictable failures before deployment.

Best practices

• Use consistent device tags so rings map cleanly to models, regions, and business units, which keeps targeting and reporting trustworthy.
• Keep pilots small and fast to find issues quickly, then scale once success criteria are met and rollback is validated.
• Communicate maintenance expectations in plain language so users know timing, restart behavior, and how to report problems.
• Pace by risk rather than calendar, advancing rings when health metrics and support signal quality are within thresholds.
• Review deployment dashboards daily during rollout, adjust ring size or cadence when error rates rise, and capture lessons learned for the next wave.

Note

• Hotpatch availability depends on your Windows edition and configuration, so confirm support and prerequisites as part of your scoping work.

Tip 6: Keep third‑party apps current with Intune Enterprise App Management

We use Intune Enterprise App Management to keep third‑party apps current without constant packaging work.

“Third-party apps fall out of date fast, so we’re standardizing how they’re updated. We do that with Enterprise App Management, which gives us reliable packages and keeps us moving at a steady cadence.”

Humberto Arias, senior product manager, Microsoft Digital

Third‑party software drives real risk: version drift, silent installers change, and manual packaging pipelines break at the worst time.

With Enterprise App Management, we select from a managed catalog, set assignment and update rules, and let the service handle new versions as they ship. We spend our time on exceptions, not routine updates.

“Third-party apps fall out of date fast, so we’re standardizing how they’re updated,” says Humberto Arias, a senior product manager in Microsoft Digital. “We do that with Enterprise App Management, which gives us reliable packages and keeps us moving at a steady cadence.”

This approach also improves the user experience. Updates arrive in predictable windows and dependencies are handled in a timely manner. We avoid surprise prompts and failed installs that generate tickets. When we do need to pause or pin a version, we scope it cleanly and document the reason.

How we use it

• Build a standard catalog that covers the common apps our users need and assign clear ownership for each title.
• Configure update behavior to auto‑update.
• Use rollout rings so pilots validate the installation success rate and app behavior before expanding to broad audiences.
• Scope assignments with device tags such as model, region, or business unit to simplify targeting and reporting.
• Monitor install and update status, investigate failures, and retry with adjusted timing or requirements when needed.
• Capture exceptions for apps that need holds or custom steps and set review dates to revisit the decision.

Scenarios we run

• Rapid response when a high‑risk CVE drops by prioritizing affected apps and moving them to the front of the update queue.
• Version cleanup by removing outdated or duplicate installers so devices converge on a single approved release.
• Conditional deployment for specialized teams by offering an app as available instead of required while still tracking adoption.

Why it helps

• Less packaging toil because the catalog supplies current installers and metadata.
• Faster patching for common apps because updates flow as they publish.
• Better compliance reporting because versions and assignments are consistent across rings and groups.

Best practices

• Keep an authoritative list of approved apps with owners, support notes, and rollback steps.
• Coordinate maintenance windows for high‑impact apps so users can save work before enforced updates.
• Require pilots for any app with add‑ins or drivers and validate workflows with real users before scaling.
• Use uninstall assignments to remove unapproved or vulnerable software and block reinstallation where needed.
• Document app‑level exceptions, including the rationale and a date to re‑evaluate.

Notes

• Some apps need pre-install checks or post-install steps, so include scripts or detection rules where required.
• Track license terms and usage for commercial titles so updates do not outpace entitlements.

Tip 7: Close the loop with Defender Vulnerability Management and Intune security tasks

We use Microsoft Defender Vulnerability Management with Intune to turn exposure insights into targeted actions that close risk fast.

“The Intune Vulnerability Agent gives us a clear list of issues by device and owner. It shortens our path from finding a problem to fixing it.”

Harshitha Digumarthi, senior product manager, Microsoft Digital

Incidents don’t end when we spot a CVE. They end when devices are fixed and verified.

Vulnerability Management gives us an AI-powered live inventory of devices, software, and configurations, then connects that inventory to known threats. It shows which versions run where, highlights misconfigurations, and explains why a device is at risk. We see the problem and the cause, not just a risk score.

“The Intune Vulnerability Agent gives us a clear list of issues by device and owner,” says Harshitha Digumarthi, a senior product manager at Microsoft Digital. “It shortens our path from finding a problem to fixing it.”

It also ranks what to fix first. Factors like severity level, exploit availability, active attacks, and business context all feed into the priority list, so that commensurate effort goes where it’s needed most. The service recommends specific actions such as updating, uninstalling, reconfiguring, or applying a policy as appropriate.

From there, it pushes the work into our change tools. Tasks flow to Intune, Autopatch, and Enterprise App Management so the remediation is traceable. Exceptions are tracked, including data on owners, compensating controls, and review dates. Closure is verified by watching exposure decrease and confirming the fix landed with the intended devices.

How we use it

• Review exposure by CVE, software, and device group to see where risk concentrates.
• Prioritize based on business impact, internet exposure, and privilege level so high‑value targets move first.
• Select the fix that fits the issue, including app updates through Enterprise App Management, OS and quality updates through Autopatch or Hotpatch (where supported), firmware and drivers through Intune update management, or policy changes for configuration weaknesses.
• Target the right scope using tags for model, region, and business unit so remediation lands where it’s needed.
• Set deadlines and user experience settings that balance urgency with productivity.
• Validate closure by rechecking exposure, confirming install success, and watching support signals for regressions.

What we monitor

• Exposure trends over time, to prove that remediation is reducing risk.
• Top vulnerable apps and models, so effort tracks where it matters most.
• Noncompliant devices and owners, so follow‑ups are direct and accountable.
• Exceptions that need compensating controls, documented rationale, and a review date.

Why it helps

• Fewer handoffs because the same team that sees risk can initiate remediation.
• Measurable outcomes because exposure and deployment data live in connected systems.
• Consistent execution because rings, tags, and approvals follow the same patterns as other updates.

Best practices

• Keep device tags authoritative so targeting and reporting stay reliable.
• Use pilots even for urgent fixes to catch compatibility issues before broad rollout.
• Link vulnerability records to Intune assignments so audit and learning loops are clear.
• Communicate clearly with affected users about timing, restarts, and how to report problems.
• Document exceptions with owners and expiration dates so temporary holds don’t become permanent.

Notes

• Not every fix is an update, and some issues require a configuration change or feature disablement with clear rollback steps.
• Least‑privilege access and standard approvals keep remediation fast without expanding risk.

Key takeaways

Our approach for managing devices and updates has changed. We shifted device and update management from manual hunting and ad hoc remediation to a connected loop that starts with a question and ends with verified resolution—reducing investigation time and speeding recovery.

A few lessons stand out:

• Make natural language work by grounding it in trust. Natural language becomes a force multiplier when insights are drawn from authoritative data and access is tightly scoped.
• Keep pilots small, fast, and intentional. Focused pilots surface issues early without slowing momentum or introducing unnecessary risk.
• Standardize signals to build confidence. Consistent tagging and clear ownership make reports, deployment rings, and rollbacks easier to interpret and trust.
• Control exceptions with discipline. Every exception requires a written rationale and a review date, ensuring temporary holds don’t become permanent policy.
• Close the loop—every time. Verification matters as much as detection. We confirm outcomes and capture learnings to continuously improve the next cycle.

What we’re improving next:

• Strengthen question‑to‑action flows. We’re deepening prompts and playbooks that connect Security Copilot and Intune so operators can move from investigation to scoped change in a single flow.
• Expand Hotpatch adoption and measurement. As support broadens, we’re increasing usage and measuring the impact on downtime, reliability, and user experience.
• Grow app coverage with clearer stability rules. We’re expanding Enterprise App Management while enforcing stronger version‑pinning guidance where predictability is critical.
• Automate deployment decisions. Additional automation around ring placement, readiness checks, and rollback triggers will allow deployments to adapt to live health signals.
• Accelerate investigations with reusable telemetry. We’re developing richer telemetry patterns and reusable KQL in Visual Studio Code to reduce noise and speed repeat investigations.

It’s a continuing evolution of our awareness and capabilities in device management, and we’ll keep improving on it, one loop at a time.

Try it out

Manage and secure your devices with Microsoft Intune.

Related links

• Learn how Microsoft Security Copilot integrates with Microsoft Intune.
• Explore how we’re transforming security and compliance with Windows Hotpatch.
• Read more about Windows Autopatch.
• Discover how Microsoft Defender Vulnerability Management helps remediate device vulnerability.
• Find out how Intune Enterprise App Management enables app discovery and deployment

The post Read our seven tips for shifting to a ‘cloud-native’ device management strategy appeared first on Inside Track Blog.

Answers got sharper. Delivery sped up. New patterns of development emerged across teams working with Copilot agents.

That ease of communication, however, comes with a responsibility: Protect the conversation.

Questions came up like, who’s allowed to speak? What can they say? And what should never leave the room?

Microsoft Digital, the company’s IT organization, and the Chief Information Security Officer (CISO) team, our internal security organization, are leaning on those questions to help us shape our strategy and tooling around MCP internally at Microsoft.

“With MCP, the problem is not the inherent design; it’s that every improper server implementation becomes a potential vulnerability. Even one misconfigured server can give the AI the keys to your data.”

Swetha Kumar, security assurance engineer, Microsoft CISO

Our approach is intentionally straightforward.

Start secure by default. Use trusted servers. Keep a living catalog so we always know which voices are in the room. Shape how agents communicate by requiring consent before making changes.

We minimize what’s shared outside our walls, watch for drift, and act when something looks off. Our goal is practical governance that lets builders move fast while keeping our data safe.

That’s the risk we design for, and it’s why our controls prioritize clear ownership, simple choices, and visible guardrails.

“With MCP, the problem is not the inherent design; it’s that every improper server implementation becomes a potential vulnerability,” says Swetha Kumar, a security assurance engineer in the Microsoft CISO organization. “Even one misconfigured server can give the AI the keys to your data.”

Understanding MCP and the need for security

MCP is a simple standard that lets AI systems “talk” to the right tools and data without custom integration work. Think of it like USB‑C for AI. Instead of building a new connection every time, teams plug into a common pattern. That standardization delivers speed and flexibility—but it also changes the security equation.

Before MCP, every integration was its own isolated conversation.

“Now, one pattern can unlock many systems,” Kumar says. “It’s a win and a risk. When AI can reach more systems with less effort, we must be precise about who’s allowed to speak, what they can say, and how much gets shared.”

We frame this as communications security.

The question isn’t just, “Is this API secure?” It’s “Is this a conversation we trust?” We want to know which servers are in the room, what actions they’re permitted to take, and how we’ll notice if something changes. At the same time, we keep the cognitive load low for builders. They choose from trusted options, see clear prompts before an agent makes edits, and move on. Simple choices lead to safer outcomes.

“MCP enables granular control over the tools and resources exposed to the Large Language Model,” Kumar says. “But that means the developer is responsible for configuring it correctly—which tools an agent can see, what actions a server can take, and what context is shared.”

This approach helps both sides.

Product teams get a consistent way to extend their agents while security teams get consistent places to add guardrails—at discovery, access, and throughout the flow of requests and responses. Everyone operates from the same playbook.

When we treat MCP this way, we protect the conversation without slowing it down. We know who’s speaking. We know what they can do. And we can prove it.

Assessing MCP security across four layers

Every MCP session creates a conversation graph. An agent discovers a server, ingests its tool descriptions, adds credentials and context, and starts sending requests. Each step—metadata, identity, content, and code—introduces potential risk.

We evaluate those risks across four layers so we can catch failures early, contain blast radius, and keep conversations in bounds.

However, the big picture is just as important as the details.

“We take a holistic view of MCP security: start with the ecosystem, then specify controls across the four layers,” Kumar says. “The layers make the work concrete, but the goal stays the same—unified governance, shared education, and faster detect-and-mitigate when a server is at risk.”

Applications and agents layer

This is where user intent meets execution. Agents parse prompts, discover tools, select actions, and request changes. MCP clients live here, deciding which servers to trust and when to ask for user consent.

• What can go wrong
  • Tool poisoning or shadowing. A server advertises safe‑looking actions but performs something else.
  • Silent swaps. A tool’s metadata changes and the client keeps trusting an altered “voice.”
  • No sandbox. The agent can request edits or run code without strong guardrails.
• What we watch for
  • Unexpected tool descriptions or capabilities at connect time.
  • Edit attempts on critical resources without explicit user consent.
  • Abnormal tool‑selection patterns across sessions.

AI platform layer

The AI platform layer includes the AI models and runtimes that interpret prompts and call tools, along with orchestration logic and safety features.

• What can go wrong
  • Model supply‑chain drift. Unvetted models, unsafe updates, or compromised fine‑tunes change behavior.
  • Prompt injection via tool text. Descriptions and responses steer the model toward unsafe actions.
• What we watch for
  • Model provenance and update cadence tied to agent behavior changes.
  • Signals of jailbreaks or instruction overrides in prompts and intermediate messages.
  • Output drift linked to specific tools or servers.

Data layer

This layer covers business data, files, and secrets the conversation can touch.

• What can go wrong
  • Context oversharing. Session data, files, or secrets get packed into the model’s context and leak to a third‑party server.
  • Over‑scoped credentials. Long‑lived tokens, broad scopes, or wrong audience claims enable lateral movement.
• What we watch for
  • Size and sensitivity of context passed to tools.
  • Token hygiene, including short lifetimes, least‑privilege scopes, and correct audience claims.
  • Data egress patterns that don’t match a tool’s declared purpose.

Infrastructure layer

The infrastructure layer includes compute, network, and runtime environments.

• What can go wrong
  • Local servers with too much reach. Excessive access to environment variables, file systems, or system processes.
  • Cloud endpoints without a gateway. No TLS enforcement, rate limiting, or centralized logging.
  • Open egress. Servers call out to the internet where they shouldn’t.
• What we watch for
  • All remote MCP servers registered behind the API gateway.
  • Runtime signals, such as authentication failures, burst traffic, or unusual geographies.
  • Network policies that restrict outbound calls to certain targets.

Across all four layers, the throughline is AI communications security. We decide who can speak and verify what was said—and keep listening for change.

Establishing a secure-by-default strategy

We start by closing the front door. We recommend every remote MCP server sits behind our API gateway, giving us a single place to authenticate, authorize, rate‑limit, and log. There are no direct calls and no blind spots.

“Everything we do starts with securing the MCP server by default and that begins by registering it in API Center for easier discovery. We rely solely on vetted and attested MCP servers, ensuring every call comes from a trusted footprint.”

Prathiba Enjeti, principal PM manager, Microsoft CISO

Next, we decide who gets a voice.

Teams choose from a vetted list of MCP servers. If someone connects to an unapproved endpoint, they receive a friendly nudge and a clear path to register it. No shaming—just fast correction and a better inventory the next time around.

Identity comes next. Servers expect short‑lived, least‑privilege tokens with the right scopes and audience. Admin paths require strong authentication, and where possible, we use proof‑of‑possession to bind tokens to the client and reduce replay risk. Secrets don’t live in code, keys rotate, and audit trails are in place.

“Everything we do starts with making the MCP server secure by default and that begins by registering it in API Center for easier discovery,” says Prathiba Enjeti, a principal product manager in the Microsoft CISO organization. “We only use vetted and attested MCP servers. That’s how we keep the conversation safe without slowing it down.“

On the client side, we slow agents at the right moments. Agents can’t touch high‑risk tools without explicit consent. Tool descriptions are verified on connection and compared to approved contracts. If a tool’s “voice” drifts, we block the call.

We also minimize what’s shared.

Context is trimmed to what the task requires. Sensitive data isn’t included by default, and third‑party servers get only what they need—not the whole transcript. Output filters and prompt shields sit alongside the model to prevent risky inputs from becoming risky actions.

Isolation completes the design. Local servers run in containers with tight file and network permissions. Hosted servers allow only the outbound calls they need, and inbound traffic flows through the gateway, with TLS and logging enforced.

Simple rules with visible guardrails.

“We only use vetted MCP servers,” Enjeti says. “That’s how we keep the conversation safe without slowing it down.”

How we run MCP at scale: architecture, vetting, and inventory

We keep MCP safe by making three things intentionally boring: architecture, vetting, and inventory. One defined path. One vetting flow. One living catalog.

Architecture

We recommend remote MCP servers sit behind an API gateway, giving us a single place to authenticate, authorize, validate, rate‑limit, and log. Transport Layer Security (TLS) is required by default, and for sensitive endpoints, we can require mutual TLS. Outbound egress is pinned to approved destinations using private endpoints and firewall rules, so servers can’t “call anywhere.” Runtime protection continuously watches for credential abuse, injection patterns, burst traffic, and odd geographies.

Identity is established up front. We issue short‑lived, least‑privilege tokens with the correct audience and scopes, and admin paths require strong authentication. Where supported, tokens are bound to the client to reduce replay risk. Services use managed identities or signed credentials; secrets don’t live in code, and keys rotate on schedule.

Model‑side safety travels with every conversation. Content safety and prompt shields help models ignore risky inputs, while orchestration enforces a per‑tool allowlist, so an agent can’t call tools that aren’t in policy—even if the model suggests it. We also track model versions, allowing behavior changes to be correlated with updates.

Clients enforce consent at the edge. “Ask before edits” is enabled by default for write, delete, and configuration changes. When an agent connects, it verifies tool descriptions against the approved contract.

Observability ties it all together. We’re working toward logging tool calls, resource access, and authorization decisions end‑to‑end with correlation IDs. Detections flag abnormal tool selection, unexpected data egress, or edits without consent. Every server has an owner, a contract, and an approval record, and metadata changes automatically trigger re‑review. Kill switches live at both the client and the gateway when we need them.

Vetting

We don’t “connect and hope.”

Before any MCP server can speak in our environment, it earns trust. Owners declare what the server does (tools and actions), what it touches (data categories and exports), how callers authenticate (scopes and audience), and where it runs (runtime and on‑call ownership).

We start with static checks: manifests must match the contract, side‑effecting actions must be consent‑gated, tokens must be short‑lived and properly scoped. A SBOM (Software Bill of Materials) must be present, dependencies must be current, and no credentials can be embedded in code.

Then we test like a client would. We snapshot tool metadata on connect and compare it to the approved contract, probe for prompt‑injection and tool‑poisoning, and verify that “ask before edits” triggers for destructive actions.

We also confirm context minimization, validate that egress is pinned to approved hosts, and test resilience under load, including health checks, retry behavior, and isolation using containers with least‑privilege file and network access. Servers are published only when security, privacy, and responsible AI reviews are complete, runbooks and on‑call are in place, and the registry entry is created and pinned.

Inventory

“Inventory is the foundation—if we miss a server, we miss the conversation. Every server, regardless of where it’s running or how it’s deployed, must be accounted for in our system.”

Priya Janardhanan, principal security assurance engineering manager, Microsoft CISO

You can’t govern what you can’t see, and MCP shows up in more places than a single system of record. To solve that, we’re building the map from signals and stitch them into one catalog.

“Inventory is the foundation—if we miss a server, we miss the conversation,” says Priya Janardhanan, a principal security assurance engineering manager at Microsoft CISO Operations. “Every server, regardless of where it’s running or how it’s deployed, must be accounted for in our system. Without a complete inventory, we lose visibility into critical operations, risk exposing sensitive data, and undermine our ability to ensure compliance and security.”

Our goal state is that Endpoint telemetry catches developer‑run servers on laptops and workstations. Repos and CI pipelines reveal intent before anything ships. IDEs (Integrated Development Environments) surface local extensions and configured endpoints. The gateway and our registries anchor what’s approved for business data, while low‑code environments tell us which connectors are in use and where they point.

We normalize and correlate those signals with stable IDs for servers, tools, and owners. Ownership is proven through repositories, gateway services, and environment administrators—on‑call contacts included. Exposure is scored based on data touches, scopes requested, egress rules, and change history, so high‑risk items rise to the top of the queue.

Freshness is tracked with last‑seen timestamps, and stale entries are retired over time. Builders can discover and reuse approved servers; reviewers can see what changed since the last approval, and admins get instant visibility into coverage and hotspots.

We’re working toward automated identification and notification for unknow servers. In the ideal state, a registration stub is created when we detect an unknown server on an endpoint. Then, the likely owner is notified, and direct calls are blocked until the server is vetted through an automated process. If tool metadata changes after approval, high-risk actions are paused and routed for re-review, then auto-resumed once approved.

“It all revolves around inventory as the foundation,” Janardhanan says. “If we miss a server, we miss the conversation.”

“Agent 365 tooling servers will allow centralized governance for IT admins. That means a single pane where they can see what’s approved, who owns it, what data it touches, and then apply policy.”

Aisha Hasan, principal product manager, Microsoft Digital

Architecture gives us stable choke points. Vetting keeps weak servers out. Inventory keeps our map current. It’s a single pattern for builders and a unified playbook for security.

Governing agents in low‑code and pro-code scenarios

Makers move fast—that’s the point. A Customer Support team needed a Copilot action to pull case history, so they opened Copilot Studio, selected an approved MCP connector, and shipped a first version before lunch. No tickets. No detours. Governance showed up in the flow, not as a blocker.

“Agent 365 tooling servers will allow centralized governance for IT admins,” says Aisha Hasan, a principal product manager at Microsoft Digital. “That means a single pane where they can see what’s approved, who owns it, what data it touches, and then apply policy. We’re moving toward that consolidation so innovation continues while governance gets simpler and more consistent.”

We place guardrails where makers already work. In Copilot Studio, trusted and verified first-party MCP servers are allowed in developer environments to accelerate innovation and encourage experimentation. Riskier or complex MCP integration is available in Copilot Studio custom environments and other pro-code tools such as Microsoft 365 Agent Tool kit in VS Code and Microsoft Foundry, but only with clear checks: service ownership, security and privacy review, responsible AI assessment, and consent gating for high‑impact actions.

The allowlist is our north star.

Approved MCP servers and connectors live in one catalog with documented owners, scopes, and data boundaries. Makers choose from that shelf. If an MCP server uses an unverified tool, we enforce endpoint filtering. If there is misconfiguration, we open a task for the owner and help them build securely.

Permissions stay tight without adding cognitive load. Tokens are short‑lived and scoped to the task. Context is trimmed so only the necessary fields flow to the tool. Third‑party servers never get the full transcript. If a connector’s capabilities change, the runtime compares the new “voice” to what we approved. MCP Clients should pause risky actions, notify the owner, and resume automatically once reviewed.

With agent inventory in Power Platform Admin Center and registry in Agent 365, admins get a clean view on which connectors are active, who owns them, what data they touch, and how often they’re called. Organization policies such as DLP and MIP can be enforced in a unified way , with a re‑review when capabilities change. The goal is simple: let builders innovate confidently and securely while maintaining security and compliance.

“MCP servers are powerful AI tools that enable agents to seamlessly integrate and interact with enterprise data and transform business workflows,” Hasan says. “That means the same enterprise data and governance principles are applied equally to MCP servers and other connectors. A robust inventory, an agile policy framework, and an automated workflow for enforcement are cornerstones for successfully governing agents at scale.”

Securing MCP at scale: Operating, monitoring, and enabling

Our work doesn’t stop at go‑live. Once an MCP server is in the catalog, we operate the conversation like a service: measurable, observable, and responsive. Identity and policy guard the front door, but runtime is where we prove the controls work without slowing anyone down.

In practice, operating MCP at scale comes down to four motions:

Observe every tool call end to end. We make the flow observable. Every tool call carries a correlation ID from client to gateway to server and back. Prompts, tool selections, authorization decisions, and resource access should belogged with consistent schemas. Golden signals—latency, errors, saturation—sit alongside safety signals like unexpected egress or edits without consent. Owners and security teams see the same dashboards.

Detect drift and abnormal behavior early. Detection lives close to the work. We flag abnormal tool patterns, spikes in write operations, burst traffic from new geographies, and context sizes that don’t fit a task. We continuously compare a tool’s “voice” at connect time to the approved version; drift automatically pauses risky actions and pings the owner. Cost controls double as guardrails, using rate limits and budgets to cap blast radius and surface runaway loops early.

Respond with precision instead of blunt shutdowns. Response is graded, not binary. We can block destructive actions and allow reads, or throttle a noisy client without killing the session. Kill switches exist at both the client and the gateway. Playbooks are pre‑approved and integrated into the consoles owners already use, and dry runs are part of muscle memory, so the first switch flip doesn’t happen during an incident.

We treat model behavior as part of operations. Content safety and prompt shields run in production, not just in tests. We pin model versions and watch for output drift after updates. If a model starts suggesting tools out of character, the owner gets paged with the exact prompts and calls that triggered it.

Telemetry respects privacy. Logs avoid sensitive payloads by default and mask what must pass through for forensics. Access is role‑based, retention follows policy, and audit readiness is designed in on day one.

Enable builders through templates, education, and reuse. Adoption and education run in parallel. Builders get templates that enable best practices: sample manifests with consent gates, CI checks for token scope and SBOMs, and gateway stubs with sane defaults. A “ten‑minute preflight” runs locally to verify contracts, test consent flows, and check egress before a pull request is opened. IDE lint rules catch common issues early.

“This is how we operate MCP at scale,” says Janardhanan. “Observe the conversation, detect drift early, respond with precision, and teach habits that make the right path the easy path. We run it like a product because that’s what it is.”

Measuring results and moving forward

This program has changed how we build. Reviews move faster because every server follows the same path. Drift is caught early because clients compare a tool’s “voice” on connection. Shadow servers decline as inventory fills in from endpoint, repo, IDE, and gateway signals. Reuse increases because teams can discover trusted servers instead of creating new ones. Incidents resolve faster with correlation IDs across the conversation and kill switches at both the client and the gateway.

It’s also changed how our admins work. One gateway means one perimeter to manage. Policies land once and apply everywhere. Owners see the same telemetry security sees, so fixes happen where the work happens.

Going forward, we’re focused on more consolidation and automation. We’re moving toward a single pane for MCP governance—approve, monitor, and pause from one place. Policy-as-code will keep allowlists, consent rules, and egress boundaries versioned and testable in CI.

Our preflight checks will get smarter, with stronger injection tests, automatic egress validation, and environment‑aware templates. We’ll expand consent patterns so high‑impact actions remain explicit and auditable, even across multi‑tool chains. And we’ll keep shrinking re‑review time, so drift is measured in minutes, not days.

AI conversations are now part of how we build every day. MCP standardizes how agents talk to tools and data. Secure‑by‑default architecture, rigorous vetting, and a living inventory, ensure the right voices stay in the room, only what’s needed is shared, and drift is caught early.

The result is simple: teams ship faster with fewer surprises, and governance stays visible without getting in the way. We’ll keep tightening the loop, so saying yes remains both easy and safe.

Key takeaways

If you’re implementing MCP security, consider these key actions to ensure secure, efficient adoption in your organization:

• Build governance into the maker flow. Embed security, consent, and responsible AI checks directly where teams build—so protection shows up by default, not as an afterthought.
• Maintain a single allowlist and catalog. Centralize approved MCP servers and connectors with clear ownership, scope, and data boundaries.
• Enforce scoped, short-lived permissions by default. Automatically limit token scope and duration to minimize risk and exposure.
• Monitor continuously and detect drift early. Observe activity, flag deviations, and pause risky actions until reviewed and approved by owners.
• Automate incident response and controls. Leverage pre-approved playbooks, kill switches, and rate limits for fast, precise action.
• Design for privacy and auditability from day one. Mask sensitive data, restrict log access by role, and endure audit readiness.
• Promote education and reuse. Provide templates, training, and feedback loops to encourage safe development and adoption of trusted servers.

Try it out

Get started with MCP Server.

Related links

• Learn more about MCP Server.
• Explore Microsoft API Management documentation to secure and govern MCP servers behind a single gateway.
• Get started with Copilot Studio Kit Compliance Hub.
• Get started with Microsoft Copilot Studio security and compliance for custom connectors and actions.
• Understand Microsoft’s Zero Trust guidance app‑to‑app communication.

The post Protecting AI conversations at Microsoft with Model Context Protocol security and governance appeared first on Inside Track Blog.

Microsoft Viva is a digital employee-experience platform that brings together essential capabilities such as knowledge, learning, and workplace insights in the flow of work to empower people and teams to be their best.

Powered by Microsoft 365 Copilot and AI, Viva enables our employees—and anyone who uses it—to hone their skills and acquire new ones. It gives our managers data-driven insights that help them make better decisions. And with new Copilot Analytics integration, Viva is enabling leaders to measure and optimize the impact of AI across the organization. Ultimately, Viva helps us—and organizations like yours—build inclusive, thriving cultures where people can achieve their full potential.

Our team, Microsoft Digital, in partnership with Microsoft Human Resources (HR) and our leadership, deployed Viva across Microsoft to accelerate our evolving growth-mindset culture and help ensure that our employees thrive.

Supporting employee engagement

Our mission in Microsoft Digital is to power, protect, and transform Microsoft. Part of that responsibility is ensuring that Microsoft employees can thrive in a flexible hybrid work environment. In partnership with HR, our internal business partner and customer, our team obsesses over every dimension of an employee’s experience, from early on when they are a candidate for employment to when they become an alumnus of the company. We steward employees’ digital experience across all aspects of their work, ensuring that they have the devices, applications, services, and infrastructure they need to be productive on the job, regardless of what they do or where they do it.

Continuing to improve the experience our employees have with Viva requires a steady company-wide effort to build awareness of improvements being made on the platform, including the integration of Copilot and AI, and to drive usage. It’s an effort that’s both technical and cultural, driven by Microsoft HR in partnership with our team and the Viva product group.

Evolving our culture

Microsoft HR is an important driver of organizational culture at Microsoft, helping our employees thrive in a growth mindset culture with a focus on being customer-centered, diverse and inclusive, and unified as One Microsoft. Microsoft leadership and the HR team sponsor and advocate for Viva as our internal experience platform.

The HR team’s collective expertise, developed in HR centers of excellence, has been a key influence on Viva’s development and implementation. HR centers of excellence are groups of experts and leaders in areas such as culture, talent management, people analytics, learning, and other people practices. They help drive company-wide HR programs and processes using evidence-based research and external benchmarks. HR teams serve as experts in the employee life cycle, providing insights into core HR functions such as onboarding, wellbeing, recruiting, and career growth.

From the start, our teammates in HR have been Viva advocates, always on the lookout for opportunities to streamline work using Viva for existing HR programs and processes and recommending new HR employee-experience scenarios that shape the future of Viva product design. As our team in Microsoft Digital and HR deployed and drove adoption of Viva internally, we found new inspiration for product features and improvements.

Adopting Viva as Customer Zero

At Microsoft Digital, we are early adopters of our own technology. We believe in our products, and we obsess over making them better for our customers. This all happens within a culture and practice we think of as being Customer Zero for the company.

Customer Zero is our internal journey to make our products better using our own business experience. Across our company, we respect employee privacy, data-access regulations, and the laws of the countries and regions where we operate while using powerful tools to understand how work gets done. By acting as Customer Zero for Viva, our team in Microsoft Digital provides valuable feedback that enables the product team to develop features and experiences that further benefit our employees and our customers.

Throughout the Viva adoption process, our Customer Zero relationship has included the Viva product team—as they have developed new modules and features, we in Microsoft Digital and Microsoft HR have been their first customers.

Our Customer Zero approach requires involvement from all three contributors—Microsoft Digital, HR, and our product groups. This involvement creates dependency among the three contributors for successful deployment, adoption, and testing. It also creates a cycle of benefits that positively affects all three contributors and, ultimately, Microsoft’s customers:

• Microsoft Digital. As the team responsible for implementing and supporting Viva within Microsoft, our team has direct access to the product group. This provides us with:
  • Access to preview features and capabilities on a controlled rollout schedule.
  • Direct support from the Viva product team for software updates and testing.
  • Support from Microsoft HR for driving cultural change and adoption and encouraging feedback from Microsoft employees.
• Microsoft HR. Microsoft HR and Microsoft Digital technology teams have been partnering to drive Viva adoption to accelerate culture and business outcomes. This gives us:
  • The ability to guide feature development in Viva for specific use cases and scenarios within Microsoft.
  • The ability to contribute thought leadership in Viva’s product roadmap and overall design.
  • Assurance that the Viva product team is building a platform designed to meet business needs and evolve culture.
• Microsoft product groups. Our product groups have in-place test and feedback environments that consider both technical and cultural perspectives. Practically, they get:
  • Enterprise testing conducted by our team in Microsoft Digital in real-life scenarios within the global Microsoft context. Input from Microsoft subject matter experts in crucial Viva subject areas such as employee experience, HR processes, learning, and knowledge management.
  • Access to existing tools and capabilities across Microsoft Digital and Microsoft HR tools that are already in place. We’ve developed a wide variety of apps and tools used for HR processes. The code and capabilities in these tools can be used in Viva modules and components.
  • A controlled feedback loop: As Customer Zero, Microsoft Digital and Microsoft HR directly communicate with the product group.

Customer Zero is our way of improving our products and services before we release them to our customers, and it reflects our commitment to making Viva—and all our enterprise apps and services—the best they can be, based on our own internal usage at Microsoft.

Enriching our employee experience

We’ve had great success driving usage and adoption of Viva across Microsoft through structured, globally relevant change-management activities. Enabling employees to thrive and be their best from anywhere by bringing knowledge, learning, resources, and insights together into the flow of work is always the central focus of our larger Viva adoption. At the same time, much of the practical implementation happened at the individual Viva module level, where each module supports culture evolution and employee experience at Microsoft.

Viva Engage

We use Viva Engage to build community with purpose across Microsoft—bringing our employees together across our organization to connect with our leaders, their coworkers, and our communities. It provides an experience that enables our employees to crowdsource answers and ideas, share their work and experience, and find belonging and connections at work. Engage also supports peer-to-peer knowledge sharing with dedicated Microsoft 365 AI adoption communities where employees can ask questions, get support from peers and administrators, and learn best practices for using Copilot effectively.

Viva Engage home feed

Engage has become the primary platform we use for enterprise social communication at Microsoft, supporting large-scale campaigns such as Copilot boot camps that help employees build shared understanding of AI and develop confidence using it. These campaigns activate communities and strengthen leader visibility, helping leaders to engage employees at-scale. We also use the integration of Copilot with Engage to refine our posts and to suggest where employees can post their updates to maximize their effectiveness and reach their intended audience.

Viva Amplify

Viva Amplify empowers organizations’ communication teams and leaders to elevate their message and energize their people. The app centralizes communication processes in a single space and offers writing guidance to help messages from leaders, corporate communications, and HR to resonate with employees. Communicators can orchestrate messages across multiple channels, manage their campaigns from a single coordinated workspace, and use engagement insights to refine and improve future communications.

At Microsoft, we use Amplify to organize and streamline our internal communications workflows, centralizing campaign management while simplifying publishing and reporting. Amplify helps us ensure that messages land consistently across audiences by using AI to optimize messaging and measure engagement. Business leaders at Microsoft use Amplify and Engage to run large, structured campaigns—such as Copilot adoption efforts—that reach employees across regions and roles, meeting people where they are and helping build shared understanding at scale.

Viva Amplify overview

Viva Insights

Viva Insights is designed to guide organizations toward better work habits and norms to improve wellbeing and productivity. Viva Insights respects employee privacy while leveraging Microsoft 365 data to measure the day-to-day actions that contribute to our culture and success, like how employees use their time, their collaboration habits, and how they operate across team, business, and geographic boundaries. Viva Insights has also become a valuable tool for helping managers understand how employees are adopting AI.

Viva Insights dashboard

At Microsoft, we use Insights to promote a more productive workplace culture across all levels of the company using capabilities like Copilot Analytics, teamwork habits, and operational insights:

• Copilot analytics: Copilot Analytics integration with Insights enables managers to observe how employees are engaging with AI technology and agents and offer actionable insights into adoption patterns and usage trends. This data helps leaders identify opportunities for further AI-driven innovation and support within their teams.
• Teamwork habits: Insights promotes productive teamwork habits by using team-level insights to help managers maintain regular 1:1 personal interaction and keep up with outstanding tasks to unblock the team and recognize strengths and accomplishments.
• Operational transformation: Insights helps managers and business leaders focus on streamlining operations and improving productivity, including such areas as meeting effectiveness and AI-driven improvements in process efficiency. Insights has helped us to measure the shift in meeting culture at Microsoft: thanks to AI-powered recaps and summaries, employees who aren’t central to a meeting can now catch up asynchronously, saving time and improving productivity.

By aggregating and evaluating this kind of data at the highest levels of the company, we’re able to use organizational trends to make changes that help us improve our employees’ experience while respecting individuals’ privacy.

Viva Glint and Viva Pulse

Glint and Pulse are voice-of-employee solutions that we use to transform feedback into action, at scale. The all backed by deep people-science rigor, Copilot-assisted insights, and native integrations across Microsoft 365.

We’re using these tools for multiple purposes while we navigate our AI transformation:

• Benchmarked org-wide sentiment: Glint enables our functional leadership teams to assess org-wide employee sentiment and drive targeted action—including via Employee Signals, our twice-yearly HR-led employee sentiment survey, our annual global Communications community survey. This enables our leaders to compare how AI is affecting workflows across different teams, functions, and parts of Microsoft, rather than looking at one org in isolation.
• Democratized local insights: Pulse enables our business leaders to send brief surveys in a local capacity, outside of the standardized org-wide programs. Our leaders use our Copilot templates to understand how their teams are getting the most value from AI—and where they still need help learning!
• Strategic initiative tracking: For key transformations like Copilot adoption, Glint and Pulse integrate seamlessly into our broader, companywide change management efforts with native experiences easily available in Copilot Dashboard to gather feedback from employees on additional change management support needs, highlight breakthrough success stories, and understand how Copilot adoption is driving changes in employee experience

Surveying our employees

Together, these tools help enable leaders throughout our organization keep up to date with how our employees are feeling as they navigate culture and technology transformations. This ensures our leaders get the critical, timely feedback needed to accelerate and achieve success in bringing their employees along in times of change.

Like Insights, Glint and Pulse include built-in privacy safeguards such as aggregation and differential privacy, so our HR teams can honor compliance obligations while gaining a better sense of the current status and needs of their organization and then share anonymized reports with business leaders.

Viva Learning

We’re using Viva Learning for high-value learning experiences, a part of which is creating a single front door for the wide variety of learning experiences available to Microsoft employees. Viva Learning is a centralized learning hub in Microsoft Teams that lets our employees seamlessly integrate learning and skill building into their day. With Learning, our teams can discover, share, recommend, and learn from content libraries provided by the organization and content recommended by peers. And they can do all of this without leaving Microsoft Teams.

Viva Learning modules

At Microsoft, we use Viva Learning to:

Accelerate Copilot adoption with upskilling: Microsoft Copilot Academy provides our employees with structured, role-based learning paths and hands-on exercises that help them build their Copilot skills and confidently apply Microsoft 365 Copilot in their daily work.

Deliver organization-driven learning experiences: Viva Learning enables assigned compliance training and supports custom academies created by the organization, helping our employees improve their skills in their domains while aligning learning with business priorities.

Encourage peer-to-peer learning: Our employees can curate and share learning collections with peers, fostering collaboration and sharing knowledge across teams.

We also have launched a Learning Agent, which is currently in public preview for some customers. It delivers AI-powered, personalized learning experiences to our employees that complement what their Viva Learning experience. It helps our employees discover tailored content and accelerate skill development.

Bigger picture, Viva Learning reduces learning-resource isolation, and it provides our employees with a single portal to discover opportunities to build their skills and manage required training. Consolidating these experiences into a single environment, where learning can be discovered and shared within the flow of work, is a significant value of Viva Learning for us here at Microsoft.

AI-based content recommendations and peer-recommended learning enable our culture of learning, encouraging our employees to be full-time, lifelong learners in whatever areas they choose to pursue. Together, these capabilities support continuous learning at scale, empowering employees to upskill themselves, adapt, and contribute to business outcomes.

What’s next

At Microsoft, we’ve achieved over 97 percent employee usage across Viva as a suite, and adoption continues to grow. As we continue to drive additional usage, we’re providing our product teams with insights that help improve the experience for our customers. Based on our own usage and feedback from our customers and partners, we continue to help the product team build out new capabilities that deliver additional value and help ensure that Viva is the centralized, digital platform for staying productive, connected, and supported in the hybrid workplace.

Our employee-experience evolution with Viva has been underway now for over five years, but we aren’t finished. We’re continuing to refine the capabilities, and we’re committed to improving Viva for our customers and for our employees, and we look forward to sharing our future innovations with you as Customer Zero.

Key takeaways

As you evaluate the employee experience and learning management features of Viva and its newest AI-powered capabilities, here are some practical steps you can take to ensure you get all the benefits it has to offer:

• Use AI-powered analytics to optimize employee engagement: Surface actionable recommendations, automate routine tasks, and deliver tailored learning and wellbeing experiences that meet employees where they are.
• Centralize communications and feedback with modern platforms: Adopt solutions such as Viva Amplify to streamline campaign management, gather real-time feedback, and ensure consistent, impactful messaging across your organization.
• Align organizational goals and employee development with strategic business outcomes: Use AI-enhanced tools like Viva Learning to connect daily work to broader objectives and support continuous upskilling.
• Foster a culture of collaboration, inclusion, and knowledge sharing: Empower employees to connect, share expertise, and build community through platforms like Viva Engage, using its AI features to break down silos and amplify voices across the organization.
• Adopt a “Customer Zero” mindset to drive continuous improvement: Pilot new technologies internally, gather feedback, and iterate quickly, using your own organization as a testbed to ensure solutions are effective before broader rollout.
• Measure impact and adapt using data-driven insights: Track adoption, engagement, and business outcomes with AI-powered analytics, and use these insights to refine strategies and maximize the return on your digital transformation investments.

Try it out

Try out Microsoft Viva today to see how you can drive cultural change and AI adoption in your organization.

Related links

• Learn how Microsoft Viva became a business transformation engine at Microsoft.
• Read about how we’re supercharging our internal communications with Viva Engage.
• Step through our guide—based on our internal experience here at Microsoft—for transforming your business with Microsoft Viva.
• Find out how we’re deploying Microsoft 365 Copilot in Viva Engage at Microsoft.

The post Accelerating our cultural transformation at Microsoft with Viva and AI appeared first on Inside Track Blog.