For most enterprises adopting AI, Microsoft AI agents are the first agents in production. Copilot Studio makes it possible for a non-technical user to build and deploy an agent in an afternoon. Foundry extends that into more custom workflows. Power Apps adds another path. The result, for cybersecurity leaders, is that the first agent estate they have to govern is one they did not build, and one that grows faster than any approval workflow can keep up with.
This is the workload we see most often at Opsin: a CISO who knows Microsoft Copilot is in production, knows agents are being built on top of it, and does not yet have a way to answer who owns a given agent, what data it can reach, or whether anyone is accountable when it behaves unexpectedly.
Securing Microsoft AI agents is not the same workload as securing a SaaS application or a traditional service account. Three architectural properties make it different.
First, the identity model. A Microsoft AI agent is a non-human identity that often acts on behalf of a human user through delegation models such as Microsoft's On-Behalf-Of, which means its effective permissions are inherited rather than declared. A Copilot response can surface a SharePoint document that the invoking user is technically entitled to retrieve but never expected to see, simply because the agent walked the permission graph faster than the user ever would.
Second, the data scope is implicit. Agents do not have a fixed data perimeter. They reach across SharePoint, OneDrive, Teams, Outlook, and any connectors the business has wired into Copilot Studio or Foundry. The data scope of any given agent is a function of the identity it acts as and the connectors it has access to, and that scope changes whenever permissions change anywhere upstream.
Third, behavior is non-deterministic. Two functionally identical prompts can return different content depending on retrieval, context window, and downstream tool calls. That makes after-the-fact triage of agent behavior labor-intensive, and it is why the conversation among security teams is moving toward continuous monitoring of what agents are actually doing, not only what they are configured to do.
These properties combine into a workload that looks less like application security and more like a hybrid of identity governance, data security posture management, and behavioral analysis, applied to a population of non-human actors that is growing inside the enterprise every week.
Microsoft has invested heavily in the building blocks. Entra establishes a unique identity for each agent and extends conditional access. Purview adds Data Security Posture Management for agents and provides sensitivity-label enforcement during agent interactions. Defender contributes anomaly detection. Microsoft Agent 365, currently in preview, is the architectural attempt to unify these into a single control plane.
The native capabilities are real, and for many environments they are the right place to start. Where we see security teams hit limits is in three patterns.
These gaps are not criticisms of the Microsoft stack. They are the natural consequence of building a control plane for an emerging category in parallel with the agents it is meant to govern. They are also why most CISOs we work with end up combining native Microsoft tooling with a dedicated layer focused on agent behavior and data exposure.
When Opsin runs a proactive risk assessment on a Microsoft Copilot environment, the findings concentrate in a small number of categories.
Oversharing is the most consistent. Legacy SharePoint permissions, inherited group memberships, and overly broad sensitivity-label scopes routinely cause Copilot to surface content the invoking user did not expect to retrieve. Before Culligan rolled out Copilot broadly, this kind of exposure represented roughly 80% of the queries we tested. After working through the underlying permissions and label issues, the same testing showed it dropped to under 15%.
Weak or absent authentication on agents is the second category. Copilot Studio allows administrators to choose the authentication level for an agent, including options that permit unauthenticated access. Agents published to public channels with weak or absent authentication accumulate quietly, often without an assigned human owner.
Agents without clear ownership are the third. In environments where Copilot Studio adoption has outrun security review, it is common to find agents that no one in the organization can confidently claim. When something goes wrong, there is no human accountable for remediation, and no one with the authority to retire the agent.
These three patterns are the practical face of what the broader industry now calls agent sprawl. They turn Microsoft AI agent security from a strategic conversation into a weekly operational discipline.
Recent industry research has been pointing in the same direction. In the Gartner® May 2026 research report, How to Secure Microsoft AI Agents, Gartner notes that "agent sprawl is therefore a major problem" and frames the unauthenticated-agent risk vividly, observing that unauthenticated or shared credentials for Microsoft agents "risk turning into the new S3 open buckets."
Gartner's Strategic Planning Assumption in the same research is that "by 2028, more than 50% of organizations with a predominance of Microsoft AI agents will rely on Microsoft tools to protect such agents."
In our reading, that assumption is consistent with two things we already see in the field. Most Microsoft-heavy enterprises will lean on the native stack as the foundation for Microsoft AI agent security. And most of those same enterprises will need additional capability on top, because their agent estates are mixed, their security requirements exceed what native tooling currently delivers, or their licensing posture makes a Microsoft-only approach impractical.
Opsin is referenced in How to Secure Microsoft AI Agents among third-party products that, in Gartner's words, "specialize in preventing information leakage and oversharing by Microsoft Copilot and AI Agents."
We view that reference as a reflection of where we focus: helping security teams secure the sanctioned Microsoft AI deployments they already have, through proactive risk assessment, contextual visibility, and root-cause remediation.
Our approach centers on what we call the dynamic contextual layer. The premise is that Microsoft AI agent security gets meaningfully easier when identity, data, and model behavior are joined in one view. That join is what lets a security team distinguish a Copilot response that happened to retrieve a sensitive document from one that did so because of an upstream permission misconfiguration that will keep happening until it is fixed.
In a Microsoft environment, that takes a few concrete forms. We connect to Microsoft Copilot and Copilot Studio via API. We surface agents alongside their configuration, ownership, and data scope. We simulate real user queries against sanctioned AI deployments to identify exposure within 24 hours. We correlate findings with Microsoft Entra identity and Microsoft Purview data sensitivity so issues are prioritized by exposure scope, not alert volume. And we route each issue to a clear human owner with remediation guidance, so security teams are not the bottleneck for closing it.
The same contextual layer extends across the rest of the agent estate, including ChatGPT Enterprise, Claude, Google Gemini, and custom agent frameworks. That breadth matters because the mixed agent estate is now the default, and any Microsoft-only security strategy will produce a Microsoft-only view of risk.
Microsoft AI agent security is settling into something more like a discipline than a project. The agents are not going to slow down. The native tooling will continue to mature, and so will the third-party layer alongside it. The enterprises that handle this well will treat Microsoft AI agents as the first stage of a broader agent estate, build a contextual view that spans identity, data, and behavior, and design their controls to extend cleanly to whatever they adopt next.
For cybersecurity leaders, the question is no longer whether Microsoft AI agents will operate inside the perimeter. They already do. The question is whether the governance model can keep pace with how fast the business is building on top of them.
Gartner, How to Secure Microsoft AI Agents, Dionisio Zumerle, Avivah Litan, 13 May 2026.
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
GARTNER is a trademark of Gartner, Inc. and its affiliates.
For most enterprises adopting AI, Microsoft AI agents are the first agents in production. Copilot Studio makes it possible for a non-technical user to build and deploy an agent in an afternoon. Foundry extends that into more custom workflows. Power Apps adds another path. The result, for cybersecurity leaders, is that the first agent estate they have to govern is one they did not build, and one that grows faster than any approval workflow can keep up with.
This is the workload we see most often at Opsin: a CISO who knows Microsoft Copilot is in production, knows agents are being built on top of it, and does not yet have a way to answer who owns a given agent, what data it can reach, or whether anyone is accountable when it behaves unexpectedly.
Securing Microsoft AI agents is not the same workload as securing a SaaS application or a traditional service account. Three architectural properties make it different.
First, the identity model. A Microsoft AI agent is a non-human identity that often acts on behalf of a human user through delegation models such as Microsoft's On-Behalf-Of, which means its effective permissions are inherited rather than declared. A Copilot response can surface a SharePoint document that the invoking user is technically entitled to retrieve but never expected to see, simply because the agent walked the permission graph faster than the user ever would.
Second, the data scope is implicit. Agents do not have a fixed data perimeter. They reach across SharePoint, OneDrive, Teams, Outlook, and any connectors the business has wired into Copilot Studio or Foundry. The data scope of any given agent is a function of the identity it acts as and the connectors it has access to, and that scope changes whenever permissions change anywhere upstream.
Third, behavior is non-deterministic. Two functionally identical prompts can return different content depending on retrieval, context window, and downstream tool calls. That makes after-the-fact triage of agent behavior labor-intensive, and it is why the conversation among security teams is moving toward continuous monitoring of what agents are actually doing, not only what they are configured to do.
These properties combine into a workload that looks less like application security and more like a hybrid of identity governance, data security posture management, and behavioral analysis, applied to a population of non-human actors that is growing inside the enterprise every week.
Microsoft has invested heavily in the building blocks. Entra establishes a unique identity for each agent and extends conditional access. Purview adds Data Security Posture Management for agents and provides sensitivity-label enforcement during agent interactions. Defender contributes anomaly detection. Microsoft Agent 365, currently in preview, is the architectural attempt to unify these into a single control plane.
The native capabilities are real, and for many environments they are the right place to start. Where we see security teams hit limits is in three patterns.
These gaps are not criticisms of the Microsoft stack. They are the natural consequence of building a control plane for an emerging category in parallel with the agents it is meant to govern. They are also why most CISOs we work with end up combining native Microsoft tooling with a dedicated layer focused on agent behavior and data exposure.
When Opsin runs a proactive risk assessment on a Microsoft Copilot environment, the findings concentrate in a small number of categories.
Oversharing is the most consistent. Legacy SharePoint permissions, inherited group memberships, and overly broad sensitivity-label scopes routinely cause Copilot to surface content the invoking user did not expect to retrieve. Before Culligan rolled out Copilot broadly, this kind of exposure represented roughly 80% of the queries we tested. After working through the underlying permissions and label issues, the same testing showed it dropped to under 15%.
Weak or absent authentication on agents is the second category. Copilot Studio allows administrators to choose the authentication level for an agent, including options that permit unauthenticated access. Agents published to public channels with weak or absent authentication accumulate quietly, often without an assigned human owner.
Agents without clear ownership are the third. In environments where Copilot Studio adoption has outrun security review, it is common to find agents that no one in the organization can confidently claim. When something goes wrong, there is no human accountable for remediation, and no one with the authority to retire the agent.
These three patterns are the practical face of what the broader industry now calls agent sprawl. They turn Microsoft AI agent security from a strategic conversation into a weekly operational discipline.
Recent industry research has been pointing in the same direction. In the Gartner® May 2026 research report, How to Secure Microsoft AI Agents, Gartner notes that "agent sprawl is therefore a major problem" and frames the unauthenticated-agent risk vividly, observing that unauthenticated or shared credentials for Microsoft agents "risk turning into the new S3 open buckets."
Gartner's Strategic Planning Assumption in the same research is that "by 2028, more than 50% of organizations with a predominance of Microsoft AI agents will rely on Microsoft tools to protect such agents."
In our reading, that assumption is consistent with two things we already see in the field. Most Microsoft-heavy enterprises will lean on the native stack as the foundation for Microsoft AI agent security. And most of those same enterprises will need additional capability on top, because their agent estates are mixed, their security requirements exceed what native tooling currently delivers, or their licensing posture makes a Microsoft-only approach impractical.
Opsin is referenced in How to Secure Microsoft AI Agents among third-party products that, in Gartner's words, "specialize in preventing information leakage and oversharing by Microsoft Copilot and AI Agents."
We view that reference as a reflection of where we focus: helping security teams secure the sanctioned Microsoft AI deployments they already have, through proactive risk assessment, contextual visibility, and root-cause remediation.
Our approach centers on what we call the dynamic contextual layer. The premise is that Microsoft AI agent security gets meaningfully easier when identity, data, and model behavior are joined in one view. That join is what lets a security team distinguish a Copilot response that happened to retrieve a sensitive document from one that did so because of an upstream permission misconfiguration that will keep happening until it is fixed.
In a Microsoft environment, that takes a few concrete forms. We connect to Microsoft Copilot and Copilot Studio via API. We surface agents alongside their configuration, ownership, and data scope. We simulate real user queries against sanctioned AI deployments to identify exposure within 24 hours. We correlate findings with Microsoft Entra identity and Microsoft Purview data sensitivity so issues are prioritized by exposure scope, not alert volume. And we route each issue to a clear human owner with remediation guidance, so security teams are not the bottleneck for closing it.
The same contextual layer extends across the rest of the agent estate, including ChatGPT Enterprise, Claude, Google Gemini, and custom agent frameworks. That breadth matters because the mixed agent estate is now the default, and any Microsoft-only security strategy will produce a Microsoft-only view of risk.
Microsoft AI agent security is settling into something more like a discipline than a project. The agents are not going to slow down. The native tooling will continue to mature, and so will the third-party layer alongside it. The enterprises that handle this well will treat Microsoft AI agents as the first stage of a broader agent estate, build a contextual view that spans identity, data, and behavior, and design their controls to extend cleanly to whatever they adopt next.
For cybersecurity leaders, the question is no longer whether Microsoft AI agents will operate inside the perimeter. They already do. The question is whether the governance model can keep pace with how fast the business is building on top of them.
Gartner, How to Secure Microsoft AI Agents, Dionisio Zumerle, Avivah Litan, 13 May 2026.
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
GARTNER is a trademark of Gartner, Inc. and its affiliates.
.png)
