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.
Agent Credit Limits and Alerts - Copilot Studio
Hi everyone, We're evaluating the use of Agent Credit Limits and alert notifications in the Power Platform Admin Center as a way to control unexpected Copilot Credit consumption. Recently, we had an agent consume 668k Copilot Credits in just 3 days, which raised concerns about how quickly usage can grow before administrators become aware of it. My questions are: How frequently is Copilot Credit consumption evaluated against an agent's credit limit? Are alert notifications generated in near real-time, or are they dependent on the same reporting pipeline used by the consumption reports? If an agent reaches its configured credit limit, is it automatically turned off or blocked from further consumption? Given that consumption reports often appear to refresh hours later (or even the next day), can alerts also be delayed? If there is a reporting delay, is there a risk that an agent could significantly exceed the intended limit before administrators receive a notification? What is the recommended approach for preventing large unexpected consumption spikes in production? Has anyone successfully implemented a governance model that provides more immediate protection against runaway usage, or are the current credit limits and alerts primarily intended for retrospective monitoring? Thanks in advance for any guidance.
Windows 11 Microsoft Account authentication fails system-wide – WAM/Sign-in issue
Hello, I am experiencing a system-wide Microsoft account authentication/sign-in problem on Windows 11 25H2. Microsoft Support has already assisted me with extensive troubleshooting and recommended that I report the issue here because the problem appears to be related to the Microsoft account authentication/sign-in process rather than to a specific Windows user profile. Main issue I am currently using a local Windows account. When I go to Settings > Accounts > Your info > Sign in with a Microsoft account instead, the process eventually asks me to authenticate my existing local Windows account. The password for my local account is definitely correct and works normally on the Windows sign-in screen. However, the same password is rejected during the Microsoft account linking/conversion process. The problem is not limited to my Windows user profile. To test this, I created a completely new local Windows test account. The exact same problem occurs there as well: the local password works for signing in to Windows, but is rejected when attempting to link/convert the local account to a Microsoft account. This strongly suggests that the issue is system-wide rather than caused by corruption of my individual Windows user profile. Additional Microsoft authentication issue I also tried to submit this problem through the Windows Feedback Hub. During the submission process, Windows Security asks me to verify my identity for my Microsoft account using my Windows Hello PIN. My correct Windows Hello PIN is rejected with the message that the PIN is incorrect. Therefore, I cannot submit the report through the Feedback Hub. At the same time, I can successfully sign in to my Microsoft account through a web browser. In fact, I was able to sign in to the Microsoft Tech Community through the browser in order to submit this report. Additional symptoms that have now appeared The problem is no longer limited to linking my Microsoft account to Windows: Outlook is no longer reliably receiving new emails. Microsoft Word can no longer save documents. Feedback Hub cannot authenticate my Microsoft account because the correct Windows Hello PIN is rejected. Microsoft account authentication through the web browser continues to work normally. These additional symptoms make me suspect that there may be a common problem with Microsoft account authentication, WAM (Web Account Manager), the account broker, or another Windows authentication component. Troubleshooting already performed Extensive troubleshooting has already been carried out: The problem was reproduced with a newly created local Windows test account. The local account password was verified and works correctly at the Windows sign-in screen. SFC was run and did not identify an unresolved system-file corruption problem. DISM was run and the component store was repaired/checked. A Windows 11 repair installation was already performed. The problem remained afterward. Relevant Microsoft account/authentication components and services were checked. Microsoft Account Sign-in Assistant, WAM-related components, Account Control/Credential Provider-related components and associated services were checked and appear to be present/running. Credential-related services, including Credential Manager/Vault-related components and TokenBroker, were checked. The issue persists across multiple local Windows accounts. Microsoft Support has therefore concluded that this does not appear to be a simple user-profile corruption issue and may instead involve the Microsoft account linking/authentication pipeline. Current situation Windows 11 25H2 is otherwise running, and my Microsoft account itself is accessible through the browser. However, Microsoft account authentication within Windows appears to fail in several places. I would therefore appreciate assistance in determining whether this is a WAM/account broker/Microsoft account authentication issue and how the affected Windows authentication components can be repaired or reset without reinstalling Windows from scratch. Please let me know if diagnostic logs, event logs, correlation IDs, or any other information would be useful. I can provide additional diagnostic information if required. Thank you.
I need to speak to a person at Microsoft
Firstly, I don't know if this is the correct place to ask, if not, I apologise, and would be greratful if I could be directed to the correct medium. So..... *** I am writing this on behalf of someone else *** His account has been locked after he had been hacked and infected with a virus, and Microsoft will not unlock it. However, they have decided (today) to take his money for his 365 subscription, that he can't use, and doesn't want. When looking for a way to cancel it, the answer is log-in to his account and cancel it himself. BUT, he can't log in because the account is locked. He has tried looking for a phone number to speak to someone, but cannot find any. He has tried looking for a Live Chat, but, (if it exists) it is only available after he logs in. He just wants to cancel the subscription, and get a refund. Can someone please give me a contact number - preferably in the UK, but any English speaking representitive, in any countrty will do. Thanks,Windows 11, version 26H2 security baseline
You can download the baseline package from the Microsoft Security Compliance Toolkit, test the recommended configurations in your environment, and customize / implement them as appropriate. Summary of Changes This release includes several changes since the Security baseline for Windows 11, version 25H2 that further strengthen enterprise security and align the baseline with current platform capabilities and industry standards. These changes are summarized in the table below. Security Policy Change Summary Printer\Configure Windows Ready Print driver ranking Configured as “Enabled” to reduce reliance on third-party print drivers in the stack, narrowing the overall print driver attack surface. Internet Explorer\Internet Control Panel\Advanced Page\Turn off encryption support Updated from TLS 1.1 and TLS 1.2 to TLS 1.2 and TLS 1.3 to align with current security standards. Windows Ready Print driver ranking Configure Windows Ready Print driver ranking" is the newly added setting under Administrative Templates\Printers to control whether Windows prefers the modern inbox IPP class driver over third-party OEM drivers when installing new printers. We recommend enabling this policy to reduce reliance on third-party print drivers in the stack, narrowing the overall print driver attack surface. Note that driver ranking applies when printers are installed via a connection method that supports IPP, such as USB or network multicast discovery. In those cases, if the printer supports IPP, Windows will install using the class driver even if a vendor V3/V4 driver is available. If the printer doesn't support IPP, or is installed directly as a TCP/IP printer, there's no change in behavior. Encryption Support We have updated the policy "Turn off encryption support" to allow only TLS 1.2 and TLS 1.3. Previous baseline releases permitted TLS 1.1 and TLS 1.2; however, TLS 1.1 is now considered obsolete and is no longer recommended for enterprise environments. This change aligns the security baseline with modern cryptographic standards while maintaining compatibility with widely deployed services that support current TLS versions. Please let us know your thoughts by commenting on this post or through the Security Baseline Community.I built a free, open-source M365 security assessment tool - looking for feedback
I work as an IT consultant, and a good chunk of my time is spent assessing Microsoft 365 environments for small and mid-sized businesses. Every engagement started the same way: connect to five different PowerShell modules, run dozens of commands across Entra ID, Exchange Online, Defender, SharePoint, and Teams, manually compare each setting against CIS benchmarks, then spend hours assembling everything into a report the client could actually read. The tools that automate this either cost thousands per year, require standing up Azure infrastructure just to run, or only cover one service area. I wanted something simpler: one command that connects, assesses, and produces a client-ready deliverable. So I built it. What M365 Assess does https://github.com/Daren9m/M365-Assess is a PowerShell-based security assessment tool that runs against a Microsoft 365 tenant and produces a comprehensive set of reports. Here is what you get from a single run: 57 automated security checks aligned to the CIS Microsoft 365 Foundations Benchmark v6.0.1, covering Entra ID, Exchange Online, Defender for Office 365, SharePoint Online, and Teams 12 compliance frameworks mapped simultaneously -- every finding is cross-referenced against NIST 800-53, NIST CSF 2.0, ISO 27001:2022, SOC 2, HIPAA, PCI DSS v4.0.1, CMMC 2.0, CISA SCuBA, and DISA STIG (plus CIS profiles for E3 L1/L2 and E5 L1/L2) 20+ CSV exports covering users, mailboxes, MFA status, admin roles, conditional access policies, mail flow rules, device compliance, and more A self-contained HTML report with an executive summary, severity badges, sortable tables, and a compliance overview dashboard -- no external dependencies, fully base64-encoded, just open it in any browser or email it directly The entire assessment is read-only. It never modifies tenant settings. Only Get-* cmdlets are used. A few things I'm proud of Real-time progress in the console. As the assessment runs, you see each check complete with live status indicators and timing. No staring at a blank terminal wondering if it hung. The HTML report is a single file. Logos, backgrounds, fonts -- everything is embedded. You can email the report as an attachment and it renders perfectly. It supports dark mode (auto-detects system preference), and all tables are sortable by clicking column headers. Compliance framework mapping. This was the feature that took the most work. The compliance overview shows coverage percentages across all 12 frameworks, with drill-down to individual controls. Each finding links back to its CIS control ID and maps to every applicable framework control. Pass/Fail detail tables. Each security check shows the CIS control reference, what was checked, what the expected value is, what the actual value is, and a clear Pass/Fail/Warning status. Findings include remediation descriptions to help prioritize fixes. Quick start If you want to try it out, it takes about 5 minutes to get running: # Install prerequisites (if you don't have them already) Install-Module Microsoft.Graph, ExchangeOnlineManagement -Scope CurrentUser Clone and run git clone https://github.com/Daren9m/M365-Assess.git cd M365-Assess .\Invoke-M365Assessment.ps1 The interactive wizard walks you through selecting assessment sections, entering your tenant ID, and choosing an authentication method (interactive browser login, certificate-based, or pre-existing connections). Results land in a timestamped folder with all CSVs and the HTML report. Requires PowerShell 7.x and runs on Windows (macOS and Linux are experimental -- I would love help testing those platforms). Cloud support M365 Assess works with: Commercial (global) tenants GCC, GCC High, and DoD environments If you work in government cloud, the tool handles the different endpoint URIs automatically. What is next This is actively maintained and I have a roadmap of improvements: More automated checks -- 140 CIS v6.0.1 controls are tracked in the registry, with 57 automated today. Expanding coverage is the top priority. Remediation commands -- PowerShell snippets and portal steps for each finding, so you can fix issues directly from the report. XLSX compliance matrix -- A spreadsheet export for audit teams who need to work in Excel. Standalone report regeneration -- Re-run the report from existing CSV data without re-assessing the tenant. I would love your feedback I have been building this for my own consulting work, but I think it could be useful to the broader community. If you try it, I would genuinely appreciate hearing: What checks should I prioritize next? Which security controls matter most in your environment? What compliance frameworks are most requested by your clients or auditors? How does the report land with non-technical stakeholders? Is the executive summary useful, or does it need work? macOS/Linux users -- does it run? What breaks? I have tested it on macOS, but not extensively. Bug reports, feature requests, and contributions are all welcome on GitHub. Repository: https://github.com/Daren9m/M365-Assess License: MIT (free for commercial and personal use) Runtime: PowerShell 7.x Thanks for reading. Happy to answer any questions in the comments.Microsoft Intune Settings Catalog updated to support Windows 11, version 26H2
10.06.26 Update: The Windows security baseline for Windows 11, version 26H2 is now available for all customers in Microsoft Intune. This baseline reflects current Microsoft security recommendations and is the latest available Windows security baseline in Intune. Windows 11, version 26H2 is now available, and Microsoft Intune provides day zero support for validated Windows policy settings in the settings catalog. We continue to invest in the settings catalog infrastructure to ensure timely support for new Windows policy settings. This enables organizations to adopt new OS versions and features without delay and maintain secure, compliant, and well-managed environments. Settings catalog support for Windows 11, version 26H2 As part of Windows 11, version 26H2 settings catalog support, the settings catalog now includes all newly released settings and updates to existing settings introduced with the latest Windows 11, version 26H2 release. The following table highlights settings that are now available for configuration in the settings catalog and ready to use in device configuration profiles for Windows endpoints. While this update aligns with Windows 11, version 26H2 support, not every setting listed is a new 26H2 feature; some are existing Windows settings that are now available for management through the settings catalog. Category Policy Name Friendly Name Above Lock ConfigureAudioOnLockScreen Configure Audio On Lock Screen Application Management EnableMsixAllowedZones Enable MSIX Allowed Zones Device Lock ClearTextPassword Clear Text Password Device Lock RelaxMinimumPasswordLengthLimits Relax Minimum Password Length Limits Printers ConfigureWindowsReadyPrintDriverRanking Configure Windows Ready Print Driver Ranking Privacy LetAppsAccessForegroundText Let Apps Access Foreground Text Privacy LetAppsAccessForegroundText_ForceAllowTheseApps Let Apps Access Foreground Text – Force Allow These Apps Privacy LetAppsAccessForegroundText_ForceDenyTheseApps Let Apps Access Foreground Text – Force Deny These Apps Privacy LetAppsAccessForegroundText_UserInControlOfTheseApps Let Apps Access Foreground Text – User In Control Of These Apps Windows Update IgnoreWindowsUpdateGroupPolicies Ignore Windows Update Group Policies Windows Update SetMaxPauseDays Set Max Pause Days What this means for administrators Administrators can find the new settings within the settings catalog in the Microsoft Intune admin center under Devices > Manage devices > Configuration > Create > New policy. Select Windows 10 and later for the platform and settings catalog for the profile type. Before deploying Windows 11, version 26H2: Review the new and updated settings that apply to your organization. Test configuration profiles with a representative device group. Confirm that the targeted Windows edition and version support each setting. Monitor profile deployment and device status after assignment. Windows 11, version 26H2 security baseline Windows 11 version 26H2 security baseline will also be made available shortly in Intune. We are validating the final recommendations and plan to make the updated baseline available over the coming days following the Windows 11, version 26H2 release. The current baseline includes: A new recommendation for Configure Windows Ready Print driver ranking. An updated Turn off encryption support recommendation that changes the supported Transport Layer Security versions from TLS 1.1 and 1.2 to TLS 1.2 and 1.3. Configure NetBIOS settings - This setting is pending availability in the settings catalog and will be added to the baseline in a future update. Learn more Create a policy using settings catalog in Microsoft Intune Windows 11 - release information Learn about Intune security baselines for Windows devices We welcome your feedback. If you have questions about these settings or Windows 11, version 26H2 management in Intune, leave a comment on this post or follow us on LinkedIn or @MSIntune and @IntuneSuppTeam on X to continue the conversation. Post updates: 10/06/26: The Windows security baseline for Windows 11, version 26H2 is now available in Microsoft Intune. We’ve also updated this post with the Settings Catalog additions introduced as part of Windows 11, version 26H2 support.
Windows 11 Remote Terminal server with a custom port across the internet
Hi All I have the need to connect to a windows 11 box across the internet using RDP for a short period of time I have changed the default port from 3389 to 44710. I have tested this change on the local LAN and workes fine using the RDP App with the connection string of 192.x.x.x.:44710 I have configured my firewall to look like this (I will restrict the source when I get it working) I have configured the windows firewall on the windows 11 machine like this When I try to connect over the internet I immediately get prompted for credentials but all that happens is Anyone have any ideas as to what I can do to make this work? thanks for any help or advice Gary
