As AI capabilities advanced, we saw an opportunity to move beyond individual productivity gains and toward something more transformative: Empowering our developers to build intelligent agents that can automate workflows, streamline operations, and create new business value.

Realizing this vision required more than new tools. We needed to rethink how we foster development, govern innovation, and operate at scale.

“We’ve made a lot of progress enabling our developers to build agents that make us more productive. We’re Customer Zero at Microsoft, which means we’re the first to deploy and use the technology and services that we later sell to our customers. Those learnings give us a unique perspective and story to share about the journey our developers have been on with AI and agents.”

Brian Fielder, vice president, Microsoft Digital

Today, we’re sharing the foundation we built that supports this shift.

We’re driving employees across Microsoft to create and use AI agents—from simple, task-focused solutions to enterprise-grade applications available across the company. It’s all supported by a secure, governed, and extensible platform.

“We’ve made a lot of progress enabling our developers to build agents that make us more productive,” says Brian Fielder, vice president of Microsoft Digital, the company’s IT organization. “We’re Customer Zero at Microsoft, which means we’re the first to deploy and use the technology and services that we later sell to our customers. Those learnings give us a unique perspective and story to share about the journey our developers have been on with AI and agents.”

Within the context of Microsoft Build 2026, we’re sharing what it really takes to move from experimentation to impact. Through this collection of stories and resources, we highlight how we’re empowering our developers to build with agentic AI—from establishing governance and platform capabilities to driving adoption and delivering real-world outcomes. Our goal is to provide practical insights you can use to accelerate your own AI journey.

“We hope you find the journey we’ve been on practical and useful,” Fielder says. “When it comes to agents, we’re accelerating fast and scaling at an enterprise level. As our story continues to evolve, we look forward to sharing it with you.”

Guidance for developers: How we manage agentic AI at Microsoft

These articles outline our vision for agentic AI, showing how we’re building a secure, governed, and extensible foundation for AI agents—from Work IQ and Copilot Studio to Agent 365, Azure DevOps, and Model Context Protocol—so developers can create scalable, high-value solutions across the enterprise.

April 16, 2026

Alex Fleck

Becoming a Frontier Firm: A guide for deploying AI agents based on our experience at Microsoft

May 21, 2026

Alex Fleck

Governing AI agents at scale: Lessons from our journey at Microsoft

• How Work IQ is supercharging our AI usage at Microsoft
• Shaping AI management at Microsoft with Agent 365 and Copilot controls
• Deploying Microsoft Agent 365: How we’re extending our infrastructure to manage agents at Microsoft
• Unlocking enterprise AI extensibility at Microsoft with Microsoft Copilot Studio
• Powering AI value with Microsoft 365 Copilot extensibility at Microsoft
• How our employees are extending enterprise AI with custom retrieval agents
• Transforming our approach to sensitivity labels at Microsoft with Microsoft Entra
• Reclaiming engineering time with AI in Azure DevOps at Microsoft
• Protecting AI conversations at Microsoft with Model Context Protocol security and governance

UPCOMING POSTS

• Intelligence on tap: Our guide for How Work IQ enables Microsoft 365 Copilot to better understand how we work at Microsoft
• Our guide for deploying Agent 365 based on our experience at Microsoft
• Agentic modernization: Securing Python at scale for agentic AI at Microsoft

Our IT guide to becoming a Frontier Firm

These stories share our IT playbook for becoming a Frontier Firm, highlighting a practical path to enterprise AI maturity through agentic transformation, operational scale, responsible innovation, and partnership—showing how IT leaders can balance governance, modernization, and employee engagement while building an AI-first organization.

December 4, 2025

Keith Boyd

Becoming a Frontier Firm: Our IT playbook for the AI era

• Enterprise AI maturity in five steps: Our guide for IT leaders
• The agentic future: How we’re becoming an AI-first Frontier Firm at Microsoft
• AI at scale: How we’re transforming our enterprise IT operations at Microsoft
• Transforming into an AI-first Frontier Firm in partnership with our works councils
• Fast Train to the AI Frontier: Balancing risk and innovation in the era of AI at Microsoft

Working as developer in IT at Microsoft in the era of AI

These stories explore what it means to work in Microsoft Digital during the AI era, showing how developers and knowledge workers are reshaping engineering, the employee experience, and their own career growth through AI-powered tools, new ways of working, and personal journeys that reflect the evolving culture of IT at Microsoft.

May 21, 2026

Matthew Cooke

IT on the cutting edge: Working in Microsoft Digital in the era of AI

• Powering the new age of AI-led engineering in IT at Microsoft – Inside Track Blog
• The Frontier Firm: How knowledge workers are forging their own AI tools at Microsoft – Inside Track Blog
• The future of work is here: Transforming our employee experience with AI – Inside Track Blog
• Olutunde Makinde: From Lagos to Redmond, a Microsoft IT engineer’s journey – Inside Track Blog
• Building from the inside: Anahit Hovhannisyan’s impact on IT at Microsoft – Inside Track Blog

Key takeaways

From our journey enabling agentic AI across Microsoft Digital, several key principles have emerged to help organizations move from experimentation to scalable, enterprise-wide impact.

• Treat your organization as Customer Zero. Use your own AI capabilities first to generate real-world insights, validate scenarios, and build credibility before scaling to customers.
• Build a foundation for scale. Establish a secure, governed, and extensible platform that enables developers to create AI agents—from simple solutions to enterprise-grade applications.
• Empower developers to drive transformation. Move beyond productivity gains by enabling developers to build intelligent agents that automate workflows and unlock new business value.
• Align governance with innovation. Rethink how you enable development, govern AI, and operate at scale to balance flexibility with responsible use.
• Connect tools, platforms, and workflows. Integrate AI capabilities across your ecosystem—linking platforms, governance models, and development tools to support consistent, scalable adoption.
• Translate experimentation into impact. Focus on turning early AI exploration into coordinated, enterprise-wide efforts that deliver measurable outcomes.

Try it out

Learn more about Microsoft Build.

Related links

• Read our guide for deploying AI agents based on our experience at Microsoft.
• Learn about how we’re governing AI agents at scale internally.
• Find out how Work IQ is supercharging our AI usage at Microsoft.
• Check out an IT playbook for the AI era and see how we’re becoming a Frontier Firm.

The post Microsoft Build 2026: Empowering our developers to adopt agentic AI 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.

These innovations have come in many different forms across every group and function at the company. It’s impossible to capture them all in a single concept or story, but one of the ways that we’ve activated the power of AI for our workforce is Work IQ.

Work IQ isn’t a product.

It’s a shared intelligence layer that enables Microsoft 365 Copilot and AI agents to reason over and understand your organization’s work data, then use that context to generate more relevant responses and actions. This means that the entire Microsoft Graph—including rich unstructured data from your Teams chats and meetings, Outlook emails, Word documents, PowerPoint presentations, and more—is now part of your AI-powered work experience.

“It’s not really a brand-new capability, but more an evolution of what users already know, which is access to the grounding data in their Microsoft tenant. The difference is that Work IQ adds an additional layer to provide more context, allowing for richer and more relevant results.”

Aisha Hasan, principal product manager, Microsoft Digital

Work IQ enables Copilot to not only tailor answers to your role and responsibilities, but also to understand who your most frequent collaborators are, comprehend details about your latest projects, surface deliverables and deadlines, and intuit next steps. Additionally, Work IQ makes it easy for any AI agent to take advantage of the same rich enterprise data to return and act on more contextual results.

“It’s not really a brand-new capability, but more an evolution of what users already know, which is access to the grounding data in their Microsoft tenant,” says Aisha Hasan, a principal product manager in Microsoft Digital. “The difference is that Work IQ adds an additional layer to provide more context, allowing for richer and more relevant results.”

At Microsoft Digital, the company’s IT organization, we’ve seen firsthand how this intelligence layer is accelerating employee adoption of Copilot and agentic AI as outputs become more perceptive and valuable. Work IQ is a foundational step toward a future where AI has moved beyond isolated assistance and become a trusted professional helper—sometimes described as a digital colleague—that carries out tasks and anticipates needs in every aspect of daily work.

How Work IQ impacts everyday work

One of the most instructive aspects of Work IQ’s impact across our organization is that it happened without a traditional deployment. There was no enablement event for employees or operational playbook distributed to administrators. It didn’t require any changes to the application interfaces. Yet over time, our employee Copilot interactions improved in measurable ways.

“There was a period where we weren’t adding new content to Copilot, and yet I noticed our metrics for quality and user satisfaction kept going up. Why was that? It was because of all these incremental improvements that we refer to as Work IQ.”

Dodd Willingham, principal product manager, Microsoft Digital

This was a direct consequence of introducing a shared intelligence layer into a Microsoft environment that was already rich in work signals. Those work signals are extremely valuable data that was difficult to extract meaning from before the advent of AI. As the technology advanced, we could take full advantage of this data to inform and improve agentic responses.

As Customer Zero for the company, Microsoft Digital was at the forefront of measuring the impact of Work IQ. Our employees saw significant gains in relevance, grounding, and answer coherence in Copilot that were visible in the metrics, even during times when the underlying content remained relatively static. That’s the Work IQ difference.

“There was a period where we weren’t adding new content to Copilot, and yet I noticed our metrics for quality and user satisfaction kept going up,” says Dodd Willingham, a principal product manager in Microsoft Digital. “Why was that? It was because of all these incremental improvements that we refer to as Work IQ.”

At a systems level, Work IQ reasons across a broad cross-section of Microsoft 365 data, including:

• Outlook email content, thread structure, and interaction patterns
• Teams chats, channels, and meeting transcripts
• Calendar events and scheduling metadata
• Documents and files across Word, PowerPoint, Excel, OneDrive, and SharePoint
• Signals that show who collaborates with whom, how often, and in what context

Work IQ can also access structured data in tools like Dynamics 365, Power BI, Power Apps, and other business applications. The ability to extract context and interpret structured and unstructured data in a unified intelligence layer is the reason why Work IQ is making such a difference for our employees.

Making Outlook better

Outlook provides a useful lens on how Work IQ functions because it’s both heavily used by our employees and a highly contextual tool. Although the application hasn’t outwardly changed, the way Copilot interacts with inbox and calendar data has evolved, in part due to richer context provided by Work IQ.

“The intelligence works behind the scenes as you use Outlook. Your inbox just gradually feels more relevant. Outlook adapts to your work patterns, making your inbox feel more like an assistant, instead of a filing cabinet of communications.”

Matthew Marzynski, principal product manager, core experiences, Microsoft Digital

Now when you turn to Copilot in Outlook to summarize email threads, it can surface decision points, action owners, and unresolved issues. Instead of treating email as a collection of messages and providing rote summaries, Copilot perceives it as a record of decisions and commitments over time.

Calendar-related experiences are on a similar trajectory. Meeting preparation and follow‑up suggestions are now drawing on prior interactions with the same participants, relevant documents that were previously shared, and historical patterns around similar meetings.

Work IQ isn’t rule-based automation layered on top of Outlook. Users aren’t configuring new filters or workflows. Instead, the system is adapting based on observed patterns, meaning user behavior can remain the same while output quality improves

“The intelligence works behind the scenes as you use Outlook,” says Matthew Marzynski, a principal product manager for core experiences in Microsoft Digital. “Your inbox just gradually feels more relevant. Outlook adapts to your work patterns, making your inbox feel more like an assistant, instead of a filing cabinet of communications.”

Applying persistent memory

Another important aspect of Work IQ is the ability to retain persistent memory of each employee’s role, responsibilities, and work context. Copilot and other agents no longer need to be continually prompted with details about who the user is and what they’re working on. It learns that information and remembers it going forward.

This feature, also called persistent understanding, builds trust and increases efficiency each time an employee turns to AI for help with their work. AI systems that depend on manual context-setting don’t scale well across large organizations, which we at Microsoft Digital learned as we tested and deployed Copilot across the company.

“The user no longer has to tell the agent, ‘I work in this area, so please tailor your response to that’ every time,” says Anishkumar Ramakrishnan, a principal PM manager in Microsoft Digital. “With Work IQ, Copilot and agents recall it going forward. It remembers things that the user doesn’t even remember themselves about their past work and actions. This is the promise of intelligent context.”

From answers to action: Work IQ and AI agents

As organizations move toward integrating AI agents into all aspects of their day-to-day work, the value of Work IQ increases. Any agent—not just a general-purpose agent like Copilot—that can interpret vast amounts of your unstructured work data is going to produce results that are far more relevant than one that simply draws on general knowledge about a topic or process.

“Before, a builder had to go connector by connector and be very prescriptive—calendar read, email read, meeting access—just to build an agent. Now they can simply point the agent to Work IQ, and it gains contextual access across mail, calendar, meetings, and files through a single connector (API or MCP server).”

Naveen Jangir, principal architect, Microsoft Digital

Early agent implementations relied on narrower task-specific access to data. For each agent, a developer would have to build connections to a particular document library, mailbox, or set of calendar data. Each connection required separate consent and management, which generally resulted in a more limited scope.

But with Work IQ, builders can create agents using Microsoft Copilot Studio or other development platforms (such as Microsoft Foundry) that use APIs or Model Context Protocol (MCP) servers to connect to Microsoft Graph data. This enables them to bring the full power of enterprise data to any agentic creation, not just Microsoft 365 agents.

“Before, a builder had to go connector by connector and be very prescriptive—calendar read, email read, meeting access—just to build an agent,” says Naveen Jangir, a principal architect in Microsoft Digital. “Now they can simply point the agent to Work IQ, and it gains contextual access across mail, calendar, meetings, and files through a single connector (API or MCP server).”

This shift doesn’t just simplify agent development—it fundamentally expands what agents are capable of. Instead of operating within narrow, predefined tasks, agents can now reason across a broader work context to deliver better outcomes. For example, an agent supporting a project manager can surface relevant email threads, identify key stakeholders from meeting activity, reference the latest project documents, and highlight upcoming deadlines—all within a single interaction.

Intelligence without bypassing governance

From a governance perspective, Work IQ doesn’t introduce a new security model. Instead, it operates entirely within the existing Microsoft 365 data protection boundaries that our company and our customers already rely on.

The intelligence layer can access this enterprise data, but it does so while honoring permissions, sensitivity labels, access policies, and compliance controls defined at the source. Work IQ can only surface or act on information that the user—or an agent identity acting on the user’s behalf—is already authorized to access.

This inheritance model is intentional. Governance remains rooted in the data layer, not in the AI layer. Work IQ respects established controls such as identity‑based access and tenant policies, which means agents are generally given less access than human users.

“An agent user only gets access to what is explicitly shared with it,” Jangir says. “Human users typically have broader default access. By design in Work IQ, agents can usually see less than people, not more.”

For IT and security teams, this places the emphasis squarely on data discipline and identity controls, which are complementary security layers. Work IQ amplifies the value of well‑governed data and exposes weaknesses where governance is inconsistent. Admins remain in control of access and can turn off APIs and MCP server connections if they want to limit an agent’s data access.

Work IQ, Fabric IQ, and Foundry IQ

As we’ve scaled up Copilot and agentic AI internally, one lesson has become clear: Intelligence works best when it’s part of a layered infrastructure rather than working on its own.

That’s why Work IQ is just one context layer we’re using at Microsoft. We’ve also developed Fabric IQ and Foundry IQ, which are complementary layers in our overall data strategy. Each of these addresses a different aspect of enterprise intelligence.

The three layers serve distinct but connected purposes:

• Work IQ focuses on unstructured productivity data, helping AI understand how people work across email, meetings, documents, and collaboration signals.
• Fabric IQ applies similar reasoning to analytical and structured data, adding context and explanation to metrics, trends, KPIs, and other business signals.
• Foundry IQ provides the foundation for builders to create agents that draw from both worlds, connecting intelligence across Microsoft 365, analytics platforms, and line‑of‑business systems.

Taken together, these layers also contribute to something deeper: the emergence of a shared business ontology. By extracting and aligning business entities—such as people, projects, and processes—from both structured data in Fabric IQ and the unstructured signals captured by Work IQ, the system perceives meaningful connections that previously were hidden. This unified understanding allows agents to reason across domains with greater precision, linking metrics to the real work and making insights more actionable in context.

This architecture matters because it removes artificial seams. Agents shouldn’t need to shift between separate contexts for work content, enterprise data, or application logic. The IQ layers make it possible to deliver a single agentic experience that reasons consistently, applies governance uniformly, and moves with users across environments. Just as importantly, the same controls—identity, permissions, labeling, and policy—flow through each layer, keeping trust intact as capability expands.

At Microsoft, Work IQ and the other context layers are helping Copilot and agents to accelerate beyond AI experimentation. They are now vital operational tools that make everyone more productive across the global enterprise. Context and intelligence in agentic tools are a key part of the future of work, at Microsoft and for our customers as well.

Key takeaways

Here are some things to keep in mind as you prepare your own organization to take full advantage of Work IQ:

• Treat the technology as infrastructure, not a feature. We didn’t formally roll out Work IQ. Its value emerged gradually as it improved Copilot responses and as our agent builders could more easily tap into unstructured enterprise data.
• Expect improvements in AI quality without changes to your data. We saw measurable gains in relevance and user satisfaction even when underlying content remained the same, driven by better contextual reasoning across existing work signals.
• Focus on how employees work, not just what content exists. Work IQ improves AI outcomes by connecting people, relationships, and activity patterns, resulting in more actionable and grounded responses.
• Use Work IQ to move from assistance to action with agents. By giving agents access to contextual enterprise data through a unified layer, we enabled more automated workflows without requiring developers to manage dozens of connectors manually.
• Invest in data governance early to maximize AI value. Because Work IQ inherits permissions and policies from the data layer, its effectiveness—and safety—relies on clear labeling, intentional access design, and disciplined data management.
• Enable self-service collaboration data so it’s available for Work IQ. WorkIQ can only ground on data that is both available and not purposefully hidden. We make sure that our meetings are AI-enabled (and often recorded) and allow self-service in Teams and SharePoint, so the data is not hidden from Work IQ.
• Build toward a unified intelligence model across work and data. Combining Work IQ with Fabric IQ and Foundry IQ means agents can operate seamlessly across different kinds of data and incorporate more intelligence into their output and actions.

Try it out

Get a closer look at Work IQ.

Related links

• Check out how we’re embracing this agentic moment at Microsoft.
• Explore a Microsoft Learn article for more technical details about how Work IQ works.
• Learn how to get started building agents with Microsoft tools.
• Discover our detailed guide on how we deploy AI agents internally at Microsoft.
• Read an IT playbook for the AI era and learn how we’re becoming a Frontier Firm at Microsoft.
• See how we’re using Model Context Protocol security and governance to protect AI conversations at Microsoft.

The post How Work IQ is supercharging our AI usage at Microsoft appeared first on Inside Track Blog.

Geoff Belknap, CVP and operating CISO shares the questions he asks when considering when and how to integrate technologies with a merged or acquired company.

Key takeaways

Think about moving slowly with early integration with M&A. Here are some key questions to consider:

• What do we risk by combining tools or technical capabilities too quickly?
• Is the deal still valuable if we do not integrate systems?
• What operational safeguards and governance are needed?

The post Microsoft CISO advice: Consider the risks of early integration with mergers and acquisitions appeared first on Inside Track Blog.

On the other: A deep responsibility to protect the enterprise—its data, employees, customers, and regulatory posture—at a time when AI systems are evolving faster than traditional governance models were designed to handle.

“In the era of AI, delaying deployment does not eliminate risk—it often increases it. We need to work even faster to enable our business with AI, while simultaneously protecting our enterprise.”

Brian Fielder, vice president, Microsoft Digital

For CIOs, CDOs, and technology leaders across industries, this is no longer a philosophical debate, it’s an operating reality. How do you accelerate AI‑driven transformation without increasing enterprise risk? And critically, how do you innovate earlier, when learning is most valuable, without sacrificing trust?

At Microsoft, we’re living this tension firsthand, and our experience has led us to clear conclusions.

“In the era of AI, delaying deployment does not eliminate risk—it often increases it,” says Brian Fielder, vice president of Microsoft Digital. “We need to work even faster to enable our business with AI, while simultaneously protecting our enterprise.”

Mastering the delicate balance between risk avoidance and AI-fueled innovation is the new challenge for technology leaders globally. This insight has fundamentally reshaped how we approach release management, AI adoption, and enterprise governance at Microsoft. We call this approach Fast Train, and it has become a core part of how we operate as a Frontier Firm—one that learns early, under control—enabling capabilities that give our employees an edge while carefully balancing enterprise risk.

Rethinking release management for the AI era

Traditional release management was designed for a different world.

“While we’ve never been as risk‑averse as some of our customers, our focus is to always be risk‑aware. When products attest to risk upfront and take ownership at design time, they’re empowered to deploy at full speed—without waiting in a backlog of exceptions.”

B. Ganti, principal architect, Microsoft Digital

Stage‑gated approvals, quarterly releases, and broad “wait until it’s safe” models worked when change was linear, infrequent, and predictable. But AI changes the equation. Models evolve continuously. Capabilities improve weekly. User behavior, as well as risks, emerge dynamically in production.

In this environment, waiting for certainty before deploying often means learning too late.

As Customer Zero for so many of Microsoft’s enterprise products, Microsoft Digital has long been risk aware, with greater tolerance for risk than some of our customers. However, with Fast Train we’re moving at greater speed in low-risk situations.

“While we’ve never been as risk‑averse as some of our customers, our focus is to always be risk‑aware,” says B. Ganti, a principal architect in Microsoft Digital. “When products attest to risk upfront and take ownership at design time, they’re empowered to deploy at full speed—without waiting in a backlog of exceptions.”

Legacy models concentrate exposure until a global rollout, when:

• Dependency has already hardened
• Mitigation options are limited
• The blast radius is at its largest

Frontier organizations take a different approach. They treat release management not as a gate, but as an adaptive operating system—one designed to surface signal early, while controls still matter.

While you won’t have access to Microsoft solutions at design time, these same principles are useful as you consider how to “shift left” when you build or acquire new digital capabilities in your environment. Design time in this context might be early visibility of new features or capabilities in the Microsoft 365 Message Center. Applying a Fast train mentality can help you to quickly identify trusted updates to bring into your environment immediately versus those that might require deeper assessment prior to deployment.

At Microsoft, that shift reframed a core question:

Not “How do we safely deploy change at scale?”, but instead “How do we learn earlier, safely, and continuously?”

Fast Train: Learning early, at enterprise scale

Fast Train is not a shortcut around governance. It is Microsoft’s primary early‑Frontier deployment model for low‑ and medium‑risk innovation.

Under Fast Train, eligible capabilities are deployed earlier—often globally—inside Microsoft’s own enterprise environment, under explicit guardrails. This allows product teams to learn from real usage patterns, real data flows, and real operational behavior before expectations harden and dependencies scale.

Critically, Fast Train operates on a simple principle: speed should align to risk, not to organizational inertia.

Instead of forcing every capability down the slowest possible path, Fast Train uses risk‑adaptive deployment shapes:

• Default‑on Frontier deployment for lower‑risk capabilities
• Admin‑gated Frontier deployment for higher‑impact or tenant‑sensitive scenarios
• Standard or deferred release only where risk truly demands it

In all cases, innovation moves forward. What changes is how it is enabled, not whether it progresses at all.

Why early deployment can reduce risk

From a security and compliance perspective, this may sound counterintuitive. Isn’t early deployment riskier?

In practice, we’ve observed the opposite. The most dangerous moment for an enterprise system is not early exposure, it’s late discovery. Waiting until adoption is widespread before learning how a capability behaves:

• Reduces mitigation options
• Expands blast radius
• Compresses response timelines under regulatory or customer pressure

“The question isn’t how to eliminate risk entirely—it’s where we’re willing to be uncomfortable, so our employees don’t work around IT.”

David Johnson, principal tenant architect, Microsoft Digital

By contrast, Frontier deployment reverses this risk profile. Fast Train allows Microsoft to:

• Surface data flow issues and edge cases earlier
• Tune controls before dependencies harden
• Establish clear accountability for rollback, disablement, and remediation

This is risk‑aware innovation, not risk‑blind speed. Guardrails are built in and not bolted on after the fact.

Governance that adapts instead of blocks

One of the most significant shifts Fast Train enabled was a change in how governance participates in innovation.

“Fast Train is fundamentally a risk-taking exercise—but it’s a deliberate one,” says David Johnson, principal tenant architect in Microsoft Digital. “The question isn’t how to eliminate risk entirely—it’s where we’re willing to be uncomfortable, so our employees don’t work around IT. If the platform honors our non‑negotiables—security, compliance, discovery—then we don’t need to over‑rotate on every new feature built on top of it.”

Traditional models treat governance as a final checkpoint. Governance is an episodic approval that happens after most key decisions are already made. Frontier models embed governance earlier and continuously, focusing attention where it matters most.

“Innovation doesn’t have to be slowed down by governance,” Ganti says. “By shifting risk consideration to design time, we remove friction at the point of deployment—so teams can move straight onto the Fast Train, with no toll booths, no gates, and no delays.”

Under Fast Train:

• Low‑risk change moves quickly under defined boundaries
• Higher‑impact capabilities shift to choice‑based enablement
• Deep governance review is reserved for material risk events like new data flows, boundary changes, or regulatory impact

This keeps governance focused, effective, and credible while avoiding the trap of over‑governing low‑risk change.

Just as importantly, Fast Train makes our Microsoft product teams explicitly accountable. Ownership for quality, rollback, and remediation sits with the teams shipping the capability, not with downstream review bodies. That means product teams have an incentive to build features that meet our Fast Train criteria, increasing the chance that our customers can also deploy new capabilities more quickly and with less risk.

Admin‑gated does not mean anti‑Frontier

A common misconception is that admin‑gated or choice‑based deployment is inherently slower or less innovative. Our experience in Microsoft Digital suggests the opposite.

Admin‑gated Frontier deployments are not a retreat from innovation. They are a different exposure shape for the same learning objective. We use them when impact is higher and explicit tenant choice matters.

In both default‑on and admin‑gated Frontier deployment:

• Capabilities reach real users early
• Deployment is global
• Learning loops start before broad GA expectations harden

The distinction is not speed. It’s enablement mechanics, informed by the risk profile of the deployment.

Becoming a Frontier Firm is a maturity journey

Frontier behavior is a maturity that advances over time.

“Our focus is evolving to put greater focus on speed and enablement. Fast Train lets governance teams focus on truly high‑risk scenarios while giving product teams the guidance and tools they need upfront so they can move faster with confidence.”

Priya Chebiyam, principal product manager, Microsoft Digital

In Microsoft Digital, we measure ourselves against a Frontier Firm capability maturity model, which reflects how organizations evolve from risk averse release models toward risk aware, signal driven operations. Our internal rubric describes 5 stages of enterprise maturity:

Frontier Firm capability maturity model

“Our focus is evolving to put greater focus on speed and enablement,” says Priya Chebiyam, principal product manager in Microsoft Digital. “Fast Train lets governance teams focus on truly high‑risk scenarios while giving product teams the guidance and tools they need upfront so they can move faster with confidence.”

Today, we assess ourselves in the Emerging Frontier stage, operating Fast Train broadly while investing to further institutionalize continuous governance, telemetry, and accountability. A critical step in that journey has been onboarding Microsoft 365 Copilot and first‑party agents into the Fast Train operating model to expand early signal and tighten ownership.

The lesson for customers isn’t to copy Microsoft’s internal processes, but to adopt the pattern:

• Define where early learning is safe through your own criteria—these are effectively your organizational “guardrails”
• Make enablement choices explicit
• Require ownership and rollback readiness
• Let real‑world signal and not assumptions drive your decisions

Trust and innovation advance together

At Microsoft, Fast Train has reinforced a simple truth: speed, trust, and compliance are not tradeoffs. They are outcomes of a risk‑adaptive operating model.

“Fast Train is built on a simple principle: ship fast when it’s safe, and slow down only when it’s necessary,” Chebiyam says. “We empower feature owners to self‑attest low‑risk features using clear criteria, while still protecting security, privacy, compliance, and regulatory requirements.”

By learning earlier—under control—organizations can reduce late‑stage surprises, accelerate transformation, and engage partners and stakeholders from a position of evidence rather than theory.

“We will be deploying earlier under the right guardrails so we can understand real world behavior, build the right controls, and earn customer trust through evidence, not assumptions. Our responsibility is not to slow innovation down, but to enable it safely—at the speed our customers and the market demand.”

Aleš Holeček, chief architect and corporate vice president, Microsoft Security

In the AI era, the greatest enterprise risk isn’t moving too fast—it’s learning too slow.  Fast Train reflects a shift from risk avoidance to risk awareness and near real-time assessment.

“We will be deploying earlier under the right guardrails so we can understand real‑world behavior, build the right controls, and earn customer trust through evidence, not assumptions,” says Aleš Holeček, chief architect and corporate vice president in Microsoft Security. “Our responsibility is not to slow innovation down, but to enable it safely—at the speed our customers and the market demand.”

Frontier firms don’t move fast despite risk. They move fast because risk is understood, bounded, and actively managed.

Key takeaways

For CIOs, CDOs, and technology leaders ready to accelerate AI adoption while minimizing risk, Microsoft Digital’s experience suggests five practical actions you can take today:

• Treat early deployment as a risk‑reduction strategy. Surface issues earlier when mitigation options are still available, instead of discovering them after global dependency sets in.
• Establish a clear Frontier cohort. Identify a workload, geography, or business unit where early learning is safe, intentional, and governed and be intentional in empowering that cohort.
• Separate innovation speed from enablement mechanics. Use default‑on deployment for low‑risk capabilities and admin‑gated choice for higher‑impact scenarios without slowing learning velocity.
• Make governance continuous, not episodic. Shift governance left by embedding it earlier with monitoring, attestation, and clear escalation triggers rather than relying on late‑stage gates.
• Require explicit ownership and rollback readiness. Ensure every deployed capability has a named owner, a defined rollback path, and continuous telemetry to support fast correction.

Try it out

Looking to accelerate your journey to the Frontier? Try Microsoft Agent 365 in your company.

Related links

• Check out our IT playbook for becoming a Frontier Firm.
• Read more about the agentic future that we’re embracing at Microsoft.
• Discover our readiness guide for deploying AI agents, based on our own company’s experience.
• Learn how we’re transforming our enterprise IT operations with AI at scale.
• Explore our five-step guide to enterprise AI maturity for IT leaders.

We’d like to hear from you!

• Want more information? Email us and include a link to this story and we’ll get back to you.

The post Fast Train to the AI Frontier: Balancing risk and innovation in the era of AI at Microsoft appeared first on Inside Track Blog.

At Microsoft Digital, the company’s IT organization, we shape and propel many of our groundbreaking products through our role as the company’s Customer Zero—and we want to tell that story. At this year’s Microsoft 365 Community Conference, we hosted a variety of sessions focused on change management, AI adoption, and how we manage governance in the era of the Frontier Firm.

As Customer Zero for Microsoft 365 Copilot, we embedded the technology into our employees’ daily workflows and carefully monitored the results. That journey from early experimentation to broad adoption of the tool across our organization continues to guide the company as we explore what comes next.

Today, that’s agents.

“Copilot changes how our employees work. Agents are changing how the work gets done. Our focus is to make the technology practical and valuable, so people want to use it daily.”

Stephan Kerametlian, senior director, business program management, Microsoft Digital

We’ve reached a level of maturity with Copilot that allows us to move from individual productivity to systems that can reason and collaborate on our behalf. Our focus now is on driving the adoption of agents across the company, grounding them in our workflows to solve problems.

“Copilot changes how our employees work,” says Stephan Kerametlian, a senior director in Microsoft Digital. “Agents are changing how the work gets done. Our focus is to make the technology practical and valuable, so people want to use it daily.”

Adoption doesn’t happen without trust

As we’ve empowered employees with more capable AI tools that can help automate tasks and make decisions, we’ve been equally focused on making sure the right safeguards are in place.

Innovation and safety are extremely important—the challenge is to enable both at the same time. And this is where governance comes in.

“We’ve spent a lot of time getting governance right. This means giving people confidence, not slowing them down. When employees know the guardrails are there, they feel empowered to experiment and innovate safely.”

David Johnson, principal PM architect, Microsoft Digital

At Microsoft, good governance is what makes innovation sustainable. It’s how we protect the company, our data, and our customers, while still giving employees the freedom to build and push boundaries with AI.

“We’ve spent a lot of time getting governance right,” says David Johnson, a principal PM architect in Microsoft Digital. “This means giving people confidence, not slowing them down. When employees know the guardrails are there, they feel empowered to experiment and innovate safely.”

How Microsoft does IT: Managing and governing agents—empower with risk-aligned oversight

Session description: See how Microsoft Digital empowers employees with tools to build and manage agents. From agent management with Microsoft Agent 365, to securing our environment with Microsoft Defender, to managing our productivity estate with Microsoft Purview, this session offers broad insights into how we use our own technology to accelerate agentic innovation while mitigating risk.

Speakers: David Johnson, Naveen Jangir, and Mike Powers

David Johnson leads our internal Microsoft 365 and productivity services with responsibility for tenant strategy, architecture, and governance. He manages how we empower employees with guardrails and manages our capability onboarding and tenant configuration.

Naveen Jangir is a principal architect in Microsoft Digital. He drives Microsoft 365 security and compliance strategy and leads tenant architecture and capability onboarding, while overseeing secure adoption of services across the enterprise.

Mike Powers is a senior service engineer and AI administrator in Microsoft Digital who manages Copilot features, Agent 365, and enterprise AI operations. He partners with internal product groups and security stakeholders to make sure AI tools and agents are deployed responsibly and governed effectively.

More on AI agents and governance at Microsoft

• Read the guide to how we’re tackling Microsoft 365 Copilot governance internally at Microsoft.
• See how we’re embracing the agentic future to become a Frontier Firm.
• Learn how we deployed the Employee Self-Service Agent at Microsoft. 

Inside Microsoft: Reclaiming engineering time with AI in Azure DevOps

Session description: AI tools embedded directly into Azure DevOps (ADO) are changing how engineering teams work, eliminating manual tasks without creating separate tools or increasing cognitive load. This session explores how ADO AI Chat and the AI Work Item Assistant accelerate coding workflows at Microsoft. You’ll learn how to improve your backlog quality, sprint hygiene, and downstream effectiveness of GitHub Enterprise and Copilot, helping your teams reclaim capacity and focus on the work that moves products forward.

Speakers: Gopal Panigrahy and Sumit Dutta

Gopal Panigrahy is a product leader and member of our product management team in Microsoft Digital. He’s an advocate for our customer-first approach to product development and is passionate about helping people overcome challenges in the era of AI.

Sumit Dutta is a product-minded technology leader working at the intersection of AI, enterprise platforms, and scalable product design. Offering a strong blend of engineering knowledge and product strategy, he focuses on building systems that are not just functional but also extensible and reliable.

More on AI and IT engineering at Microsoft

• Learn how we’re reclaiming engineering time with AI in Azure DevOps at Microsoft.
• Read about powering the new age of AI-led engineering in IT at Microsoft.
• Discover how we’re streamlining engineering at Microsoft with Azure DevOps.

How Microsoft does IT: Microsoft 365 governance in the age of Copilot and agents

Session Description: Microsoft 365 Copilot and Copilot agents are powerful tools, but without proper governance, you could be putting your company at risk. In this lightning talk, you’ll learn how Microsoft Digital protects our enterprise while enabling employee innovation with Copilot and agents.

Speaker: David Johnson

Johnson brings hands-on experience operating Copilot and AI-powered agents inside Microsoft, with a focus on identity, permissions, data boundaries, and real-world misuse prevention. He takes real-world lessons and makes them practical for others.

More on governance at Microsoft

• Learn about how we’re tackling Microsoft 365 Copilot governance internally at Microsoft.
• Check out our guide to deploying Microsoft 365 Copilot in five chapters.
• Read how we’re powering data governance with Purview Unified Catalog.

Accelerating AI adoption with Copilot controls: Lessons from Microsoft Digital

Session description: Microsoft 365 Copilot and AI agents unlock productivity gains, but without careful oversight they can also introduce security and compliance risks. The session covers how the Copilot Control System helps scale AI safely, including adoption insights and satisfaction signals. You’ll also see demos of popular agents, including the Employee Self-Service Agent and the Admin agent.

Speakers: Amy Ceurvorst and Reshma Kapoor

Amy Ceurvorst is a director of business programs In Microsoft Digital. She’s worked extensively with Copilot controls and evangelizes a unified way to view Copilot health reports that help administrators understand Copilot health.  

Reshma Kapoor is a senior product manager in Microsoft Digital with 20 years of experience leading and shipping products at scale. She is customer‑obsessed, grounding product decisions in real customer signals to deliver intuitive, high‑impact experiences.

More on AI and Copilot adoption and deployment

• Read how we’re shaping AI management at Microsoft with Agent 365 and Copilot controls.
• Explore our five-chapter guide to deploying Microsoft 365 Copilot internally.
• Learn how we deployed Microsoft 365 Copilot in Viva Engage at Microsoft.

How Microsoft does IT: Driving adoption of Microsoft 365 Copilot and agents across Microsoft

Speakers: Cadie Kneip and Stephan Kerametlian

Session description: Our team at Microsoft Digital led the first enterprise-scale deployment of Microsoft 365 Copilot, launching to more than 300,000 employees and vendors worldwide. Learn how the team drove adoption using change management strategies to encourage employees to thread Copilot into their daily work. Now we’re doing the same for agents across the enterprise. Learn best practices for accelerating adoption and maximizing value while guiding your own journey with Copilot and AI agents.

Cadie Kneip is a senior business program director and the Copilot Champs community lead in Microsoft Digital. She specializes in turning complex AI initiatives into confidence-building pathways that help employees thrive in an AI-powered workplace. 

Stephan Kerametlian is a senior director in Microsoft Digital, where he leads our global change management efforts for Copilot and agents. He thrives on learning how people use AI and on finding ways to get more people to embrace the technology.

More on adoption and deployment of Copilot and agents

• Explore our guide on how we deployed Microsoft 365 Copilot internally.
• Find out how we’re skilling up for the future of work at Microsoft with Agent Launchpad.

Real-world adoption stories: A fireside chat with a key customer

Session description: Pull back the curtain on the customer experience with Copilot adoption. Join this fireside chat with a Microsoft customer to hear about lessons learned and the real impact that Copilot is delivering across their organization. You’ll glean practical insights you can apply immediately at your own company. 

Speakers: Karuana Gatimu and Sam Crewdson

Karuana Gatimu is a director of Customer Advocacy – AI & Collaboration in Microsoft Digital and a solution architect driven by a passion for people, storytelling, and leadership. With 30 years of experience at the intersection of technology and human impact, she turns complex innovation into compelling narratives that help organizations adopt change and deliver business value.

Sam Crewdson, a principal product manager in Microsoft Digital, is passionate about turning user insights into product improvements. His work focuses on driving adoption of the latest SharePoint features and helping users take advantage of the power of both SharePoint and OneDrive. Working at the intersection of IT, users, feedback, and strategy, he translates real‑world business needs into collaborative experiences that scale.  

More insights on Copilot adoption

• Learn about how we’re tackling Microsoft 365 Copilot governance internally at Microsoft
• Check out our guide for deploying Microsoft 365 Copilot in five chapters.
• Read our executive-level guide covering our Copilot deployment.

Try it out

• Learn more and sign up for the 2027 Microsoft 365 Community Conference.
• Start using Microsoft 365 Copilot.
• Learn how to build your own AI-powered agents and workflows.

Related links

• Find out about the keynote presentations that happened at the 2026 Microsoft 365 Community Conference.
• See how we’re serving as Customer Zero at Microsoft in the era of AI.
• Read about Copilot Control System security and governance.
• Learn about deploying Microsoft Agent 365: How we’re extending our infrastructure to manage agents at Microsoft.
• Discover how the Employee Self-Service Agent helps employees quickly complete IT and HR tasks.

We’d like to hear from you!

• Want more information? Email us and include a link to this story and we’ll get back to you.

The post Unfolding our AI-in-IT story: What to expect at the 2026 Microsoft 365 Community Conference appeared first on Inside Track Blog.

In light of this priority, we have established a data council to help accelerate our companywide AI-powered transformation.

Our data council is a cross-functional team with representation from multiple domains within Microsoft, including Microsoft Digital, the company’s IT organization; Corporate, External, and Legal Affairs (CELA); and Finance.

“By championing robust data governance, literacy, and responsible data practices, our data council is a crucial part of our AI-powered transformation. It turns enterprise data into a strategic capability that fuels predictive insights and intelligent outcomes across the organization.”

Naval Tripathi, principal engineering manager, Microsoft Digital

Our data council’s mission is to drive transformative business impact by establishing a cohesive data strategy across Microsoft Digital, empowering interconnected analytics and AI at scale. Our vision is to guide our organization toward Frontier Firm maturity through a clear blueprint for high-quality, reliable, AI-ready data delivered on trusted, scalable platforms.

“By championing robust data governance, literacy, and responsible data practices, our data council is a crucial part of our AI-powered transformation,” says Naval Tripathi, principal engineering manager in Microsoft Digital. “It turns enterprise data into a strategic capability that fuels predictive insights and intelligent outcomes across the organization.”

Our evolving data strategy

Over the past two decades, we at Microsoft—along with other large enterprises—have continuously evolved our data strategies in search of the right balance between control and agility. Early approaches were highly decentralized, with different teams owning and managing their own data assets. While this enabled local optimization, it also resulted in inconsistent quality and limited enterprise-wide insight.

Our subsequent shift toward centralized data platforms brought much-needed standardization, security, and scalability. However, as data platforms grew more sophisticated, ownership often drifted away from the business domains closest to the data, slowing responsiveness and diluting accountability.

Today, we and other leading companies are embracing a more balanced, federated approach, often described as a data mesh. Rather than forcing all our data into a single centralized system or allowing unchecked decentralization, the data mesh formalizes domain ownership while embedding governance, quality, and interoperability directly into shared platforms.

With this approach, our domain teams publish data as well-defined, discoverable products, while common standards for security, metadata, and compliance are enforced through automation rather than manual processes. This model preserves enterprise trust and consistency without sacrificing speed or autonomy.

By adopting a data mesh mindset, we can scale analytics and AI more effectively across the organization while still keeping ownership closely connected to the business focus. The result is a system that supports innovation at the edges, strong governance at the core, and seamless collaboration across domains, enabling the transformation of data from a technical asset to a strategic, enterprise-wide capability.

Quality, accessibility, and governance

To scale enterprise data and AI, organizations must first ensure their data is trusted, discoverable, and responsibly governed. At Microsoft Digital, our data strategy is designed to create data foundations that power intelligent applications and effective decision making across the company.

“High-quality, well-governed data is essential to accelerate implementation and adoption of AI tools. Data quality, accessibility, and governance are imperatives for AI systems to function effectively, and recognizing that is propelling our data strategy.”

Miguel Uribe, principal PM manager, Microsoft Digital

By implementing a data mesh strategy at scale, we aim to unlock valuable data insights and analytics, enabling advanced AI scenarios. Our data council focuses on three core dimensions that make AI-ready data possible:

• Quality: Making sure enterprise data is reliable and complete
• Accessibility: Enabling secure and discoverable access to data
• Governance: Protecting and managing our data responsibly

Together, these dimensions form the foundation for scalable innovation and AI-powered data use. They connect data silos and ensure consistent, high‑quality access across the enterprise—enabling both humans and AI systems to work from the same trusted data foundation. As AI use cases mature, this foundation allows AI agents to retrieve and reason over data through enterprise endpoints, while supporting advanced analytics, data science, and broader technology.

“High-quality, well-governed data is essential to accelerate implementation and adoption of AI tools,” says Miguel Uribe, a principal PM manager in Microsoft Digital. “Data quality, accessibility, and governance are imperatives for AI systems to function effectively, and recognizing that is propelling our data strategy.”

Quality

AI-ready data is available, complete, accurate, and high-quality. By adopting this standard, our data scientists, engineers, and even our AI agents are better able to locate, process, and govern the information needed to drive our organization and maximize AI efficiencies.

By utilizing Microsoft Purview, our data council can oversee the monitoring of data attributes to ensure fidelity. It also monitors parameters to enforce standards for accuracy and completeness.

Accessibility

Ensuring that our employees get access to the information they need while prioritizing security is a foundational element of our enterprise data strategy. Microsoft Fabric allows us to unify our organization’s siloed data in a single “mesh” that enables advanced analytics, data science, data visualization and other connected scenarios.

Microsoft Purview then gives us the ability to democratize that data responsibly. By implementing a data mesh architecture, our employees can work confidently, unencumbered by siloed or inaccessible data, and with the assurance that the data they’re working with is secure.

The data mesh connects and distributes data products across domains, enabling shared data access and compute while scaling beyond centralized architectures.

Platform services are standardized blueprints that embed security, interoperability, policies, standards, and core capabilities—providing guardrails that enable speed without fragmentation.

Data management zones provide centralized governance capabilities for policy enforcement, lineage, observability, compliance, and enterprise-wide trust.  

Governance

As organizations scale AI capabilities, strong governance becomes essential to ensure security, compliance, and ethical data use. Data governance—which includes establishing data policies, ensuring data privacy and security, and promoting ethical AI usage—is critical, as is compliance with General Data Protection Regulation (GDPR) and Consumer Data Protection Act (CDPA) regulations, among others.

However, governance is not only a technical capability; it’s also a cultural commitment.

Responsible data use must be embedded into the way teams manage data and build AI solutions. Through Microsoft Purview, we implemented an end-to-end governance framework that automates the discovery, classification, and protection of sensitive data across the enterprise data landscape.

This unified approach allows teams to innovate confidently, knowing that the data powering their insights and AI systems is trusted and protected, as well as responsibly managed.

“AI systems are only as reliable as the data that powers them,” Uribe says. “By investing in trusted and well-managed data, we accelerate not only the adoption of AI tools but our ability to generate meaningful insights and intelligent outcomes.”

The data catalog as the discovery layer

By serving as a common discovery layer for humans and AI, the data catalog ensures that governance translates directly into speed, accuracy, and trust at scale.

A unified data strategy only succeeds if both people and AI systems can consistently find the right data. At Microsoft, this is enabled by our enterprise data catalog, which operationalizes the standards set by our data council. 

For business users, the catalog provides intuitive search, ownership transparency, and trust signals—enabling confident self‑service analytics. For AI agents, the same catalog exposes machine‑readable metadata, allowing agents to programmatically discover canonical datasets, validate schema and freshness, and respect governance constraints.

Our role as Customer Zero

In Microsoft Digital, we operate as Customer Zero for the company’s enterprise solutions, so that our customers don’t have to.

That means we do more than adopt new products early. We deploy them at enterprise-scale, operate them under real‑world constraints, and hold them to the same standards our customers expect. The result is more resilient, ready‑to‑use solutions and a higher quality bar for every enterprise customer we serve.

“When we engage product teams with real telemetry from how data is created, governed, and consumed at scale, we move the conversation from theory to execution. That’s how enterprise readiness becomes real.”

Diego Baccino, principal software engineering manager, Microsoft Digital

Our data council embodies this Customer Zero mindset through its Enterprise Readiness initiative. By engaging product engineering as a unified enterprise voice, the council drives strategic conversations that surface operational blockers, influence roadmap prioritization, and ensure new and existing data solutions are truly ready for enterprise use.

These learnings are then shared broadly across Microsoft Digital to accelerate adoption, reduce duplication, and scale proven patterns across teams.

“When we engage product teams with real telemetry from how data is created, governed, and consumed at scale, we move the conversation from theory to execution,” says Diego Baccino, a principal software engineering manager in Microsoft Digital and a member of the council. “That’s how enterprise readiness becomes real.”

This work is deeply integrated with our AI Center of Excellence (CoE), where Customer Zero principles are applied to accelerate AI outcomes responsibly. Together, the AI CoE and the data council focus on improving data documentation and quality—foundational capabilities that are required to make AI feasible, trustworthy, and scalable across the enterprise.

By grounding AI innovation in measurable data quality and governance standards, Microsoft Digital ensures that experimentation can safely mature into production‑ready solutions. The partnership between our data council, our AI CoE, and our Responsible AI (RAI) Council is essential to our broader data and AI strategy.

“AI readiness isn’t aspirational—it’s operational,” Baccino says. “By measuring the health of our data, setting clear quality baselines, and using those signals to guide product and platform decisions, we turn data into a strategic asset and AI into a repeatable capability.”

Together, these teams exemplify what it means to be Customer Zero: Transforming enterprise experience into action, governance into acceleration, and data into durable competitive advantage.

Learn more

Read about our AI Center of Excellence.

Advancing our data culture

Our data council plays a pivotal role in advancing the organization transition from data literacy to enterprise data and AI capability. In conjunction with our AI CoE, it creates curricula and sponsors learning pathways, operational practices, and community programs to equip our employees with the skills and mindset required to thrive in a data- and AI-centric world.

While early efforts focused on improving data literacy, our data council ’s mission has evolved to enable data and AI capability at scale together with our AI CoE—where employees not only understand data but can effectively apply it to build, operate, and govern intelligent solutions.

“Our focus is not just teaching our teams about data. It is enabling employees to apply data to create AI-driven outcomes. When teams understand how data powers AI systems, they can make better decisions, design better products, and build more responsible AI experiences.”

Miguel Uribe, principal product manager, Microsoft Digital

Our curriculum includes high-level courses on data concepts, applications, and extensibility of AI tools like Microsoft 365 Copilot, as well as data products like Microsoft Purview and Microsoft Fabric.

By facilitating AI and data training, offering internally focused data and AI certifications, and internal community engagement, our council ensures that employees develop the capabilities required to responsibly build and operate AI-powered solutions. Achieving data and AI certifications not only promotes career development through improved data literacy, it also enhances the broader data-driven culture within our organization.

“We recognize that AI capability is built when data skills are applied directly to real AI scenarios and business outcomes—not when learning exists in isolation,” Uribe says. “Our focus is not just teaching our teams about data; it is enabling employees to apply data to create AI‑driven outcomes. When teams understand how data powers AI systems, they can make better decisions, design better products, and build more responsible AI experiences.”

Find out more

Learn how a Copilot Expo helped us build interest in Microsoft 365 Copilot.

Lessons learned

Our data council was created to develop and execute a cohesive data strategy across Microsoft Digital and to foster a strong data culture within our organization. Over time, several critical lessons have emerged.

Executive sponsorship enables transformation

Executive sponsorship is a key element to ensure implementation and adoption of a data strategy. Our leaders are committed to delivering and sustaining a robust data strategy and culture and have been effective champions of the council’s work.

“Leadership provides support and reinforcement of the council’s mission, as well as guidance and clarity related to diverse organizational priorities,” Baccino says.

Cross-functional collaboration accelerates impact

Our council’s work has also benefited from the diverse representation offered by different disciplines across our organization. Embracing diverse perspectives and understanding various organizational priorities is critical to implementing a successful data strategy and culture in a large and complex organization like Microsoft Digital.

Modern platforms allow for scalable AI productivity

Technology and architecture also play a critical role in enabling enterprise data and AI capability. Platforms like Microsoft Purview and Microsoft Fabric provide the governance, discovery, and analytics infrastructure required to create trusted, AI-ready data ecosystems.

Combined with strong leadership support and community engagement, these platforms allow our organization to move beyond isolated data projects toward connected, enterprise-wide intelligence.

As our organization continues to evolve, our data council’s strategic work and valuable insights will be crucial in shaping the future of data-driven decision making and AI transformation at Microsoft.

Key takeaways

Here are some things to keep in mind as you contemplate forming a data council to help you manage and scale AI impacts responsibly at your own organization:

• A data mesh strikes the balance enterprises have been chasing. By formalizing domain ownership while enforcing standards through shared platforms, you avoid both chaotic decentralization and slow, over-centralized control.
• Governance is an accelerator when it’s automated and embedded. Using platforms like Microsoft Purview and Microsoft Fabric, governance shifts from a manual gatekeeping function to a built‑in capability that enables faster, trusted analytics and AI.
• AI systems are only as strong as their discovery layer. A unified enterprise data catalog allows both people and AI agents to find, trust, and use data consistently—turning standards into operational speed.
• Customer Zero turns theory into enterprise‑ready execution. By operating its own data and AI platforms at scale, Microsoft Digital provides real telemetry and practical feedback that directly shapes product readiness.
• Building AI capability is a cultural effort, not just a technical one. Our data council’s focus on applied learning, certification, and real-world AI scenarios ensures data skills translate into durable business outcomes.
• AI scale exposes the cost of fragmented data ownership. A data council cuts through silos by aligning priorities, resolving tradeoffs, and concentrating investment on the data assets that matter most for AI impact.
• Shared metrics create shared ownership. Publishing data quality and AI‑readiness scores at the leadership level reinforces accountability and positions data as a core enterprise asset.

Try it out

New to Microsoft 365 Copilot? Check it out!

Related links

• Learn more about the councils that are steering AI projects at Microsoft.
• See how we’re tackling Microsoft 365 Copilot governance internally at Microsoft.
• Explore how we’re unlocking enterprise AI extensibility at Microsoft with Microsoft Copilot Studio.
• See AI-powered agents in action: How we’re embracing this new ‘agentic’ moment at Microsoft.

The post Harnessing AI: How a data council is powering our unified data strategy at Microsoft appeared first on Inside Track Blog.

As AI reshapes how we work and live, it brings with it both transformative potential and complex challenges. Across the industry, concerns about bias, safety, and transparency are growing.

At Microsoft, we believe that realizing AI’s benefits requires a shared commitment to responsibility—one we take seriously. As a result, we aren’t just creating AI solutions. We’re taking the lead on infusing responsible AI principles into our technology and organizational practices.

Prioritizing responsible AI across Microsoft

The most impressive AI-powered capabilities in the world mean nothing if people don’t trust the technology. Microsoft and many of our customers across all industries are working to strike the right balance between innovation and responsibility.

“We’re on a multi-year journey born out of the need to support innovation—and do it in a way that builds trust. Along the way, we’ve continued to iterate and evolve the program through a series of building blocks.”

Mike Jackson, head of AI Governance, Enablement, and Legal, Microsoft Office of Responsible AI

IT leaders and CXOs aren’t just deploying AI tools. They’re also thinking of the right guardrails to implement around those tools as their organizations mature. Meanwhile, developers and deployers want to be sure they’re building and implementing AI solutions within the bounds of responsibility.

As an organization that’s mapping the frontier of AI while creating business-ready tools for our customers, Microsoft is shaping the global conversation on responsible AI. We don’t only accomplish that through policy and governance, but also by embedding responsibility into the ways we build, deploy, and scale AI.

Laying the foundation for this work is the duty of our Office of Responsible AI (ORA). This team brings policy and governance expertise to the responsible AI ecosystem at Microsoft.

“We’re on a multi-year journey born out of the need to support innovation—and do it in a way that builds trust,” says Mike Jackson, head of AI Governance, Enablement, and Legal for the Office of Responsible AI. “Along the way, we’ve continued to iterate and evolve the program through a series of building blocks.”

ORA advances AI development, deployment, and secure and trustworthy innovation through governance, legal expertise, internal practice, public policy, and guidance on sensitive uses and emerging technology. The team focuses on empowering innovation while ensuring it falls within Microsoft’s governance, compliance, and policy guardrails.

ORA also partners closely with product and engineering teams as well as other trust domains like privacy, digital safety, security, and accessibility. The team created our Microsoft Responsible AI Standard, the cornerstone of our governance framework, and ensures internal AI initiatives align with it.

The Responsible AI Standard translates our six principles into actionable requirements for every AI project across Microsoft:

ORA reports into the Microsoft Board of Directors and collaborates with stakeholders and teams across the company to operationalize these principles, implementing policies and practices that apply to AI applications. They determined that every AI initiative should undergo an impact assessment to ensure it aligns with the standard.

If ORA is our compass for responsible AI, our companywide Responsible AI Council has its hands on the steering wheel.

The council, led by Chief Technology Officer Kevin Scott and Vice Chair and President Brad Smith, was formed at the senior leadership level as a forum and source of representation across research, policy, and engineering. It provides leadership, strategic guidance, and executive support and sponsorship to advance strategic objectives around innovation and responsible AI.

“ORA has established clear principles and a step-by-step assessment framework and tool. Our responsibility is to rigorously follow this process and ensure compliance across our products and initiatives.”

Naval Tripathi, principal engineering manager and co-lead, Microsoft Digital Responsible AI team

Under the council’s guidance, responsible AI CVPs, division leaders, and a network of responsible AI champions across the company operationalize the implementation of our Responsible AI Standard and compliance with our policies.

The structure of these teams is straightforward.

Every division has a designated CVP and division lead to steer the work and connect their team to the overarching Responsible AI Council. Within those divisions, each organization has a lead responsible AI champion or a set of co-leads to steer their team of champions. Those champions act as subject matter experts, reviewers for the impact assessment process, and points of contact for the teams developing AI initiatives.

Implementing AI governance within Microsoft IT

As members of the company’s IT organization, Microsoft Digital’s responsible AI division lead and champion team have a special role to play. They helped develop a critical internal workflow tool, which has now become a mandatory part of our responsible AI assessment process.

“The key is to ensure full alignment of responsible AI practices with ORA,” says Naval Tripathi, principal engineering manager and co-lead for Microsoft Digital’s Responsible AI Team. “ORA has established clear principles and a step-by-step assessment framework and tool. Our responsibility is to rigorously follow this process and ensure compliance across our products and initiatives.”

This tool logs every project, guides AI developers through initial impact assessments all the way to final reviews, and facilitates those workflows for champions.

“As organizations develop a diverse ecosystem of AI agents, often created by multiple engineering teams, it becomes essential to establish a standardized evaluation process. This ensures every agent adheres to enterprise-level standards before we deploy and distribute it to end users.”

Thomas Po, senior product manager, Microsoft Digital

By streamlining the process through a unified portal, the tool increases efficiency and minimizes errors that can arise from manual processes. It also encourages teams to make responsible AI part of the software development lifecycle (SDL) itself, not a hurdle or an afterthought.

“As organizations develop a diverse ecosystem of AI agents, often created by multiple engineering teams, it becomes essential to establish a standardized evaluation process,” says Thomas Po, a senior product manager working on Campus Services agents. “This ensures every agent adheres to enterprise-level standards before we deploy and distribute it to end users. That makes it more manageable in the long term, and having it all in one tool gives us more transparency.”

Our unified internal workflow looks like this:

• Project initiation and system registration: During the design phase for an AI initiative, the engineering team accesses the portal and registers a new AI system. From there, they fill out fields with crucial information, including a title, description, the developer team’s division, whether the project will include internal or external resources, the relevant champion who should review their initiative, and other details. Within this initial form, different scenarios will trigger different review parameters and requirements, for example, when a team intends to publish a tool externally or engage with sensitive use cases.
• Release assessment: After the system registration is complete, the team initiates the release assessment, a much more thorough review designed to ensure the AI-powered solution is ready to go live. At this point, the engineering team needs to provide detailed documentation. That includes the volume and kinds of data the system will use, potential harms and mitigations, and more. A release assessment includes experts in our Office of Responsible AI, Security, Privacy, and other teams, who review sensitive use cases or initiatives that include generative AI.

If the project clears all the requirements and reviews, it’s ready to go live. Crucially, we don’t think of these stages as a set of hurdles teams need to clear to complete their projects. Instead, the process guides engineering teams through the design elements they need to consider and provides opportunities for feedback from subject matter experts.

“The tool captures all the requirements from ORA and incorporates them into a developer-friendly workflow,” says Padmanabha Reddy Madhu, principal software engineer and responsible AI champion for Employee Productivity Engineering in Microsoft Digital. “It’s also a great way to pull AI champions into the design phase so we can support our colleagues’ work.”

With more than 80 AI projects currently underway across Microsoft Digital, logging and streamlining are essential. Teams are working on all kinds of ways to boost enterprise processes and employee experiences, like the following examples from Campus Services that users can access through our Employee Self-Service Agent:

• A facilities agent helps employees take action when they discover an issue at one of our buildings, like a burnt-out light, a spill, or physical damage. The agent creates a ticket to alert a Facilities team so they can resolve it and allows the submitter to follow up on progress.
• A campus event agent makes onsite gatherings like talks and Microsoft Garage build-a-thons more discoverable through simple queries. Using this agent, employees can more easily discover and plan around events that interest them, adding value to the in-person experience and incentivizing community.
• A dining agent addresses the challenges of multiple on-campus restaurants featuring menu options that shift daily. Employees can use natural language queries like “Where can I get teriyaki today?” The agent does the rest. This kind of agent can be especially helpful for employees with allergies or dietary restrictions, providing a boost to accessibility for the on-campus dining experience.

“AI is rapidly becoming a standard part of how we build and operate. As adoption accelerates, Responsible AI becomes imperative and enables teams to innovate at speed while maintaining safety and accountability at scale.”

Qingsu Wu, principal group product manager, Microsoft Digital

Our policies and practices have embedded a culture of responsibility and trust into our internal AI development processes. With that trust comes the confidence to experiment.

“AI is rapidly becoming a standard part of how we build and operate,” says Qingsu Wu, principal group product manager in Microsoft Digital. “As adoption accelerates, Responsible AI becomes imperative and enables teams to innovate at speed while maintaining safety and accountability at scale. By embedding Responsible AI into our engineering practices, teams have the clarity and confidence they need to manage risk proactively and deliver value without compromising safety or trust.”

Far from thinking of responsible AI assessments as an administrative or policy burden that creates additional work, teams now recognize their benefits. They look at the process as an extra set of eyes from a trusted partner. By minimizing legal and compliance risks through our Responsible AI Council’s expertise, our teams save time and stress, and we avoid problems like delayed releases or rollbacks.

“What we’re doing is entirely novel in the tech world. Microsoft is really the lead learner here, and we have a passion for corporate citizenship that we’re embedding in our tools.”

Jamian Smith, principal product manager and co-lead, Microsoft Digital Responsible AI team, Microsoft Digital

Lessons learned: Embedding responsible AI into our development efforts

Throughout this process, we’ve learned lessons that will be helpful for other organizations just beginning their AI journeys:

• We empowered early adopters and enthusiasts as responsible AI champions. They act as anchors and resources for developers who use AI, so we made sure they had the knowledge and training they needed to unlock downstream value.
• Culture has been crucial to our success, especially our growth mindset and our focus on trust. Emphasizing these aspects of our company culture helped us embed responsible AI into core SDL processes and naturalize it on our engineering teams.
• Processes are one thing, and tooling is another. If your responsible AI assessment workflow isn’t attuned to your needs, simply building a review portal tool won’t get you the rest of the way. First, we thought about the process we needed to put in place to solidify responsible AI practices and support our teams’ work. Then we built a tool that supports those workflows as easily and seamlessly as possible.
• Accuracy is reliant on data, and data has a tendency to reflect the biases of the humans who organize it. It’s necessary to correct bias actively through introspection and testing.

“What we’re doing is entirely novel in the tech world,” says Jamian Smith, principal product manager and co-lead for Microsoft Digital’s Responsible AI team. “Microsoft is really the lead learner here, and we have a passion for corporate citizenship that we’re embedding in our tools.”

As your organization begins to experiment with its own AI projects, take these concrete steps to infuse responsibility into the solutions you create:

1. Establish a strong foundation based on core principles and standards that align with your organizational culture. The Microsoft Responsible AI Standard is a great place to start because it reflects our experience and the expertise we’ve built as AI technology leaders and providers.
2. Seek out the activators across your organization: people with a passion for AI, security, transparency, and other challenge areas, along with a willingness to learn and the ability to lead. Think about how to place them in both centralized and distributed positions.
3. With the rapidly evolving regulatory climate around AI, it’s crucial to have a broad understanding of compliance and continue to follow its developments. Involve dedicated regulatory, compliance, and legal professionals in researching and monitoring global standards while communicating that information to your organization, particularly through training and updates that help teams adapt new regulations into their core processes.
4. Create a process for responsible AI assessment. Consider ways to break it into stages that propel projects forward rather than hindering them. Enlist the right people to assess projects, and consider tooling that streamlines actions for both creators and assessors. Our AI Impact Assessment Guide can help you get started.
5. Benefit from pioneers in the space, including our experts at Microsoft. Our journey has produced ready-to-use resources that can accelerate your progress. Examples include our Responsible AI Toolbox for GitHub, hands-on tools for building effective human-AI experiences, and our AI Impact Assessment Template.

“It’s not about how fast you can move, but how prepared you are. Responsible AI processes might seem like speed bumps, but ultimately they’re accelerators.”

Naval Tripathi, principal engineering manager and co-lead, Microsoft Digital Responsible AI Team

Building your capacity to create AI tools responsibly won’t happen without careful planning and strategy. As part of that process, embed responsible AI into your development workflows by emulating the practices we’ve pioneered at Microsoft.

“It’s not about how fast you can move, but how prepared you are,” Tripathi says. “Responsible AI processes might seem like speed bumps, but ultimately they’re accelerators.”

By prioritizing responsible AI, businesses of all kinds, all over the world, can ensure that the AI revolution is a truly human movement.

Key takeaways

These insights can help you as you begin your own journey through responsible AI:

• Realize that this isn’t just a technical transition. It’s also a gradual evolution and an ongoing journey.
• Work with people across your organization to establish goals and standards, because different disciplines bring different expertise and insights to the table. This will also align your responsible AI standards with your organizational values.
• Start with the basics and build from there. Establish principles, create processes, and construct tooling around those structures.
• A wide array of tooling is readily available in the world of AI. Seek out providers that model responsible values.
• Lean on your existing experts across privacy, security, accountability, and compliance. Their skills will be crucial in this new technological landscape.
• Conducting your own responsible AI groundwork is crucial, but you can also partner with Microsoft. We run on trust, and we’ve thought about these issues to pave the way for your success. Follow our lead, consider the best ways to adapt our lessons to your organization, and come to us with questions.

Try it out

Learn more about our responsible AI principles here at Microsoft.

Related links

• See how we’re responding to the AI revolution with an AI Center of Excellence.
• Learn how a data council is powering our unified data strategy at Microsoft.
• Read our guide to becoming a Frontier Firm in the age of AI.
• Explore ways that we’re accelerating employee support with our new Employee Self-Service Agent.

The post Responsible AI: Why it matters and how we’re infusing it into our internal AI projects at Microsoft appeared first on Inside Track Blog.

Learn from our experience

Network isolation (Secure Future Initiative)

“Knowing where devices are, who owns them, and what they’re supposed to be doing is pretty important in the middle of an incident,” Belknap says.

Key takeaways

Here are best practices you can use to secure your network:

• Build a complete inventory. Keep track of what your network devices are, who owns them, and what they do.
• Capture robust telemetry. Make sure your operational teams have the tools they need to see and analyze access and authentication logs.
• Use dynamic access control. Manage who can send packets on the corporate network by applying policies.
• Deprecate old network assets. Cyberattackers know to look for older, unpatched network devices. You can reduce the attack surface by replacing older devices.

Try it out

• Find at-risk devices with device inventory in Microsoft Defender for Endpoint.
• Learn how to apply managed identity best practices in Azure.

Related links

• Read about how to apply Azure network security in a Zero Trust approach to security.
• Discover the key network security capabilities in Azure.
• Explore how Microsoft online services secure the network boundary.
• View security principles and guidance on establishing related network security controls.

We’d like to hear from you!

• Want more information? Email us and include a link to this story and we’ll get back to you.

The post Microsoft CISO advice: Read our four tips for securing your network appeared first on Inside Track Blog.

“The path attackers really like to use is to compromise support tooling and laterally move to your core tooling,” says Raji Dani, Deputy Chief Information Security Officer (CISO) for Microsoft business operations.

Learn from our experience

The importance of hardening customer support tools against cyberattacks

Dani and her team focus on understanding and mitigating the risks within customer support operations. In this video, she shares principles and practices for every business that relies on online tools in their customer support ecosystem.

Key takeaways

Here are best practices you can apply to your customer support ecosystem:

• Create dedicated and isolated support identities. Use standardized support identities with phish-resistant multifactor authentication based in a separate identity ecosystem.
• Implement least privilege and enforce device protection. Only grant the access needed for a given task and nothing more.
• Ensure tooling does not have high privilege access to customer data. Architect secure tools and manage service-to-service trust and high privileged access.
• Implement strong telemetry. Anomalous patterns in logs and telemetry data are often the first clue a cyberattack is underway.

Try it out

Discover how to start applying Zero Trust practices to protect your customer support ecosystem.

Related links

• Explore more approaches for eliminating high-privilege access to enhance security.
• Review logging and threat detection capabilities.
• Find out more about phishing-resistant multifactor authentication.
• Read how we’re improving security by protecting elevated-privilege accounts at Microsoft.
• Check out how to use role-based access control to manage endpoint access.

We’d like to hear from you!

• Want more information? Email us and include a link to this story and we’ll get back to you.

The post Microsoft CISO advice: Explore our four tips for securing your customer support ecosystem 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.

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.

We’d like to hear from you!

• Want more information? Email us and include a link to this story and we’ll get back to you.

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