Strengthening Semiconductor Supply Chain Trust with Microsoft’s Artifact Signing and Transparency
As enterprises expand their use of Confidential Computing in the cloud and in AI infrastructure, the security of the underlying hardware is more critical than ever. Organizations and their customers need confidence not only in the software they deploy, but also in the silicon and firmware executing their most sensitive workloads. AMD and Microsoft are collaborating to demonstrate how signing and transparency can strengthen trust in the semiconductor supply chain. By combining AMD Device Provenance with Microsoft’s Artifact Signing and Signing Transparency, we are exploring how device provenance, signing, and transparency could work together to support independently verifiable hardware evidence. Why Hardware Provenance Needs Transparency Provenance evidence is most useful when it can be independently verified and evaluated alongside related supply chain evidence. Semiconductor manufacturers generate evidence across selected manufacturing and lifecycle stages, which may describe relevant device attributes, manufacturing events, and validation activities. A digitally signed record establishes who issued information and its integrity. Individual signatures alone do not provide a durable and independently verifiable record of the order in which they were issued, whether they were recorded consistently, or whether unexpected activity occurred in the interval. Transparency addresses this gap. Microsoft's Signing Transparency leverages confidential computing to create a verified, tamper-evident record of signing events, allowing customers and auditors to confirm that evidence was recorded and has not been silently changed or been removed. It applies the Zero Trust principle of “trust but Verify” by giving relying parties cryptographic proof they can evaluate directly. Extending Transparency from Software to Silicon Microsoft's Signing Transparency was designed to address software supply chain threats that traditional code signing alone cannot fully prevent. The same principles can be applied to firmware, hardware provenance, and other evidence generated across the physical supply chain. AMD Device Provenance is designed to provide visibility into the manufacturing and lifecycle of data center components. Through our collaboration, AMD and Microsoft are demonstrating how this evidence can be signed, made transparent, and independently validated. This approach provides several important benefits: Transparent provenance: Changes to signed hardware evidence can be detected rather than silently accepted. Independent validation: Customers can independently validate the integrity, signing history, and transparency records associated with provenance evidence while still applying their own trust requirements to the evidence issuer. Stronger accountability: Transparency creates a durable record of signing events, providing evidence that can help identify unexpected patterns or unauthorized signatures. Audit and compliance evidence: Verifiable records may help inform supplier assessments, regulatory inquiries, and internal due diligence. Standards-based portability: Evidence can be validated across organizational boundaries using interoperable IETF specifications, including RFC 9943, An Architecture for Trustworthy and Transparent Digital Supply Chains, RFC 9942, CBOR Object Signing and Encryption Receipts, and RFC 9995, CBOR Object Signing and Encryption Hash Envelope, rather than proprietary trust mechanisms. Together, these capabilities allow relying parties to verify the origin, integrity, registration, and device binding of manufacturer-issued provenance evidence. Learn More at OCP Global Summit At OCP Global Summit 2026, AMD and Microsoft will present a proof-of-concept demonstration that prototypes how these components could operate together. Visit the AMD (#C61) booth to see the demonstration and learn how AMD and Microsoft are advancing semiconductor supply chain security. To dive deeper into the demo details read AMD’s blog Advancing Semiconductor Supply Chain Assurance. Organizations interested in applying Artifact Signing and Signing Transparency to software, firmware, or hardware can also join the Artifact Signing with Signing Transparency preview community to learn more and help shape the future of the service.
The Microsoft AI and Agent Platform — Securing and Governing Intelligent Agents
In Part 1, we explored the intelligence side of the Microsoft AI and Agent Platform: how agents understand work, reason over trusted context, use models and tools, and operate across experiences such as Microsoft 365 Copilot, Copilot Studio, Microsoft Foundry, Dynamics 365, GitHub, and custom applications. But intelligence is only half the equation. As agents move from answering questions to taking action, the security model changes. Agents can retrieve sensitive data, call APIs, invoke tools, trigger workflows, collaborate with other agents, remember context, and act with delegated or assigned authority. That creates a new enterprise requirement: agents must be not only useful, but also governable, observable, contained, policy-driven, auditable, and aligned with organizational risk boundaries. The core question for enterprise AI is no longer only, “Can the agent reason?” It is also, “Can we trust what it can access, what it can do, how it is governed, and whether we can prove what happened?” That is the focus of Part 2: Trust—showing where security, governance, assurance, isolation, posture management, and security operations apply across the agent lifecycle. The mental model: The left side presents the seven platform layers, while the foundation establishes security across the architecture. On the right, scoped control rails apply targeted governance through Microsoft commercial controls and open-source specifications, with each control operating within its defined scope. Trust is not a feature. It is a platform property. Many early AI security conversations focused narrowly on prompts: prompt injection, jailbreaks, harmful content, and model outputs. Those risks remain important, but agentic systems broaden the attack surface. An enterprise agent is not just a model endpoint. It is a system composed of: User and application interaction channels. Foundation and custom models. Agent orchestration and reasoning. MCP servers, APIs, tools, skills, and connectors. RAG pipelines and enterprise knowledge sources. Short-term and long-term memory. Identity and access controls. Runtime environments, containers, cloud PCs, and networks. Monitoring, audit, compliance, and security operations. Trust must therefore be applied across every layer. A secured agent platform needs controls before the model call, during reasoning, before and after tool execution, at data retrieval time, during output generation, and throughout runtime operation. That is why the Microsoft Security for AI Platform is best understood as an end-to-end security architecture for the AI application and agent lifecycle. The diagram follows the path from interaction channels, through the agent and grounding layers, into build and runtime environments, and finally into security operations. The new security boundary: from applications to agents Traditional application security assumes relatively deterministic behavior: users click buttons, applications call APIs, authorization checks enforce access, and logs record the result. Agentic systems introduce more dynamic behavior. An agent may interpret a goal, decompose it into tasks, choose tools, retrieve context, call APIs, invoke another agent, generate code, operate a browser, or take action through a workflow. That flexibility is where business value comes from, but it also means controls must cover more than static application paths. A secure AI platform must answer several questions: Trust question Why it matters Who is the user and who is the agent? Agents need identity, permissions, ownership, lifecycle, and accountability. What data can the agent retrieve? RAG and grounding can expose overshared or sensitive enterprise data. What tools can the agent use? APIs, MCP servers, connectors, and skills become action surfaces. When does a human need to approve? High-impact actions require explicit approval and evidence. Where does the agent run? Runtime isolation matters when agents execute code, use browsers, or automate legacy apps. What happened? Security teams need traces, logs, detections, investigations, and audit records. How do we govern at scale? Enterprises need policy, posture management, compliance, and lifecycle controls across thousands of agents. Microsoft’s approach is to apply a consistent trust foundation across the same layers that deliver intelligence: interaction channels, AI applications and agents, data and context, build platforms, runtime infrastructure, and security operations. 1. Secure the AI interaction channels Agents enter the enterprise through many channels: Microsoft 365 Copilot, Teams, SharePoint, Office, Dynamics 365, custom portals, APIs, MCP endpoints, web experiences, and developer tools. Each channel has a different risk profile. Microsoft 365 Copilot and business application experiences inherit enterprise identity, compliance, and data protection controls from Microsoft 365, Microsoft Entra, Microsoft Purview, and Microsoft Defender. Custom apps, web apps, and API-driven experiences require the same rigor: authentication, authorization, network controls, input validation, logging, monitoring, and response. For developer tools, GitHub Advanced Security, Microsoft Defender for DevOps, Microsoft Defender for Cloud, and Microsoft Security Copilot help protect the software supply chain behind AI applications. Agent systems often depend on code, prompts, infrastructure-as-code, container images, packages, actions, connectors, and deployment pipelines. Those assets need the same scanning, secret detection, dependency governance, and posture management expected of any production system. For APIs and MCP servers, Azure API Management, Microsoft Defender for APIs, Microsoft Entra, Conditional Access, Private Link, and network controls become especially important. Agent tool use should be explicit, least privileged, monitored, and policy governed. Microsoft Defender for Cloud Apps also plays an important role across interaction channels by helping organizations discover and govern SaaS usage, manage OAuth app risk, apply session controls, and understand shadow AI exposure across the enterprise. 2. Secure the AI application and agent layer The AI application and agent layer is where models, agents, MCP, skills, hooks, RAG, memory, and orchestration come together. This layer sets agent security apart because agents do more than process requests, they reason, make decisions, and take action. Agent harness and the agent loop An agent harness is the runtime scaffolding that turns model reasoning into a stateful agent workflow. It assembles instructions and context, coordinates model and tool calls through the agent loop, maintains session state, and applies configured approvals and observability. Because the harness mediates these interactions, it is a natural integration point for policy controls: Agent Hooks defines standardized interception points, while the Agent Control Specification (ACS) evaluates policy at those points and returns decisions for the host to enforce. The harness is not an execution-isolation boundary; tools and code may run in separate containers, sandboxes, Cloud PCs, or hosted environments that require their own security controls. Models Foundation and custom models should be governed through approved model catalogs, deployment policies, evaluation pipelines, content safety controls, and monitoring. Microsoft Foundry provides a governed environment for model selection, evaluation, deployment, and operations. Model choice should be treated as a policy decision, not an uncontrolled developer preference. Different workloads may require different tradeoffs across cost, latency, quality, data handling, region, safety, and compliance. Enterprises need visibility into which models are used, for which workloads, and under which controls. Azure AI Content Safety, available through Microsoft Foundry capabilities, helps protect AI applications from harmful content, prompt attacks, jailbreak attempts, unsafe outputs, and other content risks. Content safety should be treated as part of the AI control plane, not a bolt-on filter at the edge. Agents Agents need their own lifecycle: discovery, ownership, identity, permissions, classification, monitoring, and retirement. Agent 365 helps organizations discover, inventory, govern, and enforce policies across their agent estate, preventing it from becoming an unmanaged shadow application layer. This matters because agent sprawl can become the next application sprawl. Without inventory and governance, organizations may not know which agents exist, who owns them, what data they access, what tools they can invoke, or whether they are still needed. Microsoft Purview complements this by helping protect and govern the data agents use, including sensitivity labels, data loss prevention, audit, compliance, and data security posture management for AI scenarios. Microsoft Entra provides the identity fabric for users, apps, agents, and workloads, helping ensure that agent actions are tied to explicit identities and least-privilege access. MCP, APIs, tools, and skills The Model Context Protocol and tool-based agent architectures are powerful because they let agents connect to systems of record, business applications, knowledge stores, and automation surfaces. They are also high-value control points. Every tool is effectively a capability grant. A read-only knowledge tool, a refund API, a database query tool, a ticketing connector, a browser automation tool, and a code execution tool carry very different risk. Tool authorization should be granular, contextual, and auditable. Key controls include: Tool allowlisting and approval workflows. Least-privilege API permissions. Strong authentication through Microsoft Entra. Managed identities and workload identities for secretless access. API inspection and protection with Azure API Management and Defender for APIs. Network isolation with Private Link, Azure Firewall, WAF, and DDoS Protection. Runtime isolation with containers, Microsoft eXecution Container (MXC), Windows 365 for Agents, and confidential computing where needed. Monitoring and detection through Microsoft Defender, Microsoft Sentinel, and Azure Monitor. Agent Hooks and policy gates Because the harness coordinates the agent loop, it provides a natural host-level seam for policy enforcement. Agent Hooks defines a framework-neutral interception contract across agent input, model calls, tool calls, and output. ACS can evaluate policy at those interception points, while the conforming host applies the resulting allow, deny, transform, or approval decision. Traditional framework callbacks are often designed for observability, not governance. They may observe events but not reliably block actions, transform content, bind approvals, or produce enforceable evidence. Agent Hooks introduces a framework-neutral governance contract for AI agents with defined interception points across the lifecycle, including startup, input, model calls, tool calls, output, and shutdown. Agent Hooks and the Agent Control Specification are open, design-partner-informed control contracts for agent hosts and frameworks. They define where policy decisions can be requested and what obligations a conformant host has when a verdict requires blocking, approval, transformation, or record generation. If a policy denies a tool call, the tool should not execute. If a post-tool response is denied, it should not enter agent state. If approval is required, the approval should bind to the exact action and content that was reviewed, not loosely to a session. Agent Hooks complements, but does not replace, runtime isolation. It helps govern cooperative agent host; it does not sandbox the host, tools, or untrusted code. It therefore works alongside the Agent Control Specification, Microsoft Foundry control plane, Agent 365, Microsoft Agent Framework, Microsoft eXecution Container (MXC), and Windows 365 for Agents to combine policy governance with secure execution. RAG and knowledge grounding Agents become more useful when they can ground reasoning in enterprise and external context. But grounding also expands the agent’s trust boundary by introducing additional data sources, retrieval paths, indexes, and content into the reasoning process. Securing and governing these grounding sources is addressed in the next section as part of the data and context layer. 3. Govern data and context The data and context layer is where enterprise knowledge becomes available to AI applications and agents and where existing data-security and governance boundaries must continue to hold. Agents may ground their reasoning across enterprise data, Work IQ, Fabric IQ, Foundry IQ, Web IQ, Azure AI Search, Microsoft Graph, and other organizational knowledge sources. These sources can provide valuable context, but each introduces its own authorization model, data boundary, retrieval path, and governance requirements. Trust therefore depends not simply on connecting agents to more information, but on ensuring that grounding does not create a new path around the controls protecting that information. Securing grounding starts with identity and authorization. Retrieval should preserve the permissions of the underlying source wherever supported and ensure that users, agents, applications, and workload identities can access only the information required for the task. Microsoft 365 Copilot respects Microsoft 365 user permissions and supported Microsoft Purview protections; other grounding architectures require source-specific configuration and validation. Access through Microsoft Graph, Azure AI Search, Microsoft Fabric, Microsoft Foundry, or other retrieval mechanisms should similarly be designed around explicit identities, least privilege, and the authorization boundaries of the underlying data. Data protection must extend through the grounding pipeline. Sensitive information can exist not only in source documents and databases, but also in indexes, retrieved passages, embeddings, prompts, agent memory, model responses, logs, and downstream actions. Applicable sensitivity labels, information protection, DLP, retention, audit, encryption, and compliance controls should therefore be considered across the complete flow of grounded information rather than only at the original data source. Grounding also introduces risks that traditional access control alone does not address. Overshared content can become overshared AI context; stale or low-quality information can influence agent decisions; compromised or untrusted sources can introduce poisoned content; and instructions embedded in retrieved content can attempt to manipulate agent behavior through indirect prompt injection. Organizations should therefore govern which sources can be used for grounding, validate the trustworthiness and freshness of those sources, protect retrieval and indexing pipelines, and apply appropriate evaluation, monitoring, and content-safety controls. For retrieval-based architectures, indexes and knowledge stores should be treated as governed enterprise assets. Organizations should understand what information is indexed, where it originated, how frequently it is refreshed, which identities can query it, how access controls are enforced, and whether retrieved content can cross security or data boundaries. Retrieval relevance alone is not sufficient; the retrieval path must also preserve the security intent of the source system. This is particularly important for Microsoft 365 grounding. Microsoft Purview helps protect and govern sensitive information through capabilities such as information protection, DLP, audit, retention, compliance, and data security posture management. Microsoft Entra provides identity and access controls for users, applications, agents, and workloads. SharePoint Advanced Management can help organizations address oversharing and content-governance risks in the SharePoint estate used by Microsoft 365 Copilot and agents. Other grounding environments require equivalent controls appropriate to their data sources, identities, retrieval architecture, and runtime. The same principles apply across Work IQ, Fabric IQ, Foundry IQ, Web IQ, enterprise data, Azure AI Search, and Microsoft Graph, but the controls should not be assumed to operate identically across them. Their integration models, permissions, governance capabilities, and maturity differ. Organizations should validate the security boundary of each grounding source and explicitly determine how identity, authorization, data protection, retrieval, monitoring, and audit requirements are enforced for that implementation. A trusted grounding architecture should therefore answer several questions: Who or what is requesting the information? Is that identity authorized to retrieve it? Is the source approved and trusted for grounding? Does retrieval preserve the source system's access boundaries? Is sensitive information protected throughout retrieval, indexing, reasoning, memory, and output? Can retrieved content introduce malicious or untrusted instructions into the agent? Are indexes and knowledge stores governed, current, and appropriately isolated? Can organizations observe and audit how grounded information is being accessed and used? The principle is straightforward: grounding should extend enterprise context to agents without weakening the identity, security, privacy, and governance boundaries of the underlying information. A trusted agent should retrieve not simply the most relevant information, but the right information, from trusted sources, through authorized paths, under controls the organization can govern and audit. 4. Secure the build continuum: no-code, low-code, and pro-code Microsoft’s platform supports multiple build paths: Agent Builder for no-code creation, Copilot Studio for low-code agents and orchestration, and Microsoft Foundry for pro-code AI systems. AI solutions can cross boundaries, and security must travel across that continuum. Build path Primary audience Trust requirements Microsoft capabilities Guided/ No-code Business users and teams Agent discovery, ownership, sharing controls, data governance, policy enforcement Microsoft Agent 365, Microsoft Purview, Microsoft Entra, Microsoft Defender Managed/ Low code Makers, process owners, business technologists Connector governance, environment strategy, DLP, approvals, lifecycle management Copilot Studio, Power Platform DLP, Managed Environments, Entra, Purview, Agent 365 Code-first/Custom Developers and platform teams Secure SDLC, evaluations, red teaming, DevSecOps, runtime isolation, observability Microsoft Foundry, GitHub Advanced Security, Defender for DevOps, Defender for Cloud, Azure Monitor No-code: Agent Builder No-code agents make AI creation accessible to more users, which increases business agility and helps organizations bring AI into the flow of work. The trust requirement is to make that creation visible and governable without removing the simplicity that makes no-code valuable. Microsoft Agent 365 helps provide agent discovery, inventory, lifecycle management, policy enforcement, and governance across the agent estate. Microsoft Purview helps ensure that the data used by these agents remains protected by sensitivity labels, DLP, audit, and compliance controls. Microsoft Entra helps enforce identity, access, and least privilege. Together, these capabilities allow organizations to empower business users while maintaining enterprise trust. Low code: Copilot Studio Copilot Studio brings orchestration, connectors, workflows, and extensibility. That makes Power Platform governance important because low-code agents often sit close to real business processes and enterprise data. Power Platform DLP policies, Managed Environments, environment strategy, connector governance, solution lifecycle management, maker and admin roles, and approval patterns for sensitive actions are the mechanisms that turn low-code agility into trusted enterprise automation. These controls help organizations decide which connectors can be used together, which environments are appropriate for development and production, who can build and publish agents, how solutions move through lifecycle stages, and when human approval is required before action is taken. Low-code agents need both business speed and enterprise control. Trust is what allows organizations to scale low-code innovation beyond isolated pilots. Pro-code: Microsoft Foundry Pro-code agent systems demand rigorous software engineering: secure architecture and coding, dependency governance, CI/CD safeguards, container security, infrastructure-as-code scanning, environment isolation, observability, evaluation, and incident response. GitHub Advanced Security and Microsoft Defender for DevOps are central to this approach. GitHub Advanced Security supports code and secret scanning, dependency review, and software supply-chain protection. Defender for DevOps brings these findings into Microsoft Defender for Cloud, giving security teams a unified view of AI application, cloud, and workload risks. AI-specific assurance should also be embedded in the development lifecycle. Open-source tools such as PyRIT, RAMPART, ASSERT, and the Agent Governance Toolkit support red teaming, behavioral evaluation, governance evidence, and regression testing. Open specifications such as Agent Hooks and the Agent Control Specification establish interoperable control patterns across agent hosts and frameworks. These open-source tools give organizations transparent, extensible ways to test and standardize AI security across heterogeneous environments. For enterprises using multiple frameworks, models, clouds, APIs, and orchestration approaches, PyRIT, RAMPART, ASSERT, and the Agent Governance Toolkit provide practical methods to red-team, evaluate, govern, and validate systems. Agent Hooks and the Agent Control Specification complement them with a common language for integrating controls at the host level. Microsoft commercial solutions operationalize these controls at enterprise scale. Microsoft Agent 365, Microsoft Foundry, Microsoft Entra, Microsoft Purview, Microsoft Defender, Microsoft Sentinel, Microsoft Security Copilot, GitHub Advanced Security, and Azure infrastructure services provide the inventory, policy enforcement, data governance, monitoring, detection, response, compliance, and operational capabilities required for production environments. The roles are complementary: open-source tools promote transparency, interoperability, and technical assurance, while commercial solutions provide enterprise control planes, integrated operations, support, and scale. Together, they help customers and partners secure AI systems from experimentation through production. 5. Secure runtime, isolation, and execution Once agents are built, they need somewhere to run. The runtime layer determines how agents are isolated, monitored, scaled, and connected. Key runtime and infrastructure components include Microsoft Foundry, Azure AI Search, Azure Confidential Computing, Azure Kubernetes Service, Azure Container Apps, Azure Functions, Azure Private Link, Storage, Azure Firewall, WAF, DDoS Protection, Azure Monitor, Azure Policy, Windows 365 for Agents, and Microsoft eXecution Container (MXC). AI applications and agents need more than access to a model. They require secure infrastructure to host orchestration, retrieve knowledge, execute tools, process files, automate workflows, connect privately to enterprise systems, maintain state, enforce policy, and capture telemetry. This foundation turns prototypes into resilient, governable production systems. Strong infrastructure controls are especially important because agents may execute code, invoke tools, operate browsers, process files, and interact with systems that were not designed for autonomous actors. Microsoft eXecution Container (MXC) and Windows 365 for Agents are especially important for secure execution. Microsoft eXecution Container (MXC) – (in early preview now) is a sandboxed code-execution capability designed to provide isolated execution environments for agent actions and code. Windows 365 for Agents provides managed Cloud PC environments for agents that need to interact with desktop applications, browsers, or legacy systems that do not expose APIs. Azure Confidential Computing can help protect sensitive workloads in use. Azure Private Link keeps traffic private. Azure Policy enforces guardrails. Azure Monitor and Application Insights provide telemetry. Azure Key Vault and Managed HSM protect secrets and keys. Managed identities and Microsoft Entra Workload ID reduce the need for long-lived secrets. Azure Container Registry and Defender for Containers help protect image-based agent workloads. As agent autonomy and tool access increase, runtime isolation, oversight, and monitoring must strengthen accordingly. 6. Manage runtime security posture Runtime security posture provides a continuous view of whether AI applications, agents, tools, and infrastructure remain within expected security boundaries. Layer 5 defines where and how agents run; Layer 6 assesses whether those environments are hardened, observable, compliant, and improving over time. For agentic systems, posture management must combine traditional cloud controls with AI-specific oversight. Security teams need visibility into AI services, agent workloads, containers, APIs, model endpoints, grounding stores, identities, secrets, and network paths. They must also identify public exposure, missing telemetry, excessive permissions, vulnerable images or packages, unprotected data stores, and access to unapproved tools or data sources. Microsoft Defender for Cloud anchors this layer. Cloud Security Posture Management identifies misconfigurations, excessive permissions, exposed resources, weak network paths, encryption gaps, and compliance issues across cloud workloads. Defender for Containers extends that visibility to images, registries, clusters, and runtime risks. Defender for AI services threat protection and AI Security Posture Management add AI-specific discovery and protection, surface risky configurations, and connect those findings to broader cloud and workload risk. Effective runtime posture also requires identity and data context. Microsoft Entra, managed identities, Entra Workload ID, Conditional Access, and Privileged Identity Management help reduce standing privilege and reliance on secrets. Microsoft Purview adds sensitivity, DLP, audit, retention, compliance, and data-security posture signals. Agent 365 and Microsoft Foundry add context about agent inventory, ownership, evaluations, guardrails, model endpoints, and lifecycle state. The goal is not to generate more recommendations, but to prioritize the risks that matter most in production: exposed agent endpoints, unmanaged MCP tools or APIs, overprivileged workload identities, vulnerable containers, missing telemetry, unprotected secrets, overshared grounding data, noncompliant model deployments, and runtime environments that do not match an agent’s autonomy. These posture signals should flow into security operations. Defender XDR, Microsoft Sentinel, Microsoft Security Exposure Management, and Security Copilot can combine posture, exposure, detection, and audit data to help defenders investigate agent behavior, trace attack paths, and coordinate response. This connects build-time assurance, runtime isolation, continuous posture management, and security operations. 7. Operationalize AI security across the Microsoft Platform AI security must extend beyond design and deployment into continuous operations. As agents move into production, organizations need to connect agent and application governance, identity, data security, cloud and workload protection, exposure management, detection, investigation, and response so agent activity can be understood and governed in the context of the broader enterprise environment. Microsoft provides complementary control planes across this operating model. Microsoft Agent 365 and Microsoft Foundry Control Plane help govern the agent estate and AI platform; Copilot Studio and Power Platform governance provide environment, connector, and DLP controls for low-code agents and applications; Microsoft Entra governs identity and access; Microsoft Purview protects and governs data; and Microsoft Defender, Microsoft Security Exposure Management, Microsoft Sentinel, and Microsoft Security Copilot extend protection, exposure management, detection, investigation, and response across the environment. Microsoft Security provides an integrated operating model across these domains: Security capability Microsoft solutions Agent and application governance Microsoft Agent 365, Microsoft Foundry Control Plane, Copilot Studio and Power Platform governance, Managed Environments, Power Platform DLP Identity and access security Microsoft Entra, Conditional Access, Identity Protection, Privileged Identity Management, Workload ID, Agent ID Data security and compliance Microsoft Purview, Data Security Posture Management, Information Protection, DLP, Audit, eDiscovery Cloud, workload, and AI protection Microsoft Defender for Cloud, Defender CSPM and AI security posture management, Defender for AI Services, Defender for Containers Endpoint and user protection Microsoft Defender XDR, Defender for Endpoint, Microsoft Intune API and application protection Azure API Management, Defender for APIs, Defender for Cloud Apps Exposure management Microsoft Security Exposure Management, Defender External Attack Surface Management Security operations Microsoft Defender XDR, Microsoft Sentinel DevSecOps and software assurance GitHub Code Security, GitHub Secret Protection, Defender for DevOps, MDASH Secrets and network protection Azure Key Vault, Managed HSM, Azure Firewall, WAF, DDoS Protection, Private Link, Global Secure Access For agentic systems, this connected view is especially important. An agent may authenticate with one identity, retrieve sensitive data from another system, invoke APIs or MCP tools, execute code in a runtime, and take action in a business application. Security operations therefore need to correlate relevant identity, data, application, API, cloud, endpoint, workload, and agent signals rather than assess each component in isolation. Posture, exposure, telemetry, detections, and audit signals can then help defenders understand suspicious agent activity in context—for example, an over-permissioned identity, exposed API, vulnerable runtime, unusual data access, or anomalous agent behavior. The goal is not to create a separate security operations model for AI, but to extend existing enterprise security operations to AI applications and agents. Defend with AI Trust also means moving from defending AI to defending with AI. Microsoft is applying AI across security operations, software assurance, and proactive threat discovery to help defenders identify risk, investigate threats, and accelerate response. Microsoft Security Copilot augments security teams with AI-assisted investigation, incident summarization, signal correlation, query generation, and response workflows. Codename MDASH, currently in preview, is Microsoft’s multi-model agentic scanning harness, an agentic code scanner in Microsoft Defender that coordinates specialized agents and models to discover, validate, and help remediate source-code vulnerabilities. Project Perception, currently in limited preview, coordinates red, blue, and green team agents to uncover weaknesses, investigate threats, and recommend or perform approved remediation. Together, these capabilities demonstrate the next evolution of security operations: using security to protect AI while using AI to strengthen security combining human expertise with AI-assisted and agentic defense across prevention, exposure management, detection, investigation, and response. Apply security foundations across every layer Security foundations provide consistent principles that underpin trust across the AI and agent lifecycle. Zero Trust, encryption, observability, continuous monitoring, Responsible AI, and governance become actionable when they are applied as concrete controls across identity, data, applications, agents, tools, grounding, and runtime environments. Zero Trust: Verify explicitly, enforce least privilege, and assume breach across user, agent, workload, tool, data, and runtime access. Encryption: Protect prompts, responses, grounding data, memory, logs, and tool payloads at rest, in transit, and where supported, in use. Observability and logging: Capture relevant agent activity including tool calls, data access, policy decisions, approvals, errors, and outcomes with appropriate privacy controls. Responsible AI and governance: Evaluate agents for safety, reliability, privacy, security, transparency, and accountability before and after deployment. Continuous monitoring: Monitor for drift, misuse, anomalous behavior, unexpected data access, and emerging threats as models, data, and tools change. Audit and accountability: Maintain evidence of who initiated an action, which agent acted, what resources were accessed, which controls were applied, and what outcome occurred. Privacy and data protection: Apply appropriate information protection, DLP, retention, audit, and compliance controls across prompts, grounding, memory, outputs, logs, and downstream actions. These controls must operate continuously across the agent lifecycle. As agents move from design and build through grounding, deployment, monitoring, and response, their models, data, tools, identities, permissions, and runtime environments will continue to change. Trust therefore cannot be established once at deployment; it must be continuously evaluated, governed, monitored, and improved as the agent and its operating environment evolve. The outcome: trusted autonomy Trust is not a constraint on AI transformation; it is what enables AI to scale responsibly across the enterprise. As organizations move from assistive copilots to increasingly autonomous agents and multi-agent systems, they need confidence that those systems operate within clear boundaries for identity, data access, tool use, execution, governance, and accountability. The goal is not to eliminate autonomy, but to make autonomy intentional, bounded, observable, and governable. Microsoft brings together AI platforms with identity, data security, application security, cloud and runtime protection, security operations, and open security tooling to help organizations establish these boundaries across the agent lifecycle. Rather than creating a separate security model for every agent, framework, runtime, or data source, organizations can apply a consistent trust architecture while adapting controls to the risk and autonomy of each scenario. This is trusted autonomy: enabling agents to reason and act with increasing independence while keeping their access, actions, and outcomes within enterprise-defined security and governance boundaries. Combining the intelligence that makes agents useful with trust that allows organizations to deploy them confidently at enterprise scale. Intelligence + Trust = Frontier Transformation.Post-Quantum Cryptography Comes to Windows Insiders and Linux
Introduction As the digital landscape continues to evolve, the emergence of quantum computing presents both significant opportunities and challenges. In previous blog posts, we discussed how quantum computing could disrupt contemporary cryptographic algorithms, Microsoft’s contributions to quantum safety efforts across the industry, and the addition of PQC algorithms to SymCrypt, our core cryptographic library. We are pleased to announce the next significant milestone in our PQC journey: We’re making PQC capabilities available for Windows Insiders, Canary Channel Build 27852 and higher, and Linux, SymCrypt-OpenSSL version 1.9.0. This advancement will enable customers to commence their exploration and experimentation of PQC within their operational environments. By obtaining early access to PQC capabilities, organizations can proactively assess the compatibility, performance, and integration of these novel algorithms alongside their existing security infrastructure. This practical approach helps security teams identify potential challenges, optimize implementation strategies, and enable an easier transition as industry standards evolve. Furthermore, early adoption will offer valuable insights into the ways in which PQC can help mitigate emerging threats, thereby positioning organizations to more effectively protect sensitive data against future quantum threats. What’s new in Windows Windows, being one of the most widely used operating systems globally, plays a crucial role in the digital ecosystem. Taking the addition of PQC algorithms to SymCrypt a step further, we’re excited to bring ML-KEM and ML-DSA to our Windows Insiders via updates to the Cryptography API: Next Generation (CNG) libraries and Certificate and Cryptographic messaging functions. Developers can begin experimenting with ML-KEM in scenarios where public key encapsulation or key exchange is desired, to help prepare for “harvest now, decrypt later” threat. The table below describes the parameter sets included in this update. We encourage customers to use a hybrid approach, using ML-KEM alongside existing algorithms (like ECDH or RSA) during transition for defense in depth, with preference for NIST security level 3 and above where possible, based on the need and threat model. Public (encapsulation) key size Ciphertext size Shared secret size NIST security level ML-KEM 512 800 bytes 768 bytes 32 bytes Level 1 ML-KEM 768 1184 bytes 1088 bytes 32 bytes Level 3 ML-KEM 1024 1568 bytes 1568 bytes 32 bytes Level 5 The addition of ML-DSA in Cryptography API: Next Generation (CNG) enables developers to begin experimenting with PQC algorithms for scenarios that require verification of identity, integrity or authenticity using digital signatures. We encourage customers to use a composite approach, using ML-DSA alongside existing algorithms (like ECDSA or RSA) during transition. Our preliminary analysis indicates that size and performance will have some impact. We encourage you to begin this analysis early to understand the effects on your environment and applications. Public key size Private key size Signature size NIST security level ML-DSA-44 1312bytes 2560 bytes 2420bytes Level 2 ML-DSA-65 1952 bytes 4032 bytes 3309 bytes Level 3 ML-DSA-87 2592 bytes 4896 bytes 4627 bytes Level 5 With PQC updates in wincrypt, the Windows certificate API surface, customers can experiment with installing, importing and exporting ML-DSA certificates to and from the certificate store. Customers can also experiment with validating PQ certificate chains and trust status. Visit our crypto developer's page to learn more about how you can get started. While the changes here correspond to the NIST standardized algorithms, we will continue to iterate and make updates as the standards evolve and what is required for quantum-resistant cryptography changes. What’s new in Linux As we progress in helping make PQC available to our Windows customers through CNG and SymCrypt, it is important to acknowledge that many of our Linux users are anticipating PQC updates in the SymCrypt provider for OpenSSL 3. This provider is a natural way for Linux programmers to use OpenSSL’s API surface powered by SymCrypt cryptographic operations. With version 1.9.0 of SymCrypt-OpenSSL, we are enabling customers to experiment with TLS hybrid key exchange as per the latest IETF internet draft, providing an early opportunity to help prepare for “harvest now, decrypt later” threats. Furthermore, this functionality empowers customers to conduct in-depth analysis of how integrating PQC algorithms in a hybrid mode impacts handshake message sizes, changes TLS handshake latency, and has effects on overall connection efficiency. Such investigations are crucial for understanding the operational trade-offs of adopting PQC, enabling informed decisions as organizations prepare for a future where quantum-resistant security becomes fundamental. It is important to note that these changes are based on draft specifications, and as the standards evolve, we will update the SymCrypt-OpenSSL implementation to enable interoperability and compliance. What’s coming next The integration of PQC into Windows Insiders and Linux marks an important first step in enabling our customers to explore PQC within their environments. This is just the beginning—more capabilities and enhancements are on the way. Alongside the addition of SLH-DSA to SymCrypt, CNG and SymCrypt-OpenSSL, we plan to incorporate further algorithms to enable continued compliance with global regulations, robust security, and broad compatibility as PQC standards mature. The PKI and certificate standards are gaining momentum within the LAMPS working group in IETF. We are collaborating with industry partners on X.509 standardizations concerning the general use of ML-DSA, composite ML-DSA, SLH-DSA, ML-KEM, composite ML-KEM and LMS/XMSS. These efforts will be relevant to various signature schemes and PKI use cases, including those used in firmware and software signing. The use of PQC algorithms to secure TLS communications is rapidly evolving. While we’ve introduced hybrid key exchange through SymCrypt-OpenSSL for Linux, we’re actively working to get this capability to our Windows customers via the Windows TLS stack (Schannel). We’re also collaborating with the IETF to develop and standardize quantum-safe authentication mechanisms including Composite ML-DSA, pure ML-DSA and SLH-DSA for TLS and other IETF protocols. As these standards are finalized, we will make them available through both the Windows TLS stack (Schannel), SymCrypt provider for OpenSSL and SymCrypt Rust Wrapper on Linux. It is important to note that TLS 1.3 will be a prerequisite for PQC, and we strongly advise customers to start transitioning from older TLS protocols if they have not already. For more information, see Taking Transport Layer Security (TLS) to the next level with TLS 1.3. Another area we’re actively working on is helping support PQC algorithms within Microsoft Active Directory Certificate Services (ADCS). This will enable customers configuring a Certification Authority (CA) to use a CA certificate based on PQC algorithms such as ML-DSA. Clients will be able to enroll for PQC end-entity certificates, and the Certificate Revocation Lists (CRLs) issued by the CA will be signed using PQC algorithms. Support will be extended across all relevant ADCS role services, including the Certificate Enrollment Policy (CEP) and Certificate Enrollment Services (CES), the Network Device Enrollment Service (NDES), and the Online Certificate Status Protocol (OCSP) responder. Microsoft Intune’s certificate delivery mechanism – the Certificate Connector – is being enhanced to help support PQC certificates as well, enabling mobile devices and endpoints can enroll and obtain quantum-safe credentials. Going forward, this connector will be updated to handle certificate requests and deliveries that use PQC keys and signatures, unblocking SCEP & PKCS #12 scenarios for on-premises CAs leveraging ADCS. These new capabilities will be introduced for experimentation through Windows Insiders and development channels, helping provide early access to organizations and individuals eager to test PQC features within real-world environments. By leveraging these preview channels, Microsoft can gather critical feedback on interoperability, security, and usability, allowing for iterative improvements before wide-scale release. As global standards for PQC continue to evolve, Microsoft remains committed to a flexible and adaptive deployment strategy. This approach allows that once standards are finalized, the more robust and interoperable solutions can be more easily brought to supported platform versions across both Windows and Linux ecosystems. Furthermore, collaboration with industry partners and standards bodies will help guarantee that emerging features align with broader ecosystem desires and global regulatory requirements, accelerating the journey toward quantum-safe security for organizations of all sizes. Future Perspectives and Challenges PQC algorithms are relatively new, and it is prudent not to consider the initial generation of PQC algorithms as the definitive solution but rather view this as an evolving field. This underscores the importance of "Crypto Agility" which involves designing solutions to be more resilient to the use of different algorithms and/or upgradable to use future algorithms as the PQ standards evolve. Recognizing this, Microsoft is a strong advocate of building solutions which are crypto agile, as well as deploying PQC solutions which make use of a hybrid PQ mode of operation. These hybrid modes, including TLS hybrid key exchange or composite certificates, use both a PQ algorithm and a traditional algorithm such as RSA or ECDHE. In time, we anticipate a shift towards pure PQ deployments, as PQ algorithms and standards mature. While the integration of PQC into Windows Insiders and Linux is an important milestone, several challenges remain. The performance of PQC algorithms, compatibility with existing systems, and the desire for widespread adoption are fundamental factors that will determine the success of this transition. Performance Considerations PQC algorithms often require more computational resources than their classical counterparts. Enabling these algorithms can be more efficiently implemented without significantly impacting system performance is a key challenge. Continuous optimization and hardware acceleration techniques are important to achieve a balance between security and performance. Many PQ algorithms, such as ML-KEM and ML-DSA, use Keccak (the basis for SHA-3, SHAKE, and related functions) for pseudo-random value generation and input integrity checks. As PQC adoption grows, improving Keccak performance—especially with hardware acceleration—will be key to efficient cryptography, reducing resource demands and helping boost security for post-quantum operations. When used in the TLS protocol, the larger sizes of PQC key encapsulation mechanisms and digital signatures, especially when used in a hybrid mode, may add to the round-trip time to establish and communicate over a secure network channel. Some IETF drafts are in progress that aim to help improve this, including TLS key share prediction for faster cipher suite negotiation and TLS certificate compression to reduce the size of certificates, but note that signatures cannot be compressed. We recommend that you assess the impact of these modifications on your environment and applications. Compatibility and Adoption The transition to PQC will require updating and replacing existing cryptographic infrastructure across various platforms and applications. Enabling compatibility with legacy systems and achieving widespread adoption will necessitate coordinated efforts among software developers, hardware manufacturers, and service providers. Education and awareness campaigns will also play an important role in encouraging organizations to embrace post-quantum cryptographic solutions along with compliance timelines set by governments globally. Conclusion The integration of PQC capabilities into Windows Insiders and Linux marks a significant step forward in preparing for the quantum era. Quantum computing has significant potential to help solve some of humanity's greatest challenges, and by proactively addressing the security concerns with current cryptographic standards, Microsoft is helping pave the way for a digital future that both realizes the benefits of quantum and mitigates the security risks. As quantum computing continues to advance, the adoption of PQC will be crucial in safeguarding our data, communications, and digital infrastructure. Through collaboration and innovation, we can help build a resilient and secure digital ecosystem that stands the test of time. Securing the Present, Innovating for the Future Security is a shared responsibility. Through collaboration across hardware and software ecosystems, we can build more resilient systems secure by design and by default, from Windows to the cloud, enabling trust at every layer of the digital experience. The updated Windows Security book and Windows Server Security book are available to help you understand how to stay secure with Windows. Learn more about Windows 11, Windows Server and Copilot+ PCs.. To learn more about Microsoft Security Solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.Migrate Sentinel to Defender - Why It Is a Security Architecture Decision, Not Just a Portal Change
Microsoft will retire the Sentinel experience in Azure on March 31, 2027. Most of the conversation around this transition focuses on cost optimization and portal consolidation. That framing undersells what is actually happening. The unified Defender portal is not a new interface for the same capabilities. It is the platform foundation for a fundamentally different SOC operating model — one built on a 2-tier data architecture, graph-based investigation, and AI agents that can hunt, enrich, and respond at machine speed. Partners who understand this will help customers build security programs that match how attackers actually operate. This document covers four things: What the unified experience delivers — the security capabilities that do not exist in standalone Sentinel and why they matter against today’s threats. What the transition really involves - is not data migration, but it is a data architecture project that changes how telemetry flows, where it lives, and who queries it. Where the partner opportunity lives — a structured progression from professional services (transactional, transition execution, and advisory) to ongoing managed security services. Why does the unified experience win competitively — factual capability advantages that give partners a defensible position against third-party SIEM alternatives. The Bigger Picture: Preparing for the Agentic SOC Before getting into transition mechanics, partners need to understand where the industry is headed — because the platform decisions made during this transition will determine whether a customer’s SOC is ready for what comes next. The security industry is moving from human-driven, alert-centric workflows to an operating model built on three pillars: Intellectual Property — the detection logic, hunting hypotheses, response playbooks, and domain expertise that differentiate one security team from another. Human Orchestration — the judgment, context, and decision-making that humans bring to complex incidents. Humans set strategy, validate findings, and make containment decisions. They do not manually triage every alert. AI Agents - built agents that execute repeatable work: enriching incidents, hunting across months of telemetry, validating security posture, drafting response actions, and flagging anomalies for human review. The SOC of 2027 will not be scaled by hiring more analysts. It will be scaled by deploying agents that encode institutional knowledge into automated workflows — orchestrated by humans who focus on the decisions that require judgment. This transformation requires a platform that provides three things: Deep telemetry — agents need months of queryable data to analyze behavioral patterns, build baselines, and detect slow-moving threats. The Sentinel data lake provides this at a cost point that makes long-retention feasible. Relationship context — agents need to understand how entities connect. Which accounts share credentials? What is the blast radius of a compromised service principle? What is the attack path from a phished user to domain admin? Sentinel Graph provides this. Extensibility — partners and customers need to build and deploy their own agents without waiting for Microsoft to ship them. The MCP framework and Copilot agent architecture provide this. None of these exist in Azure experience for Sentinel. All three ship with the Defender experience. The urgency goes beyond the March 2027 deadline. Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses — and every one of those creates a new attack surface. Prompt injection, data poisoning, agent hijacking, cross-plugin exploitation — these are not theoretical risks. They are in the wild today. Defending against AI-powered attacks requires a security platform that is itself AI Agent-ready. The new experience in Defender unlocks this experience. What Unified SIEM and XDR Actually Delivers The original framing — “single pane of glass for SIEM and XDR” — is accurate but insufficient. Here is what the unified platform delivers that standalone Sentinel does not. Cross-Domain Incident Correlation The Defender correlation engine does not just group alerts by time proximity. It builds multi-stage incident graphs that link identity compromise to lateral movement to data exfiltration across SIEM and XDR telemetry — automatically. Consider a token theft chain: an infostealer harvests browser session cookies (endpoint telemetry), the attacker replays the token from a foreign IP (Entra ID sign-in logs), creates a mailbox forwarding rule (Exchange audit logs), and begins exfiltrating data (DLP alerts). In standalone Sentinel, these are four separate alerts in four different tables. In the unified platform, they are one correlated incident with a visual attack timeline. 2-Tier Data Architecture The Sentinel data lake introduces a second storage tier that changes the economics and capabilities of security telemetry: Analytics Tier Data Lake Purpose Real-time detection rules, SOAR, alerting Hunting, forensics, behavioral analysis, AI agent queries Latency Sub-5-minute query and alerting Minutes to hours acceptable Cost ~$4.30/GB PAYG ingestion (~$2.96 at 100 GB/day commitment) ~$0.05/GB ingestion + $0.10/GB data processing (at least 20x cheaper) Retention 90 days default (expensive to extend) Up to 12 years at low cost Best for High-signal, low-volume sources High-volume, investigation-critical sources The architecture decision is not “which tier is cheaper.” It is “which tier gives me the right detection capability for each data source.” Analytics tier candidates: Entra ID sign-in logs, Azure activity, audit logs, EDR alerts, PAM events, Defender for Identity alerts, email threat detections. These need sub-5-minute alerting. Data lake candidates: Raw firewall session logs, full DNS query streams, proxy request logs, Sysmon process events, NSG flow logs. These drive hunting and forensic analysis over weeks or months. Dual-ingest sources: Some sources need both tiers. Entra ID sign-in logs are the canonical example — analytics tier for real-time password spray detection, Data Lake for graph-based blast radius analysis across months of authentication history. Implementation is straightforward: a single Data Collection Rule (DCR) transformation handles the split. One collection point, two routing destinations. The right framing: “Right data in the right tier = better detections AND lower cost.” Cost savings are a side effect of good security architecture, not the goal. Sentinel Graph Sentinel graph enables SOC teams and AI agents to answer questions that flat log queries cannot: What is the blast radius of this compromised account? Which service principals share credentials with the breached identity? What is the attack path from this phished user to domain admin? Which entities are connected to this suspicious IP across all telemetry sources? Graph-based investigation turns isolated alerts into context-rich intelligence. It is the difference between knowing “this account was compromised” and understanding “this account has access to 47 service principals, 3 of which have written access to production Key Vault.” Security Copilot Integration Security Copilot embedded in the defender portal helps analysts summarize incidents, generate hunting queries, explain attacker behavior, and draft response actions. For complex multi-stage incidents, it reduces the time from “I see an alert” to “I understand the full scope” from hours to minutes. With free SCUs available with Microsoft 365 E5, teams can apply AI to the highest-effort investigation work without adding incremental cost. MCP and the Agent Framework The Model Context Protocol (MCP) and Copilot agent architecture let partners and customers build purpose-built security agents. A concrete example: an MCP-enabled agent can automatically enrich a phishing incident by querying email metadata, checking the sender against threat intelligence, pulling the user’s recent sign-in patterns, correlating with Sentinel Graph for lateral risk, and drafting a containment recommendation — in under 60 seconds. This is where partner intellectual property becomes competitive advantage. The agent framework is the mechanism for encoding proprietary detection logic, response playbooks, and domain expertise into automated workflows that run at machine speed. Security Store Security Store allows partners to evolve from one‑time transition projects into repeatable, scalable offerings—supporting professional services, managed services, and agent‑based IP that align with the customer’s unified SecOps operating model As part of the transition, the Microsoft Security Store becomes the extension layer for the Defender —allowing partners to deliver differentiated agents, SaaS, and security services natively within Defender and Sentinel, instead of building and integrating in isolation The 4 Investigation Surfaces: A Customer Maturity Ladder The Sentinel Data Lake exposes four distinct investigation surfaces, each representing a step toward the Agentic SOC — and a partner service opportunity: Surface Capability Maturity Level Partner Opportunity KQL Query Ad-hoc hunting, forensic investigation Basic — “we can query” Hunting query libraries; KQL training Graph Analytics Blast radius, attack paths, entity relationships Intermediate — “we understand relationships” Graph investigation training; attack path workshops Notebooks (PySpark) Statistical analysis, behavioral baselines, ML models Advanced — “we predict behaviors” Custom notebook development; anomaly scoring Agent/MCP Access Autonomous hunting, triage, response at machine speed Agentic SOC — “we automate” Custom agent development; MCP integration The customer who starts with “help us hunt better” ends up at “build us agents that hunt autonomously.” That is the progression from professional services to managed services. What the Transition Actually Involves It is not a data migration — customers’ underlying log data and analytics remain in their existing Log Analytics workspaces. That is important for partners to communicate clearly. But partners should not set the expectation that nothing changes except the URL. Microsoft’s official transition guide documents significant operational changes — including automation rules and playbooks, analytics rule, RBAC restructuring to the new unified model (URBAC), API schema changes that break ServiceNow and Jira integrations, analytics rule transitions where the Fusion engine is replaced by the Defender XDR correlation engine, and data policy shifts for regulated industries. Most customers cannot navigate this complexity without professional help. Important: Transitioning to the Defender portal has no extra cost - estimate the billing with the new Sentinel Cost Estimator Optimizing the unified platform means making deliberate changes: Adding dual-ingest for critical sources that need both real-time detection and long-horizon hunting. Moving high-volume telemetry to the Data Lake — enabling hunting at scale that was previously cost-prohibitive. Retiring redundant data copies where Defender XDR already provides the investigation capability. Updating RBAC, automation, and integrations for the unified portal’s consolidated schema and permission structure. Training analysts on new investigation workflows, Sentinel Graph navigation, and Copilot-assisted triage. Threat Coverage: The Detection Gap Most Organizations Do Not Know They Have This transition is an opportunity to quantify detection maturity — and most organizations will not like what they find. Based on real-world breach analysis — infostealers, business email compromise, human-operated ransomware, cloud identity abuse, vulnerability exploitation, nation-state espionage, and other prevalent threat categories — organizations running standalone Sentinel with default configurations typically have significant detection gaps. Those gaps cluster in three areas: Cross-domain correlation gaps — attacks that span identity, endpoint, email, and cloud workloads. These require the Defender correlation engine because no single log source tells the complete story. Long-retention hunting gaps — threats like command-and-control beaconing and slow data exfiltration that unfold over weeks or months. Analytics-tier retention at 90 days is too expensive to extend and too short for historical pattern analysis. Graph-based analysis gaps — lateral movement, blast radius assessment, and attack path analysis that require understanding entity relationships rather than flat log queries. The unified platform with proper log source coverage across Microsoft-native sources can materially close these gaps — but only if the transition includes a detection coverage assessment, not just a portal cutover. Partners should use MITRE ATT&CK as the common framework for measuring detection maturity. Map existing detections to ATT&CK tactics and techniques before and after transition — a measurable, defensible improvement that justifies advisory fees and ongoing managed services. Partner Opportunity: Professional Services to Managed Services This transition creates a structured progression for all partner types — from professional services that build trust and surface findings, to managed security services that deliver ongoing value. The key insight most partners miss: do not jump from “transition assessment” to “managed services pitch.” Customers are not ready for that conversation until they have experienced the value of professional services. The bridge engagement — whether transactional, transition execution, or advisory — builds trust, demonstrates the expertise, and surfaces the findings that make the managed services conversation a logical next step. Professional Services (transactional + transition execution + advisory) → Managed Security Services (MSSP) The USX transition is the ideal professional services entry point because it combines a mandatory deadline (March 2027) with genuine technical complexity (analytics rule, automation behavioral changes, RBAC restructuring, API schema shifts) that most customers cannot navigate alone. Every engagement produces findings — detection gaps, automation fragility, staffing shortfalls — that are the most credible possible evidence for managed services. Professional Services Transactional Partners Offer Customer Value Key Deliverables Transition Readiness Assessment Risk-mitigated transition with clear scope Sentinel deployment inventory; Defender portal compatibility check; transition roadmap with timeline; MITRE ATT&CK detection coverage baseline Transition Execution and Enablement Accelerated time-to-value, minimal disruption Workspace onboarding; RBAC and automation updates; Dual-portal testing and validation; SOC team training on unified workflows Security Posture and Detection Optimization Better detections and lower cost Data ingestion and tiering strategy; Dual-ingest implementation for critical sources; Detection coverage gap analysis; Automation and Copilot/MCP recommendations Advisory Partners Offer Customer Value Key Deliverables Executive and Strategy Advisory Leadership alignment on why this transition matters Unified SecOps vision and business case; Zero Trust and SOC modernization alignment; Stakeholder alignment across security, IT, and leadership Architecture and Design Advisory Future-ready architecture optimized for the Agentic SOC Target-state 2-tier data architecture; Dual-ingest routing decisions mapped to MITRE tactics; RBAC, retention, and access model design Detection Coverage and Gap Analysis Measurable detection maturity improvement Current-state MITRE ATT&CK coverage mapping; Gap analysis against 24 threat patterns; Detection improvement roadmap with priority recommendations SOC Operating Model Advisory Smooth analyst adoption with clear ownership Redesigned SOC workflows for unified portal; Incident triage and investigation playbooks; RACI for detection engineering, hunting, and platform ops Agentic SOC Readiness Preparation for AI-driven security operations MCP and agent architecture assessment; Custom agent development roadmap; IP + Human Orchestration + Agent operating model design Cost, Licensing and Value Advisory Transparent cost impact with strong business case Current vs. future cost analysis; Data tiering optimization recommendations; TCO and ROI modeling for leadership The conversion to managed services is evidence-based. Every professional services engagement produces findings — detection gaps, automation fragility, staffing shortfalls. Those findings are the most credible possible case for ongoing managed services. Managed Security Services The unified platform changes the managed security conversation. Partners are no longer selling “we watch your alerts 24/7.” They are selling an operating model where proprietary AI agents handle the repeatable work — enrichment, hunting, posture validation, response drafting — and human experts focus on the decisions that require judgment. This is where the competitive moat forms. The formula: IP + Human Orchestration + AI Agents = differentiated managed security. The unified platform enables this through: Multi-tenancy — the built-in multitenant portal eliminates the need for third-party management layers. Sentinel Data Lake — agents can query months of customer telemetry for behavioral analysis without cost constraints. Sentinel Graph — agents can traverse entity relationships to assess blast radius and map attack paths. MCP extensibility — partners can build agents that integrate with proprietary tools and customer-specific systems. Partners who build proprietary agents encoding their detection logic into the MCP framework will differentiate from partners who rely on out-of-box capabilities. The Securing AI Opportunity Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses at an accelerating pace. Every AI deployment creates a new attack surface — prompt injection, data poisoning, agent hijacking, cross-plugin exploitation, unauthorized data access through agentic workflows. These are not theoretical risks. They are in the wild today. Partners who can help customers secure their AI deployments while also using AI to strengthen their SOC will command premium positioning. This requires a security platform that is itself AI Agent-ready — one that can deploy defensive agents at the same pace organizations deploy business AI. The unified Defender portal is that platform. Partners who position USX as “preparing your SOC for AI-driven security operations” will differentiate from partners who position it as “moving to a new portal.” Cost and Operational Benefits Better security architecture also costs less. This is not a contradiction — it is the natural result of putting the right data in the right tier. Benefit How It Works Eliminate low-value ingestion Identify and remove log sources that are never used for detections, investigations, or hunting. Immediately lowers analytics-tier costs without impacting security outcomes. Right-size analytics rules Disable unused rules, consolidate overlapping detections, and remove automation that does not reduce SOC effort. Pay only for processing that delivers measurable security value. Avoid SIEM/XDR duplication Many threats can be investigated directly in Defender XDR without duplicating telemetry into Sentinel. Stop re-ingesting data that Defender already provides. Tier data by detection need Store high-volume, hunt-oriented telemetry in the Data Lake at at least 20x lower cost. Promote only high-signal sources to the analytics tier. Full data fidelity preserved in both tiers. Reduce operational overhead Unified SIEM+XDR workflows in a single portal reduce tool switching, accelerate investigations, simplify analyst onboarding, and enable SOC teams to scale without proportional headcount increases. Improve detection quality The Defender correlation engine produces higher-fidelity incidents with fewer false positives. SOC teams spend less time triaging noise and more time on real threats. Competitive Positioning Partners need defensible talking points when customers evaluate third-party SIEM alternatives. The following advantages are factual, sourced from Microsoft’s transition documentation and platform capabilities — not marketing claims. No extra cost for transitioning — even for non-E5 customers. Third-party SIEM migrations involve licensing, data migration, detection rewrite, and integration rebuild costs. Native cross-domain correlation across Sentinel + Defender products into multi-stage incident graphs. Third-party SIEMs receive Microsoft logs as flat events — they lack the internal signal context, entity resolution, and product-specific intelligence that powers cross-domain correlation. Custom detections across SIEM + XDR — query both Sentinel and Defender XDR tables without ingesting Defender data into Sentinel. Eliminates redundant ingestion cost. Alert tuning extends to Sentinel — previously Defender-only capability, now applicable to Sentinel analytics rules. Net-new noise reduction. Unified entity pages — consolidated user, device, and IP address pages with data from both Sentinel and Defender XDR, plus global search across SIEM and XDR. Third-party SIEMs provide entity views from ingested data only. Built-in multi-tenancy for MSSPs — multitenant portal manages incidents, alerts, and hunting across tenants without third-party management layers. Try out the new GDAP capabilities in Defender portal. Industry validation: Microsoft’s SIEM+XDR platform has been recognized as a Leader by both Forrester (Security Analytics Platforms, 2025) and Gartner (SIEM Magic Quadrant, 2025). Summary: What Partners Should Take Away Topic Key Message Framing USX is a security architecture transformation, not a portal transition. Lead with detection capability, not cost savings. Platform foundation Sentinel Data Lake + Sentinel Graph + MCP/Agent Framework = the platform for the Agentic SOC. 4 investigation surfaces KQL → Graph → Notebooks → Agent/MCP. A maturity ladder from “we can query” to “we automate at machine speed.” Architecture 2-tier data model (analytics + Data Lake) with dual-ingest for critical sources. Cost savings are a side effect of good architecture. Transition complexity Analytics rules and automation rules. API schema changes. RBAC restructuring. Most customers need professional help. Partner engagement model Professional Services (transactional + transition execution + advisory) → Managed Services (MSSP). Competitive positioning No extra cost. Native correlation. Cross-domain detections. Built-in multi-tenancy. Capabilities third-party SIEMs cannot replicate. Partner differentiation IP + Human Orchestration + AI Agents. Partners who build proprietary agents on MCP have competitive advantage. Timeline March 31, 2027. Start now — phased transition with one telemetry domain first, then scale.Introducing Multi-Account Support for Connectors in Microsoft Sentinel
We're excited to announce that Microsoft Sentinel's data connectors for Auth0, CrowdStrike Falcon, and Salesforce Service Cloud now support multi-account ingestion — enabling you to connect and monitor multiple accounts or tenants from a single, unified connector configuration. The Challenge with Multi-Account Environments Modern enterprises don't run on a single account. Whether it's multiple Salesforce orgs across business units, several CrowdStrike tenants spanning subsidiaries, or Auth0 environments segmented by product line — security teams have long struggled to get unified visibility across all of them in a single SIEM. Until now, connecting multiple accounts from the same platform required painful workarounds: duplicate configurations, custom scripts, or dangerous blind spots in security coverage. Introducing Multi-Account Support for Auth0, CrowdStrike, and Salesforce in Microsoft Sentinel We're excited to announce that Microsoft Sentinel's data connectors for Auth0, CrowdStrike Falcon, and Salesforce Service Cloud now support multi-account ingestion — powered by the Codeless Connector Framework (CCF). You can now connect and monitor multiple accounts or tenants from a single, unified connector configuration — no scripts, no hacks. What's New? 🔑 Auth0 — Multi-Tenant Identity Monitoring Security teams managing multiple Auth0 tenants can now ingest logs from all of them into a single Sentinel workspace. Get complete visibility into authentication events, anomalous login patterns, and policy violations across every tenant without switching contexts. 🦅 CrowdStrike Falcon — Consolidated Endpoint Telemetry Organizations running multiple CrowdStrike tenants (e.g., across M&A entities or regional subsidiaries) can now stream detection alerts, threat intelligence, and endpoint telemetry from all tenants into Sentinel. One workspace. Full coverage. ☁️ Salesforce — Cross-Org Security Insights Enterprises with multiple Salesforce orgs can now centralize audit logs, login history, and API activity across all orgs. Detect insider threats, unauthorized access, and compliance gaps without stitching data together manually. 📖Find relevant connectors at Discover connectors Why It Matters Before After One connector = one account One connector = multiple accounts Manual workarounds for multi-tenant coverage Native, built-in multi-account support Fragmented detection across environments Unified analytics and incident correlation Higher operational overhead Streamlined configuration and management Getting Started Connecting multiple accounts is straightforward: 1. Navigate to Microsoft Sentinel → Data Connectors 2. Search for Auth0, CrowdStrike Falcon, or Salesforce 3. Open the connector and select "Add Account" 4. Authenticate and authorize each additional account 5. Start ingesting — your analytics rules, workbooks, and playbooks apply automatically across all accounts Built for Scale, Built for SOC Teams This update is part of our continued investment in making Microsoft Sentinel the most comprehensive and operationally efficient SIEM for enterprise environments. Multi-account support reduces configuration overhead, closes coverage gaps, and empowers SOC analysts to detect and respond to threats wherever they originate. What's Next? We're actively expanding multi-account support to more connectors. Stay tuned to the Microsoft Sentinel Blog and share your feedback!Help Shape the Microsoft Security Practitioner Community
We want to hear from the people who configure, operate, and defend with Microsoft Security every day. Share your priorities, challenges, and where you go to learn and connect. Your feedback will help shape future technical content, hands-on experiences, events, and community programs. The survey takes just a few minutes. Please fill out the survey here: Microsoft Security Tech Community Practitioner Survey – Fill out form Thank you!
One SOC, Many Tenants: Centralizing Microsoft Sentinel with Azure Lighthouse
Most large organizations don’t live in a single Microsoft Entra ID tenant. Acquisitions, regulatory separation, sovereignty mandates, and mission boundaries all multiply tenants over time. For a security operations team, that sprawl creates one hard question: how do you run a single security operations center (SOC) with one pane of glass, without copying every tenant’s logs into a central bucket and inheriting the compliance risk that comes with it? Azure Lighthouse provides delegated resource management for this scenario. It lets authorized operators in a central hub tenant work with scoped resources in spoke tenants from their own tenant. Paired with Microsoft Sentinel, it supports cross-tenant visibility while source logs remain stored in each spoke workspace. Group-based RBAC and Privileged Identity Management (PIM) can help govern privileged access. This practical blueprint applies least privilege to that pattern: one Sentinel deployment in the hub, delegated read access to the Log Analytics workspaces in each spoke, and RBAC and PIM controls that support auditability. The delegation is scoped to the workspaces the SOC needs. Before you begin: prerequisites Gather the identifiers and identity groups below before you touch any tenant. The consistency you establish here is what makes the per-spoke procedure repeatable across an entire estate. Collect tenant and workspace identifiers Hub CSOC tenant ID and hub Sentinel workspace resource ID. For each spoke: tenant ID, subscription ID, workspace resource group, and workspace resource ID. Create hub security groups in Microsoft Entra ID SOC-Readers, the required core query-access group. SOC-Responders, an optional group for response-specific actions. SOC-Admins, an optional and tightly controlled group. Define the minimum RBAC baseline Assign Log Analytics Reader to SOC-Readers at the spoke workspace or resource-group scope. Add elevated roles only when a documented use case requires them. Register the required resource providers Lighthouse and Sentinel both depend on resource providers being registered before delegation will work. In every spoke subscription, register Microsoft.ManagedServices so the delegation can be created. And because Sentinel lives only in the hub, register Microsoft.SecurityInsights and Microsoft.OperationalInsights on at least one subscription in the hub tenant. That last step is easy to overlook, and skipping it quietly blocks cross-tenant operations. What you’ll find here The architecture, and why data residency makes hub-and-spoke the right call. Prerequisites, including the resource providers teams most often forget to register. A repeatable, per-spoke delegation procedure. Validation queries that prove the access path actually works. A complete RBAC assignment matrix and PIM activation policy. Troubleshooting for the errors you’ll actually hit. Why hub-and-spoke for a cross-tenant SOC In this model, Microsoft Sentinel is deployed once, in the hub (CSOC) tenant. Each spoke tenant keeps its own Log Analytics workspace, where its logs are collected and retained. Azure Lighthouse connects the two: the spoke delegates scoped access to the hub, and authorized hub analysts query spoke workspaces from their own tenant. The source logs remain stored in the spoke workspace, while query results are returned across tenant boundaries to authorized users and services. Figure 1. The hub runs Sentinel and queries each spoke’s Log Analytics workspace through a scoped Azure Lighthouse delegation; logs never leave the spoke tenant. That separation is the entire point, and it lines up with the advantages Microsoft calls out for centralized cross-tenant management: Workspace ownership and source-log storage remain with each spoke tenant. Source telemetry remains stored in the configured spoke workspace and region, subject to the service configuration and authorized query access. Separate workspaces help maintain tenant isolation between spokes. Cross-tenant detection and hunting can query spoke workspaces without centralizing the underlying source logs; authorized query results are returned across tenant boundaries. Ingestion and retention costs are billed to the tenant that generates the data, not to the hub. What this runbook delivers The objective is a centralized CSOC with scoped, governed access across spoke tenants from a single Sentinel instance. Hub SOC teams query spoke Log Analytics workspaces through delegation, run cross-tenant analytics, and create and manage incidents centrally, while spoke logs stay in spoke workspaces and tenant isolation is preserved. Just as important is how that access is granted. The target state is least-privilege by construction: RBAC assignments carry only the permissions the SOC needs, privileged roles are PIM-governed rather than standing, and every delegation is scoped to the specific resources in play. When the build is complete, the operating model is both active and auditable. Configuring the delegation (per spoke tenant) Repeat the three steps below for each spoke. For fleets larger than a handful of tenants, capture the same authorization in an Azure Lighthouse ARM template and deploy it per spoke, so the scope and role assignments stay identical across the estate. Step 1: Register the provider in the spoke subscription Register Microsoft.ManagedServices in the spoke subscription. Confirm the provider registration state is Registered before continuing. Step 2: Create the Lighthouse delegation from spoke to hub Open Azure Lighthouse in the spoke tenant. Create a delegation, or offer, and set the managing tenant to the hub CSOC tenant ID. Add an authorization with the principal set to the hub SOC-Readers group and the role set to Log Analytics Reader. Set the scope to the workspace resource group (preferred) or to the individual workspace. Prefer group-based assignments and avoid direct user assignments. Step 3: Repeat across all spoke tenants Apply the same pattern and naming convention every time. Document any scope or role exceptions for security review. Validating the delegation Three checks confirm the delegation is wired correctly: visibility, query access, and incident generation. Run them in order, because each one depends on the check before it. Figure 2. The three validation checks run in sequence — visibility, then cross-tenant query, then incident generation — each building on the one before. Confirm delegated visibility From the hub context, verify that each spoke appears under Azure Lighthouse delegated resources. Confirm that the expected principals and scopes are listed. Run a cross-tenant query from hub Sentinel Run a simple take query to verify that the access path resolves. Run a data query against a known active table to confirm you can see ingestion. Confirm the access path resolves: workspace("/subscriptions/<spoke-sub-id>/resourceGroups/<spoke-rg>/providers/Microsoft.OperationalInsights/workspaces/<spoke-ws>") | take 1 Check that a known table is receiving data: workspace("/subscriptions/<spoke-sub-id>/resourceGroups/<spoke-rg>/providers/Microsoft.OperationalInsights/workspaces/<spoke-ws>").Heartbeat | where TimeGenerated > ago(24h) | summarize Events = count() Verify incident generation in hub Sentinel Create a temporary scheduled analytics rule that uses cross-tenant query logic. Trigger the test condition and confirm that the incident is created in the hub. Standardizing new-spoke onboarding Turn the procedure into a checklist so every new spoke is onboarded the same way and nothing slips. Resource provider registered. Delegation deployed with the hub as managing tenant. Roles assigned to hub SOC groups. Cross-tenant query test passed. Hub incident-generation test passed. Access-review owner assigned. Security and governance Delegation connects the hub to scoped spoke resources; governance helps control that access. Three controls do most of the work. Enforce privileged identity controls Make privileged groups PIM-eligible rather than permanently assigned. Require MFA, approval, justification, and time-bound activation. Maintain separation of duties Keep SOC monitoring, content engineering, and platform administration in separate roles. Review delegated access on a recurring governance cadence. Manage exceptions with formal controls Document every elevated-access and broad-scope delegation exception. Require security-architecture approval for any non-standard scope. Role and RBAC assignment matrix The tables below translate those principles into concrete assignments: first the hub-local roles, then the delegated spoke roles, and finally the PIM activation policy that governs both. Hub (CSOC) tenant: local assignments Spoke (service) tenant: delegated via Azure Lighthouse PIM activation requirements Key design rules Minimum privilege governs spoke delegation. Log Analytics Reader covers every cross-tenant detection and query operation, so Owner and broad Contributor at subscription scope have no place in a SOC delegation. Sentinel Responder in a spoke is rarely needed. It matters only when analysts must acknowledge, close, or act on spoke-level resources directly, and in a hub-only Sentinel model spoke incidents don’t exist, so the role usually isn’t required. Separation of duties is strict. Content engineers don’t get responder rights, responders don’t get content-deployment rights, and platform admins sit apart from both monitoring and detection engineering. Routine privileged roles are eligible and time-bound. SOC responders, hunters, content engineers, and platform admins use PIM rather than permanent assignment. Emergency-access accounts are the exception and should follow Microsoft Entra emergency-access guidance, including monitoring and regular validation. Troubleshooting common issues Most problems fall into three buckets, and each has a short diagnostic path. Design notes and what’s next By default, Sentinel stays enabled in the hub only, unless a spoke-specific requirement is approved. Spoke tenants remain data-source focused and don’t generate local Sentinel incidents; detection, incident management, and automation all live in hub Sentinel, giving you one place to build content and one place to respond. A centralized SOC does not require centralizing every source workspace. With scoped Azure Lighthouse delegation and PIM-governed access, a CSOC can query a multitenant estate while source logs remain stored in their spoke workspaces. Further reading Manage Microsoft Sentinel workspaces at scale (Azure Lighthouse) Manage multiple tenants in Microsoft Sentinel as an MSSP Extend Microsoft Sentinel across workspaces and tenantsMCP safety & evaluation with the Agent 365 CLI & Agent Governance Toolkit
Co Author: JiteshThakur AI agents are useful because they can act. They call tools, query databases, send messages, and hand work to other agents. That same freedom creates a problem: access control can tell you which service an agent may reach, but it does not always tell you whether a particular action is sensible, safe, or permitted. MCP is how most agents now act. Two Control Points: This post examines two control points that address different parts of the MCP lifecycle. Agent 365 CLI evaluates the MCP server before an agent uses it. Agent Governance Toolkit (AGT) governs sensitive tool calls while the agent runs. One improves what the agent sees. The other governs what the agent does. The Agent 365 CLI is a cross-platform command-line tool for Agent 365 applications on Azure. Its evaluation command examines MCP tool definitions and scores their quality. AGT evaluates actions against policy and records each decision. Together, these tools support a practical model: evaluate the server first, then provide proper scaffolding for the developer to test this in a dry run. Agent 365 CLI: Score an MCP server from the command line: The Agent 365 CLI can evaluate an MCP server against research-based practices for production readiness. The result is more useful than a simple pass or fail. The evaluation gives you: A score for each tool name, description, and parameter schema; A prioritized list of improvements; An overall maturity score for the server; and Local output that you can use early in development. This report turns a vague question, "Is this MCP server ready?", into a concrete list of work. The evaluate command a365 develop-mcp evaluate --server-url <server-url> [--auth-token <auth-token>] [options] The command reads the tool schemas from the server. It then produces guidance for names, descriptions, parameters, and schema structure. A local coding-agent CLI scores the semantic checks. You can use GitHub Copilot CLI or Claude Code under your account and AI subscription. The command does not send tool-schema data to Microsoft. Prerequisites: Install the following software: Agent 365 CLI; Node.js 18 or later for GitHub Copilot CLI; and A supported coding-agent CLI for semantic scoring. For example, install GitHub Copilot CLI with this command: powershell npm install -g @github/copilot This bring-your-own-LLM model keeps the scoring step in your local development environment. It is useful when model calls must remain inside an approved deployment. How the evaluation works The command runs a five-step pipeline and logs progress as it goes. Fig 1: MCP Evaluation using Agent 365 Cli Connect to the MCP server and collect its tool schemas. Generate an evaluation checklist in the output directory. Score the semantic checks with the selected coding agent. Calculate the maturity level and action priorities. Write the JSON and HTML reports. The evaluation contains two types of checks: Deterministic checks use exact rules in the CLI. For example, a tool name cannot be empty. Semantic checks use a coding agent to score clarity and meaning. Each result includes a reason for the score. Examples Set the authentication token in an environment variable. Then evaluate an authenticated server and write the artifacts to a subfolder. powershell $env:A365_MCP_AUTH_TOKEN = "<bearer-token>" a365 develop-mcp evaluate --server-url "https://my-mcp-server.contoso.com/mcp" --output-dir "./eval" Use a specific scoring engine with the `--eval-engine` option: powershell a365 develop-mcp evaluate --server-url "http://localhost:5000/mcp" --eval-engine claude-code Scenario: Evaluate a malicious MCP server For this demonstration, we hosted a deliberately malicious MCP server at `http://127.0.0.1:8124/`. It exposes tools that demonstrate tool poisoning, credential leakage, prompt injection, schema mismatch, sandbox escape, and other attacks. The server is intentionally unsafe and is for demonstration only. Fig 2: Setting up a test MCP server for evaluation We ran the evaluation in two steps. First, we generated the checklist without automatic semantic scoring: a365 develop-mcp evaluate --server-url "http://127.0.0.1:8124/" --eval-engine none Fig 3: Agent365CLI MCP Evaluation The command wrote the checklist and a semantic-evaluation prompt to the output directory. It also displayed the next steps. Second, we gave the prompt and checklist to a coding agent. The agent completed each unscored semantic check with a Boolean score and a short reason. After we saved the completed checklist, we ran the command again to generate the report: a365 develop-mcp evaluate --server-url "http://127.0.0.1:8124/" --output-dir "C:\temp\MaliciousMCP" Fig 4: Creating the report with Agent365 CLI MCP Evaluate command Understanding the evaluation report Open `<server-name>_eval_report.html` from the output directory. The report contains: The overall score from 0 to 100; The maturity level from 0 to 4; Scores for each tool and quality category; and A prioritized action list for the next maturity level. Fig 5: MCP Evaluation Report In our demonstration, the server scored 86.0 and reached Level 3: Optimized for AI. That strong overall score did not mean that every tool was safe or clear. The report found 58 action items, including one critical item and 33 high-priority items. That contrast matters. A server can have valid schemas and consistent names while still exposing misleading or dangerous tools. Fig 6: MCP Evaluation Report - Tool-By-Tool Detail What to look for Read the per-tool results before the overall score. A single weak tool can create more risk than the server average suggests. Focus on these report sections: Tool names: Can an agent select the correct tool from its name? Tool descriptions: Does each description explain the purpose and correct use? Parameter names: Do the names identify the data that the tool requires? Parameter descriptions: Do they explain the format, type, and constraints? Schema structure: Are the schemas valid and processable? Action items: Which changes have the highest effect on tool selection and use? The command processes static tool schemas from `tools/list`. It does not process runtime payloads, end-user data, or personal data. The command keeps the `--auth-token` value in memory. It sends the value only in the HTTP `Authorization` header. It does not write the token to disk or give it to the coding agent. AGT: Put governance in the execution path: Microsoft's open-source Agent Governance Toolkit (AGT) evaluates an action before execution. It adds identity and policy context, records the decision, and can send risky work for approval. This can be used by developers during the build time for dynamic evaluation of the MCP server. AGT lets developers put part of that intent into the execution path. Remote tools still need secure implementations, sandboxes need hard boundaries, and audit records need appropriate storage and access controls. You do not need to replace your agent framework to use it. What sits in the decision path? AGT wraps the tools that an agent already uses. You can start to govern a tool with two lines of Python: python from agentmesh.governance import govern safe_tool = govern(my_tool, policy="policy.yaml") On each call, `safe_tool` evaluates the configured policy. An allowed action reaches the original tool. A denied action raises `GovernanceDenied` and creates a decision record. This wrapper model reduces the cost of adoption. Teams can add governance to an existing agent stack without rebuilding it. AGT supports Python, TypeScript, .NET, Rust, and Go. Its documented integrations include popular agent frameworks, MCP, and A2A. Teams can also adopt AGT in stages. A team can begin with policy checks and audit records. It can add identity, approvals, sandboxing, and operational controls as risk increases. Each control answers a different question: Policy: Is this action allowed? Identity and trust: Which agent made the request? Runtime controls: What limits apply to execution? Audit evidence: Why did AGT allow or deny the action? A low-risk assistant can need only a deny rule and basic logging. An agent that moves money or changes production systems needs stronger controls. Fig 7: AGT Architecture Scenario: Govern the same malicious MCP server For this scenario demonstration, we used AGT Python packages as an MCP gateway. The gateway sat between an agent and the same malicious server from the earlier evaluation. This setup let us examine both control points against one target. The Agent 365 CLI examined the server's static tool definitions. The AGT gateway examined real requests and responses for the developer during its testing. Fig 8: AGT findings at runtime In the policy interface, a developer can edit runtime limits and detection rules. The developer can also validate the policy against sample tool metadata, save a revision, and activate it with a recorded reason. Fig 9: AGT control coverage The control-coverage view shows which AGT capabilities are active in the gateway. It also links each capability to package checks and end-to-end evidence. In our demonstration, we included the following controls: Tool metadata poisoning detection; Tool change and rug-pull detection; Dangerous argument blocking; Tool-response content scanning; Per-client tool-call budgets; and A redacted decision audit trail. You can build your detection & input security by reading more about it here. The gateway detected malicious content. For one blocked `tools/list` request, it recorded the findings. The important result was not only that AGT blocked the request. It also preserved the matched evidence, affected tool locations, policy modes, and request context. Fig 10: Example detection via AGT The dashboard then summarized block-mode findings, leading risk drivers, and tools that required review. This evidence can help a team prioritize policy changes and investigate repeated attacks. Fig 11: Sample AGT metrics AGT does not require this UI, gateway, or architecture. Its structured decisions can feed an admin console, SIEM, incident workflow, or approval queue. AGT also includes an Agent Compliance package with mappings for OWASP and other controls. These mappings give developers and governance teams a common record of applied controls. Teams do not need to reconstruct the agent's behavior after an incident. Check Compliance - Agent Governance Toolkit for more information. Conclusion: MCP safety needs controls before and during execution. The Agent 365 CLI improves the MCP interface before deployment. It exposes unclear tool definitions, scores server maturity, and turns quality gaps into prioritized work. While AGT is implemented at the build phase, it provides developers the ability to test policy, identity, execution context & preserve evidence for allowed or denied decisions. Neither tool replaces secure server code, strong sandbox boundaries, or protected audit storage. Instead, they make those controls easier to evaluate and explain. Start with one MCP server and one consequential tool call. Evaluate the server with the Agent 365 CLI. Then put an AGT policy around the action that carries the most risk. While these controls help secure the build phase of an agent, once agents move into production, runtime controls become essential. Agent365 provides those controls at runtime. With thanks to Ashik Kuppil for his inputs and collaboration on this post.Sensitivity Auto-labelling via Document Property
Why is this needed? Sensitivity labels are generally relevant within an organisation only. If a file is labelled within one environment and then moved to another environment, sensitivity label content markings may be visible, but by default, the applied sensitivity label will not be understood. This can lead to scenarios where information that has been generated externally is not adequately protected. My favourite analogy for these scenarios is to consider the parallels between receiving sensitive information and unpacking groceries. When unpacking groceries, you might sit your grocery bag on a counter or on the floor next to the pantry. You’ll likely then unpack each item, take a look at it and then decide where to place it. Without looking at an item to determine its correct location, you might place it in the wrong location. Porridge might be safe from the kids on the bottom shelf. If you place items that need to be protected, such as chocolate, on the bottom shelf, it’s not likely to last very long. So, I affectionately refer to information that hasn’t been evaluated as ‘porridge’, as until it has been checked, it will end up on the bottom shelf of the pantry where it is quite accessible. Label-based security controls, such as Data Loss Prevention (DLP) policies using conditions of ‘content contains sensitivity label’ will not apply to these items. To ensure the security of any contained sensitive information, we should look for potential clues to its sensitivity and then utilize these clues to ensure that the contained information is adequately protected - We take a closer look at the ‘porridge’, determine whether it’s an item that needs protection and if so, move it to a higher shelf in the pantry so that it’s out of reach for the kids. Effective use of Purview revolves around the use of ‘know your data’ strategies. We should be using as many methods as possible to try to determine the sensitivity of items. This can include the use of Sensitive Information Types (SITs) containing keyword or pattern-based classifiers, trainable classifiers, Exact Data Match, Document fingerprinting, etc. Matching items via SITs present in the items content can be problematic due to false positives. Keywords like ‘Sensitive’ or ‘Protected’ may be mentioned out of context, such as when referring to a classification or an environment. When classifications have been stamped via a property, it allows us to match via context rather than content. We don’t need to guess at an item’s sensitivity if another system has already established what the item’s classification is. These methods are much less prone to false positives. Why isn’t everyone doing this? Document properties are often not considered in Purview deployments. SharePoint metadata management seems to be a dying artform and most compliance or security resources completing Purview configurations don’t have this skill set. There’s also a lack of understanding of the relevance of checking for item properties. Microsoft haven’t helped as the documentation in this space is somewhat lacking and needs to be unpicked via some aligning DLP guidance (Create a DLP policy to protect documents with FCI or other properties). Many of these configurations will also be tied to regional requirements. Document properties being used by systems where I’m from, in Australia, will likely be very different to those used in other parts of the world. In the following sections, we’ll take a look at applicable use cases and walk through how to enable these configurations. Scenarios for use Labelling via document property isn’t for everyone. If your organisation is new to classification or you don’t have external partners that you collaborate with at higher sensitivity levels, then this likely isn’t for you. For those that collaborate heavily and have a shared classification framework, as is often seen across government, this is a must! This approach will also be highly relevant to multi-tenant organisations or conglomerates where information is regularly shared between environments. The following scenarios are examples of where this configuration will be relevant: 1. Migrating from 3 rd party classification tools If an item has been previously stamped by a 3 rd party classification tool, then evaluating its applied document properties will provide a clear picture of its security classification. These properties can then be used in service-based auto-labelling policies to effectively transition items from 3 rd party tools to Microsoft Purview sensitivity labels. As labels are applied to items, they will be brought into scope of label-based controls. 2. Detecting data spill Data spill is a term that is used to define situations where information that is of a higher than permitted security classification land in an environment. Consider a Microsoft 365 tenant that is approved for the storage of Official information but Top Secret files are uploaded to it. Document properties that align with higher than permitted classifications provide us with an almost guaranteed method of identifying spilled items. Pairing this document property with an auto-labelling policy allows for the application of encryption to lock unauthorized users out of the items. Tools like Content Explorer and eDiscovery can then be used to easily perform cleanup activities. If using document properties and auto-labelling for this purpose, keep in mind that you’ll need to create sensitivity labels for higher than permitted classifications in order to catch spilled items. These labels won’t impact usability as you won’t publish them to users. You will, however, need to publish them to a single user or break glass account so that they’re not ignored by auto-labelling. 3. Blocking access by AI tools If your organization was concerned about items with certain properties applied being accessed by generative AI tools, such as Copilot, you could use Auto-labelling to apply a sensitivity label that restricts EXTRACT permissions. You can find some information on this at Microsoft 365 Copilot data protection architecture | Microsoft Learn. This should be relevant for spilled data, but might also be useful in situations where there are certain records that have been marked via properties and which should not be Copilot accessible. 4. External Microsoft Purview Configurations Sensitivity labels are relevant internally only. A label, in its raw form, is essentially a piece of metadata with an ID (or GUID) that we stamp on pieces of information. These GUIDs are understood by your tenant only. If an item marked with a GUID shows up in another Microsoft 365 tenant, the GUID won’t correspond with any of that tenant’s labels or label-based controls. The art in Microsoft Purview lies in interpreting the sensitivity of items based on content markings and other identifiers, so that data security can be maintained. Document properties applied by Purview, such as ClassificationContentMarkingHeaderText are not relevant to a specific tenant, which makes them portable. We can use these properties to help maintain classifications as items move between environments. 5. Utilizing metadata applied by Records Management solutions Some EDRMS, Records or Content Management solutions will apply properties to items. If an item has been previously managed and then stamped with properties, potentially including a security classification, via one of these systems, we could use this information to inform sensitivity label application. 6. 3 rd party classification tools used externally Even if your organisation hasn’t been using 3rd party classification tools, you should consider that partner organisations, such as other Government departments, might be. Evaluating the properties applied by external organisations to items that you receive will allow you to extend protections to these items. If classification tools like Janus or Titus are used in your geography/industry, then you may want to consider checking for their properties. Regarding the use of auto-classification tools Some organisations, particularly those in Government, will have organisational policies that prevent the use of automatic classification capabilities. These policies are intended to ensure that each item is assessed by an actual person for risk of disclosure rather than via an automated service that could be prone to error. However, when auto-labelling is used to interpret and honour existing classifications, we are lowering rather than raising the risk profile. If the item’s existing classification (applied via property) is ignored, the item will be treated as porridge and is likely to be at risk. If auto-labelling is able to identify a high-risk item and apply the relevant label, it will then be within scope of Purview’s data security controls, including label-based DLP, groups and sites data out of place alerting, and potentially even item encryption. The outcome is that, through the use of auto-labelling, we are able to significantly reduce risk of inappropriate or unintended disclosure. Configuration Process Setting up document property-based auto-labelling is fairly straightforward. We need to setup a managed property and then utilize it an auto-labelling policy. Below, I've split this process into 6 steps: Step 1 – Prepare your files In order to make use of document properties, an item with the properties applied will first need to be indexed by SharePoint. SharePoint will record the properties as ‘crawled properties’, which we’ll then need to convert into ‘managed properties’ to make them useful. If you already have items with the relevant properties stored in SharePoint, then they are likely already indexed. If not, you’ll need to upload or create an item or items with the properties applied. For testing, you’ll want to create a file with each property/value combination so that you can confirm that your auto-labelling policies are all working correctly. This could require quite a few files depending on the number of properties you’re looking for. To kick off your crawled property generation though, you could create or upload a single file with the correct properties applied. For example: In the above, I’ve created properties for ClassificationContentMarkingHeaderText and ClassificationContentMarkingFooterText, which you’ll often see applied by Purview when an item has a sensitivity label content marking applied to it. I’ve also included properties to help identify items classified via JanusSeal, Titus and Objective. Step 2 – Index the files After creating or uploading your file, we then need SharePoint to index it. This should happen fairly quickly depending on the size of your environment. I'd expect to wait sometime between 10 minutes and 24 hrs. If you're not in a hurry, then I'd recommend just checking back the next day. You'll know when this has been completed when you head into SharePoint Admin > Search > Managed Search Schema > Crawled Properties and can find your newly indexed properties: Step 3 – Configure managed properties Next, the properties need to be configured as managed properties. To do this, go to SharePoint Admin > More features > Search > Managed Search Schema > Managed Properties. Create a new managed property and give it a name. Note that there are some character restrictions in naming, but you should be able to get it close to your document property name. Set the property’s type to text, select queryable and retrievable. Under ‘mappings to crawled properties’, choose add mapping, search for and select the property indexed from the file property. Note that the crawled property will have the same name as your document property, so there’s no need to browse through all of them: Repeat this so that you have a managed property for each document property that you want to look for. Step 4 – Configure Auto-labelling policies Next up, create some auto-labelling policies. You’ll need one for each label that you want to apply, not one per property as you can check multiple properties within the one auto-labelling policy. - From within Purview, head to Information Protection > Policies > Auto-labelling policies. - Create a new policy using the custom policy template. - Give your policy an appropriate name (e.g. Label PROTECTED via property). - Select the label that you want to apply (e.g. PROTECTED). - Select SharePoint based services (SharePoint and OneDrive). - Name your auto-labelling rules appropriately (e.g. SPO – Contains PROTECTED property) - Enter your conditions as a long string with property and value separated via a colon and multiple entries separated with a comma. For example: ClassificationContentMarkingHeaderText:PROTECTED,ClassificationContentMarkingFooterText:PROTECTED,Objective-Classification:PROTECTED,PMDisplay:PROTECTED,TitusSEC:PROTECTED Note that the properties that you are referencing are the Managed Property rather than the document property. This will be relevant if your managed property ended up having a different name due to character restrictions. After pasting in your string into the UI, the resultant rule should look something like this: When done, you can either leave your policy in simulation mode or save it and then turn it on from the auto-labelling policies screen. Just be aware of any potential impacts, such as accidently locking users out by automatically deploying a label with encryption configuration. You can reduce any potential impact by targeting your auto-labelling policy at a site or set of sites initially and then expanding its scope after testing. Step 5 - Test Testing your configuration will be as easy as uploading or creating a set of files with the relevant document properties in place. Once uploaded, you’ll need to give SharePoint some time to index the items and then the auto-labelling policy some time to apply sensitivity labels to them. To confirm label application, you can head to the document library where your test files are located and enable the sensitivity column. Files that have been auto-labelled will have their label listed: You could also check for auto-labelling activity in Purview via Activity explorer: Step 6 – Expand into DLP If you’ve spent the time setting up managed properties, then you really should consider capitalizing on them in your DLP configurations. DLP policy conditions can be configured in the same manner that we configured Auto-labelling in Step 3 above. The document property also gives us an anchor for DLP conditions that is independent of an item’s sensitivity label. You may wish to consider the following: DLP policies blocking external sharing of items with certain properties applied. This might be handy for situations where auto-labelling hasn’t yet labelled an item. DLP policies blocking the external sharing of items where the applied sensitivity label doesn’t match the applied document property. This could provide an indication of risky label downgrade. You could extend such policies into Insider Risk Management (IRM) by creating IRM policies that are aligned with the above DLP policies. This will allow for document properties to be considered in user risk calculation, which can inform controls like Adaptive Protection. Here's an example of a policy from the DLP rule summary screen that shows conditions of item contains a label or one of our configured document properties: Thanks for reading and I hope this article has been of use. If you have any questions or feedback, please feel free to reach out.The Microsoft AI and Agent Platform — The Platform Behind Intelligent Agents
Why the platform around the model is the real enterprise differentiator Enterprise AI has reached a turning point. Beyond answering questions, it can now reason over business context, retrieve knowledge, use tools, coordinate workflows, and act across enterprise systems. This shift raises a critical question: How can organizations build agents intelligent enough to transform work while ensuring they remain trusted, governed, and ready to operate at enterprise scale? The answer is not a single model, chatbot, or orchestration framework. Foundation models are advancing quickly and increasingly becoming a commodity input — Azure AI Foundry alone provides access to more than 11,000 models. What determines enterprise value is not the model alone, but the platform around the model: the data that grounds it, the tools it can use, the experiences where people engage it, the runtime where it operates, and the enterprise foundation that gives it identity, context, governance, and operational control. The Microsoft AI and Agent platform enables organizations to build, ground, govern, and operate AI apps and agents at scale, bringing together the full agent lifecycle with open development, built-in intelligence, and consistent security, compliance, and policy controls. One ecosystem, multiple experiences, shared intelligence, flexible build paths, multiple runtime choices, and an enterprise foundation that carries security, governance, compliance, and Responsible AI across the stack. The reference mental model below expresses this as a layered platform — Users → Experiences → Agents → Intelligence → Runtime → Foundation with security, governance, compliance, and Responsible AI applied across every layer. An agent that is brilliant but ungoverned never leaves the pilot stage. An agent that is locked down but context-blind never delivers real value. Impact compounds only when both dimensions advance together, on the same platform, so that intelligence and control share one identity model, one data plane, and one control plane. Part 1 — Intelligence (this post): dives into how Microsoft's platform helps organizations build agents that understand work, reason over trusted context, and act through business systems to deliver real business value. Part 2 — Trust: will go deeper on how those agents are secured, governed, monitored, and managed across their lifecycle. Intelligence + Trust = Frontier Transformation Part 1: Intelligence Most enterprise AI programs begin with model experimentation - prompts, model comparisons, prototypes, accuracy evaluations. That is necessary but not sufficient. A model alone does not know your organization, your processes, your permissions, your systems of record, your compliance obligations, or your operating model. Experience layer: meet users where work already happens Agents deliver value only when they reach people in the flow of work. Enterprise AI adoption rarely happens through a single interface or experience. A sales leader, financial analyst, security operator, developer, field technician, and HR specialist do not need the same interface they need agents surfaced in the tools and workflows they already use. Microsoft's approach is not to force every agent into one portal. The platform supports multiple experiences over a shared foundation: Microsoft 365 Copilot for productivity and business users. Security Copilot for security operations. Azure Copilot for IT operations, cloud, and infrastructure. GitHub Copilot for developers. Dynamics 365 experiences for sales, service, finance, and supply chain workflows. Power Platform and Copilot Studio experiences for business applications and low-code extensions. Custom experiences for line-of-business apps, portals, websites, and industry-specific workflows. Regardless of where users engage, the underlying intelligence, governance, and runtime capabilities remain consistent across experiences. Agent layer: specialize by domain, tools, and autonomy Specialization with a shared substrate Generic agents often fail because enterprise work is domain specific. A security agent must understand incidents, alerts, identities, and threat intelligence. A finance agent must understand reconciliations, receivables, approvals, and controls. A developer agent must understand repositories, branches, pull requests, tests, and pipelines. Microsoft's platform supports both prebuilt domain agents and custom agents. Organizations should leverage the domain specific agents where possible and focus custom development on capabilities that create unique business value. Whether an agent is out of the box or custom, it inherits the same governance, so built-in and custom are never two different compliance islands. Agent systems form an autonomy spectrum, allowing organizations to progressively increase capability while maintaining appropriate levels of human oversight. Assistive: The agent recommends; a human decides. Example - A finance agent drafts a reconciliation for review. Supervised autonomy: the agent acts within bounded authority and escalates exceptions. Example - An SRE agent auto-remediates known alert classes and escalates novel incidents. Multi-agent orchestration: A coordinating agent decomposes a goal and delegates to specialist agents. Example - One agent retrieves data, another analyzes it, another drafts a response, and another executes an approved action. Intelligence layer: grounding as a first-class platform tier An agent is only as good as the context it can reason over. The hardest part of building a useful enterprise agent is not calling a model. It is giving the agent the right context. Without trusted context, agents produce generic answers. The IQ Platform is the intelligence fabric that separates enterprise-grade agents from generic AI assistants. A generic model can answer questions based on its training data or a narrow retrieval source. A Microsoft agent, by contrast, can be grounded in multiple dimensions of your organizational intelligence: how people work, what business data means, which knowledge is authoritative, and what external signals matter. With the right intelligence fabric, agents become role-aware, process-aware, data-aware, and policy-aware. Microsoft's IQ model treats grounding as a reusable platform capability rather than per-project plumbing. IQ layer What it gives agents Why it matters Work IQ Collaboration context: people, skills, meetings, documents, decisions, workflows, and organizational relationships. Helps agents understand how work actually happens, not just what content exists. Fabric IQ Governed business data, metrics, semantic models, and analytical context. Helps agents reason over trusted enterprise data with consistent business definitions. Foundry IQ Models, curated knowledge, retrieval assets, memory, guardrails, and AI development capabilities delivered from Microsoft Foundry with plug-and-play memory, knowledge, and tool integrations. Helps teams build reliable, purpose-built agents with governed model and knowledge choices. Web IQ Public web, current external signals, research, news, and external context. Helps agents augment internal context with timely external intelligence. In a conventional application, data access is deterministic queries against known schemas. In an agentic system, the equivalent tier must serve retrieval for reasoning, semantically matching an ambiguous natural-language intent to the right passages, records, and metrics across unstructured collaboration content, structured business data, curated knowledge, and the live web. The four IQ sources correspond to those four retrieval modalities, and the IQ Platform gives agents a composable intelligence model. Each IQ layer adds a distinct signal, and together they allow agents to move from simple assistance to informed action. Intelligence is more than model capability. It emerges from the combination of grounding, memory, model selection, orchestration, and guardrails working together as a coordinated system. Grounding, fine-tuning, and adaptation Microsoft gives teams multiple adaptation levers within a governed environment rather than forcing every use case into one technique. Grounding is not a sidecar retrieval capability; it is an enterprise intelligence layer. Because the model layer is a platform tier rather than a single endpoint, adaptation techniques fine-tuning, distillation into smaller task models, and retrieval-augmented grounding are first-class options selected per workload. The common pattern: prefer grounding (RAG) for freshness and provenance, reserve fine-tuning for durable behavior, format, or domain-tone requirements, and distill to smaller models where latency and cost dominate. Memory In addition to retrieval and reasoning, enterprise agents increasingly rely on memory to preserve context across conversations, tasks, and workflows. Memory enables agents to maintain continuity, learn from prior interactions, and provide more personalized, adaptive, and goal-oriented experiences over time. Multi-model choice Agent workloads are not uniform. Some steps require simple classification. Others require complex reasoning, synthesis, code generation, or tool orchestration. Model choice is becoming a strategic architecture decision, balancing quality, latency, cost, sovereignty, and specialization requirements. Microsoft Foundry supports model choice as part of the platform rather than forcing all workloads through one endpoint with a curated catalog of leading foundation, open-source, and partner models spanning capabilities, performance trade-offs, and use cases so teams can move from experimentation to production confidently. Model routing Microsoft Foundry's Model Router selects the optimal LLM for each agent request per turn, not per session — a simple greeting can route to a fast, inexpensive model, while a complex tool-calling chain can route to a frontier model, all through one endpoint with zero routing logic. Model selection becomes a runtime policy, not hard-coded application logic providing automatic failover when an upstream provider is unavailable, prompt caching across models for identical inputs, and consistent tool-use semantics regardless of which underlying model handles a call. Key routing capabilities include per-request optimization, complexity-aware model selection, tool-aware routing, multi-agent support, resiliency, and cost optimization. Orchestration Orchestration transforms individual model interactions into coordinated agentic and multi-agent workflows. An LLM-driven planning layer that interprets user intent, breaks down complex requests, selects the right tools and knowledge, and executes multi-step plans and multi-agent workflows with guardrails for safety and compliance. Guardrails A guardrail is a named collection of controls; each control defines a risk to be detected, intervention points to scan the risk, and the response action to take when the risk is detected. Guardrails help ensure that agent behavior remains aligned with organizational policies, safety requirements, and business objectives. How agents are built: one continuum from no-code to pro-code Different builders. Different depth. One platform. The progression from no-code to low-code to pro-code is more than a tooling choice; it reflects increasing levels of customization, control, and organizational maturity. Different teams need different levels of control. A business user may need a simple knowledge agent. A process owner may need a workflow agent with connectors and approvals. An engineering team may need a custom multi-agent system with model routing, evaluation, tool use, and deployment automation. Organizations can start with simple productivity agents, evolve into governed workflow agents, and eventually build deeply integrated agentic systems. No-code - M365 Agent Builder: create simple agents from natural language and your organizational data. This is useful for lightweight departmental workflows, knowledge assistants, and task-specific copilots. Low-code - Copilot Studio: design, extend, and orchestrate agents with connectors, workflows, and enterprise governance. This is where business technologists and app makers can build more sophisticated agents that integrate with systems, automate processes, and enforce organizational rules. Pro-code - Microsoft Foundry: enables developers to build custom AI systems with full control over models, orchestration, infrastructure, and code. This is where organizations can build highly specialized agents with advanced reasoning patterns, custom retrieval, tool use, evaluation pipelines, and deployment strategies. The key principle is continuity; moving from no-code to low-code to pro-code should not require rethinking the architecture. Identity, grounding, governance, policy, and operational controls should carry forward including centralized identity and policy enforcement. Regardless of the development approach, the same intelligence, runtime, governance, and operational capabilities can be reused across the platform. Where agents run: one platform, multiple runtime choices Match the runtime to the requirement A mature enterprise platform must support more than one runtime pattern. Some agents need elastic cloud scale. Others need local execution because of latency, data sensitivity, offline operation, or regulated environments. Some need to interact with legacy applications that do not expose APIs. Runtime should be selected based on business, operational, and regulatory requirements rather than tooling limitations. Build path and runtime path should vary independently over a shared foundation. The ability to deploy the same agent architecture across multiple runtime environments helps organizations balance performance, compliance, and operational flexibility. Local / edge (Foundry Local, Windows AI): Local or edge execution supports scenarios where data sensitivity, latency, offline access, regulatory requirements, disconnected operation or device-specific context matter. Examples include on-device models, Windows AI capabilities, and local execution for regulated or disconnected environments. Cloud runtime (Azure / Copilot stack): supports scalable, API-driven agents with multi-agent orchestration running in Azure and Copilot with the default for enterprise workflows, multi-agent orchestration, connected systems, and data-connected scenarios that need elasticity. Cloud PC (Windows 365 agents): enables agents to operate in managed desktop environments. agents run on a Windows 365 Cloud PC using a check-out/check-in model, driving UI automation, browsers, and legacy apps as a human operator would in a managed and governed environment. This is the bridge to systems that expose no API, the agent operates the actual application UI in a governed, isolated desktop. Foundation layer: shared trust fabric The enterprise foundation for intelligence and trust The same enterprise services that secure, govern, and operate modern organizations now extend to agents, creating a shared foundation for both intelligence and trust. This inheritance model allows organizations to extend existing investments in identity, governance, security, compliance, and operations directly to agent systems rather than introducing a separate control model for AI. Key foundation services include: Microsoft Graph – Provides agents the context across users, groups, files, meetings, messages, relationships, and activity signals. It gives agents a permission-aware understanding of work, not just isolated documents. Microsoft Entra – Agents are governed using the same identity fabric that governs users, devices, apps, and resources enabling role-based and attribute-based access control plus risk-based Conditional Access policies. Microsoft Fabric - Governed data, analytics, semantic models, and business metrics. Foundry includes SharePoint and Microsoft Fabric among its built-in tools. Agents reason over trusted business definitions instead of disconnected raw tables. Microsoft Purview - Data protection, sensitivity labeling, DLP, compliance, and governance. Agent 365 uses Microsoft Purview for data protection and compliance controls on agent activity and data, complementing Microsoft Defender for threat detection and behavior monitoring. Agent interactions inherit enterprise compliance expectations. Azure - Provides enterprise-grade cloud infrastructure and operational maturity. Foundry emphasizes centralized observability, traces, evaluated runs, and production performance monitoring with full traceability for enterprise-scale security, audit, and compliance requirements. Microsoft 365 - Brings agents into the tools where employees already work. Agents can be surfaced in the productivity tools users already leverage. Dynamics 365 - Business application context for sales, service, finance, supply chain, and operations. Grounds agents in business processes and systems of record. Power Platform - Low-code apps, automation, connectors, and business process integration — reachable via Foundry through Azure Logic Apps integration with more than 1,400 connectors. Business technologists can extend agent workflows without building everything in code. GitHub - Developer workflows, repositories, pull requests, code context, and DevOps integration. Extends agentic assistance into software development lifecycle. Windows & Windows 365 - Endpoint and Cloud PC environments for local, desktop, and legacy app scenarios. Extends agent reach beyond APIs into managed desktop execution patterns. Alongside these services, Agent 365 and the Foundry Control Plane provide the trust layer for enterprise agents, combining security, governance, compliance, and Responsible AI with centralized visibility, policy enforcement, lifecycle management, and secure AI operations from development through production. End-to-end request journey: how the layers work together The true value of the platform emerges when all the layers work together as a coordinated system. Intelligence emerges from the combined effect of experience, domain specialization, grounding, memory, models, orchestration, runtime, and foundation. An example request, from a user - “Reconcile last month's receivables and flag anomalies for my region." Experience - The user asks from Microsoft 365 Copilot or a finance workflow surface, the agent is reached through the same stable endpoint used across Microsoft 365 and Teams. Identity context - The platform attaches user identity, and, for the agent, its Microsoft Entra Agent ID assigned in Foundry. Agent selection - A finance agent interprets the goal. If the request spans domains, Copilot Studio generative orchestration decomposes it into a plan, choosing tools, topics, knowledge sources, or connected agents. Grounding - Fabric IQ provides receivables data and metric definitions; Work IQ provides relevant approvals and prior decisions; Foundry IQ provides reconciliation rules and policy knowledge; Web IQ can add external signals when needed. Model routing - The Foundry Model Router selects the model per turn. A simple classification step goes to a nano-tier model; anomaly reasoning routes to a mid-tier model; multi-document synthesis routes to a frontier model, all through one endpoint with zero routing logic. Guardrails - Foundry guardrails scan user input, tool calls, tool responses, and final output for defined risks and take the configured action (annotate or annotate-and-block). Tool use - The agent queries systems, invokes reconciliation logic, runs anomaly detection, or calls another specialist agent via Copilot Studio connected agents or Foundry's MCP integration. Runtime execution - The workflow runs in cloud, local, or Windows 365 Cloud PC environments depending on system access, data sensitivity, latency, and legacy application constraints. Response - The agent returns a reconciled view, flagged anomalies, rationale, and recommended next steps — with citations pulled from the knowledge layer for transparency. Bridge to Trust - Every action generated by the agent remains observable, governable, and auditable through the platform's trust capabilities, which are explored further in Part 2. Conclusion The hard problem in enterprise AI was never obtaining a capable model; it was grounding that model in governed enterprise context, enabling it to act through governed tools, and doing so within the security, compliance, and operational controls organizations already rely on. Microsoft's answer is a platform approach: a dedicated grounding tier through the IQ Platform, a flexible intelligence layer spanning models, memory, routing, orchestration, and guardrails, specialized agent families aligned to business domains, a build-to-run continuum spanning no-code to pro-code, and a shared trust foundation that every agent inherits. Integrate once with this fabric, and the payoff compounds: one identity model, one grounding tier, and one governance spine become reusable across every persona surface, every agent family, every build-and-run target. Coming next — Part 2: Trust Intelligence is only half the equation. In Part 2 we turn to the other axis: how Microsoft secures and governs every component of an agent - models, tools, MCP connectors, memory, and orchestration across the full lifecycle.
