Cyber Strategy
Cyber Secure
Cyber Operations
Cyber Response
Cyber ResilienceThe AI agent boom and its security blind spots
Across the enterprise, a quiet shift is under way. With Microsoft Copilot Studio, building an AI agent no longer requires a development team. A manager in finance, a coordinator in HR, or an analyst in operations can describe what they want in plain language and, within an afternoon, stand up an assistant that reads the company’s documents, answers on behalf of a department, and takes actions in live business systems. The productivity case is obvious, and adoption is moving quickly.
What moves more slowly is the security understanding that should travel with it. An agent built this way is not a simple chatbot. It holds an identity, inherits real permissions, reads untrusted content, and calls tools that touch sensitive data. Each of those capabilities is useful, and each is a new way for the agent to be turned against the organisation that deployed it.
This article examines Microsoft Copilot Studio agents through the eyes of an attacker: how these agents are actually built, where the security weaknesses live, what real-world incidents have already shown, the patterns that recur when such agents are tested, and the practical steps that make a deployment defensible. The goal is not to discourage adoption. It is to help security and platform teams deploy these agents with their eyes open.
What's inside a Copilot Studio agent
To understand where an agent can fail, it helps to understand what it is made of. A Copilot Studio agent is an assembly of parts that a maker wires together and that a language model stitches into behaviour at runtime. It runs inside Microsoft’s Power Platform, stores its definition and data in Dataverse, and authenticates everyone through Microsoft Entra ID. Five building blocks matter most.
- The model and its instructions
- The model. The reasoning engine, an Azure OpenAI model with Anthropic models available as an external option, interprets each request and decides what to do.
- The instructions. A natural-language system prompt sets the agent’s tone, its scope, and which objects it should call.
The instructions are where the guardrails live, and they are only as strong as the model’s willingness to follow them. A determined prompt can often talk a model out of its own rules, which is why instructions alone are never a security control. They are guidance, not a boundary.
- Knowledge sources
- Grounding. The agent answers from connected sources such as SharePoint, OneDrive, Dataverse, uploaded files, public websites, and Microsoft Graph connectors.
- Retrieval. At query time the agent retrieves the most relevant content, summarises it, and cites the source.
Knowledge is the agent’s view of the world, and it is a double-edged capability. Untrusted content pulled into that view can carry hidden instructions the agent then follows, and content that is too broadly accessible becomes a disclosure risk the moment a user asks the right question.
- Tools, connectors, and actions
- Connectors. The agent can call from a large library of Power Platform connectors, plus custom REST and OpenAPI actions, Power Automate flows, and Model Context Protocol servers.
- Credentials. Tools run either with the end user’s identity, which is least privilege, or, if the maker chooses, with the maker’s own credentials.
Tools are the agent’s hands. They are what turn a conversational mistake into a real action against a real system, and the choice of whose credentials a tool runs under is one of the most consequential security decisions a maker makes, often without realising it.
- Generative orchestration
Modern agents use generative orchestration, in which a language-model planner decides which knowledge sources, tools, and connected agents to invoke for a given request. It makes those choices by reading the names and descriptions of each object, not by matching fixed phrases. Microsoft’s own guidance stresses that names matter more than anything. For an attacker, that is a clear signal: if behaviour is driven by natural-language descriptions, then natural-language manipulation is the way in.
- Channels, identity, and autonomous triggers
- Channels. An agent can be published to Microsoft Teams, Microsoft 365 Copilot, a public website, and other surfaces, with authentication ranging from full Entra sign-in to none at all.
- Triggers. An agent can also run automatically on events, such as a new email or a new record, with no human in the loop.
Autonomous, event-triggered runs change the trust model quietly. Microsoft documents that these runs authenticate with the maker’s credentials rather than the end user’s, which means every user of such an agent effectively borrows the builder’s reach. This is the classic confused-deputy condition, built into the product by design.
Where the risk lives
Set against that anatomy, the ways an agent can be attacked fall into a handful of themes. They map cleanly onto two industry frameworks a technical reader will recognise: the OWASP Top 10 for Large Language Model Applications, and the newer OWASP Top 10 for Agentic Applications, published at the end of 2025. The fact that the security community now maintains a separate top ten for agents shows that the industry has stopped treating them as ordinary chatbots.
- Prompt injection, direct and indirect
Direct injection is a user jailbreaking the agent in front of them. The more dangerous form is indirect injection, where malicious instructions arrive inside the content the agent retrieves, such as a document, an email, or a web page. The maker never sees them and the victim never types them. Because an enterprise agent combines autonomous tool use, delegated permissions, and untrusted retrieved content in one place, a single planted instruction can steer the agent for every user who later relies on it.
- Data exfiltration
Once an injection controls the agent’s output, the attacker needs a way to move data out. The recurring channels are rendering tricks: an image whose web address quietly carries stolen data, a styling declaration that does the same when the output is displayed, or a tool call whose parameters smuggle the content to an external endpoint. The most serious of these are zero-click, requiring no action from the victim at all.
- Oversharing and excessive access
An agent acts within the permissions of the person using it, which sounds safe until you remember how much access the average employee has quietly accumulated over the years. Broad legacy permissions, open sharing links, and broken inheritance mean that a low-privileged account, pointed at an agent, becomes an efficient discovery engine for content the user could technically reach but never knew existed. The agent did not grant new access. It removed the friction that kept that access theoretical.
- Sensitive information and system-prompt disclosure
Separate from how data leaves an agent is what leaks. Confidential documents can be pulled beyond their intended scope, personal data can surface from document metadata, and the agent’s own instructions and tool list can be coaxed out as reconnaissance for a follow-up attack. A subtle version involves the citation pane, where the agent’s text answer stays restrained while the source preview quietly renders the underlying file in full.
- Tool abuse and the confused deputy
Where an agent holds privilege and an attacker controls its input, the attacker can make it act. Over-privileged connectors, tools that run on the maker’s credentials, and server-side requests through web-request actions all turn a conversational flaw into a real action against a real system. The risk now reaches the tool supply chain itself: as agents increasingly connect to external tool servers through emerging standards such as the Model Context Protocol, a compromised or carelessly built connector becomes another way in, and 2026 has already brought a wave of disclosures in exactly that ecosystem. An agent is only as trustworthy as the tools and servers it is wired to.
- Anonymous agents and sprawl
Finally, the low-code model that makes Copilot Studio attractive also makes it easy to leave unauthenticated agents exposed on the internet and to accumulate forgotten, ownerless agents with inconsistent security postures. Each one is unmanaged attack surface that no one is watching.
This is already happening
If this sounds hypothetical, it is not. The most striking recent example arrived in June 2026, when researchers at Varonis disclosed a flaw they named SearchLeak. A single crafted link, once opened, turned Microsoft 365 Copilot into a one-click data-theft tool. A parameter in the link was read as an instruction, an attacker-controlled image slipped into the response before it was sanitised, and a request routed through a trusted search service quietly carried the data back out. Emails, multi-factor codes, calendar entries, and stored files could all leave on a single click, with the user none the wiser. Microsoft rated it critical and fixed it on the server side.
SearchLeak was not the first of its kind, and it will not be the last. A year earlier, the now-famous EchoLeak showed the same idea in its purest form. A crafted email, never knowingly acted on by the victim, was enough to make Microsoft 365 Copilot retrieve internal data and beacon it to an attacker with zero clicks. It was the first publicly documented zero-click data-theft chain in a production AI assistant, and it changed how the industry thinks about these systems.
Copilot Studio itself has not been spared. Microsoft has patched flaws in the platform, including an information-disclosure issue in early 2026 that exposed sensitive data to unauthenticated requests, and an earlier case in which the platform’s own web-request feature was coerced into reaching Microsoft’s internal infrastructure and retrieving credentials. Independent researchers have gone further, demonstrating live hijacks of customer-service agents built on Copilot Studio that leaked entire customer-record databases, and finding thousands of such agents reachable on the open internet.
The throughline across every one of these cases is the same: untrusted input, a capable agent, and a path for data to leave. The specific bug changes from one disclosure to the next. The shape of the attack does not.
The weaknesses that keep showing up
Adversarial testing of Copilot Studio agents repeatedly surfaces the same weakness classes. They are described here as general patterns rather than incidents, because the point is not any single organisation; these failures are systemic to how the platform is used today. In each case the impact can be demonstrated safely, without disrupting a live environment.
- Indirect injection to exfiltration. An agent’s own grounded content can be turned into a working data-exfiltration path by planted instructions, with no action required from the user.
- Confidential content disclosure. Agents can be made to reveal internal documents, and the structure of those documents, well beyond what their authors intended to expose.
- Personal data exposure. Names and contact details can be recovered from document metadata, the kind of information that fuels targeted social engineering.
- Instruction and scope disclosure. An agent’s own instructions and guardrail logic can be reconstructed through patient questioning, and the gaps that reveals then exploited.
- Knowledge-base enumeration. The size and naming patterns of an agent’s document store can be mapped, enabling systematic guessing of adjacent records.
- Capability abuse. Agents can be driven to generate working attacker tooling and to perform their own value-triage of what an attacker would want most.
The methods behind these failures are rarely technical exploits. They are pretexts the model wants to believe: posing as the agent’s own administrator, layering authority with urgency, asking the agent to describe rather than quote, or encoding a request so it slips past filters that only watch for obvious keywords. The lesson for defenders is uncomfortable but clear. The strongest attacks read like ordinary, reasonable requests, and the agents that fail are usually not badly built.
Agents that fail security testing are rarely badly built. They are built the way the platform encourages, which is exactly why this is an industry problem and not a one-off.
The AI agent boom and its security blind spots
Across the enterprise, a quiet shift is under way. With Microsoft Copilot Studio, building an AI agent no longer requires a development team. A manager in finance, a coordinator in HR, or an analyst in operations can describe what they want in plain language and, within an afternoon, stand up an assistant that reads the company’s documents, answers on behalf of a department, and takes actions in live business systems. The productivity case is obvious, and adoption is moving quickly.
What moves more slowly is the security understanding that should travel with it. An agent built this way is not a simple chatbot. It holds an identity, inherits real permissions, reads untrusted content, and calls tools that touch sensitive data. Each of those capabilities is useful, and each is a new way for the agent to be turned against the organisation that deployed it.
This article examines Microsoft Copilot Studio agents through the eyes of an attacker: how these agents are actually built, where the security weaknesses live, what real-world incidents have already shown, the patterns that recur when such agents are tested, and the practical steps that make a deployment defensible. The goal is not to discourage adoption. It is to help security and platform teams deploy these agents with their eyes open.
What's inside a Copilot Studio agent
To understand where an agent can fail, it helps to understand what it is made of. A Copilot Studio agent is an assembly of parts that a maker wires together and that a language model stitches into behaviour at runtime. It runs inside Microsoft’s Power Platform, stores its definition and data in Dataverse, and authenticates everyone through Microsoft Entra ID. Five building blocks matter most.
- The model and its instructions
- The model. The reasoning engine, an Azure OpenAI model with Anthropic models available as an external option, interprets each request and decides what to do.
- The instructions. A natural-language system prompt sets the agent’s tone, its scope, and which objects it should call.
The instructions are where the guardrails live, and they are only as strong as the model’s willingness to follow them. A determined prompt can often talk a model out of its own rules, which is why instructions alone are never a security control. They are guidance, not a boundary.
- Knowledge sources
- Grounding. The agent answers from connected sources such as SharePoint, OneDrive, Dataverse, uploaded files, public websites, and Microsoft Graph connectors.
- Retrieval. At query time the agent retrieves the most relevant content, summarises it, and cites the source.
Knowledge is the agent’s view of the world, and it is a double-edged capability. Untrusted content pulled into that view can carry hidden instructions the agent then follows, and content that is too broadly accessible becomes a disclosure risk the moment a user asks the right question.
- Tools, connectors, and actions
- Connectors. The agent can call from a large library of Power Platform connectors, plus custom REST and OpenAPI actions, Power Automate flows, and Model Context Protocol servers.
- Credentials. Tools run either with the end user’s identity, which is least privilege, or, if the maker chooses, with the maker’s own credentials.
Tools are the agent’s hands. They are what turn a conversational mistake into a real action against a real system, and the choice of whose credentials a tool runs under is one of the most consequential security decisions a maker makes, often without realising it.
- Generative orchestration
Modern agents use generative orchestration, in which a language-model planner decides which knowledge sources, tools, and connected agents to invoke for a given request. It makes those choices by reading the names and descriptions of each object, not by matching fixed phrases. Microsoft’s own guidance stresses that names matter more than anything. For an attacker, that is a clear signal: if behaviour is driven by natural-language descriptions, then natural-language manipulation is the way in.
- Channels, identity, and autonomous triggers
- Channels. An agent can be published to Microsoft Teams, Microsoft 365 Copilot, a public website, and other surfaces, with authentication ranging from full Entra sign-in to none at all.
- Triggers. An agent can also run automatically on events, such as a new email or a new record, with no human in the loop.
Autonomous, event-triggered runs change the trust model quietly. Microsoft documents that these runs authenticate with the maker’s credentials rather than the end user’s, which means every user of such an agent effectively borrows the builder’s reach. This is the classic confused-deputy condition, built into the product by design.
Where the risk lives
Set against that anatomy, the ways an agent can be attacked fall into a handful of themes. They map cleanly onto two industry frameworks a technical reader will recognise: the OWASP Top 10 for Large Language Model Applications, and the newer OWASP Top 10 for Agentic Applications, published at the end of 2025. The fact that the security community now maintains a separate top ten for agents shows that the industry has stopped treating them as ordinary chatbots.
- Prompt injection, direct and indirect
Direct injection is a user jailbreaking the agent in front of them. The more dangerous form is indirect injection, where malicious instructions arrive inside the content the agent retrieves, such as a document, an email, or a web page. The maker never sees them and the victim never types them. Because an enterprise agent combines autonomous tool use, delegated permissions, and untrusted retrieved content in one place, a single planted instruction can steer the agent for every user who later relies on it.
- Data exfiltration
Once an injection controls the agent’s output, the attacker needs a way to move data out. The recurring channels are rendering tricks: an image whose web address quietly carries stolen data, a styling declaration that does the same when the output is displayed, or a tool call whose parameters smuggle the content to an external endpoint. The most serious of these are zero-click, requiring no action from the victim at all.
- Oversharing and excessive access
An agent acts within the permissions of the person using it, which sounds safe until you remember how much access the average employee has quietly accumulated over the years. Broad legacy permissions, open sharing links, and broken inheritance mean that a low-privileged account, pointed at an agent, becomes an efficient discovery engine for content the user could technically reach but never knew existed. The agent did not grant new access. It removed the friction that kept that access theoretical.
- Sensitive information and system-prompt disclosure
Separate from how data leaves an agent is what leaks. Confidential documents can be pulled beyond their intended scope, personal data can surface from document metadata, and the agent’s own instructions and tool list can be coaxed out as reconnaissance for a follow-up attack. A subtle version involves the citation pane, where the agent’s text answer stays restrained while the source preview quietly renders the underlying file in full.
- Tool abuse and the confused deputy
Where an agent holds privilege and an attacker controls its input, the attacker can make it act. Over-privileged connectors, tools that run on the maker’s credentials, and server-side requests through web-request actions all turn a conversational flaw into a real action against a real system. The risk now reaches the tool supply chain itself: as agents increasingly connect to external tool servers through emerging standards such as the Model Context Protocol, a compromised or carelessly built connector becomes another way in, and 2026 has already brought a wave of disclosures in exactly that ecosystem. An agent is only as trustworthy as the tools and servers it is wired to.
- Anonymous agents and sprawl
Finally, the low-code model that makes Copilot Studio attractive also makes it easy to leave unauthenticated agents exposed on the internet and to accumulate forgotten, ownerless agents with inconsistent security postures. Each one is unmanaged attack surface that no one is watching.
This is already happening
If this sounds hypothetical, it is not. The most striking recent example arrived in June 2026, when researchers at Varonis disclosed a flaw they named SearchLeak. A single crafted link, once opened, turned Microsoft 365 Copilot into a one-click data-theft tool. A parameter in the link was read as an instruction, an attacker-controlled image slipped into the response before it was sanitised, and a request routed through a trusted search service quietly carried the data back out. Emails, multi-factor codes, calendar entries, and stored files could all leave on a single click, with the user none the wiser. Microsoft rated it critical and fixed it on the server side.
SearchLeak was not the first of its kind, and it will not be the last. A year earlier, the now-famous EchoLeak showed the same idea in its purest form. A crafted email, never knowingly acted on by the victim, was enough to make Microsoft 365 Copilot retrieve internal data and beacon it to an attacker with zero clicks. It was the first publicly documented zero-click data-theft chain in a production AI assistant, and it changed how the industry thinks about these systems.
Copilot Studio itself has not been spared. Microsoft has patched flaws in the platform, including an information-disclosure issue in early 2026 that exposed sensitive data to unauthenticated requests, and an earlier case in which the platform’s own web-request feature was coerced into reaching Microsoft’s internal infrastructure and retrieving credentials. Independent researchers have gone further, demonstrating live hijacks of customer-service agents built on Copilot Studio that leaked entire customer-record databases, and finding thousands of such agents reachable on the open internet.
The throughline across every one of these cases is the same: untrusted input, a capable agent, and a path for data to leave. The specific bug changes from one disclosure to the next. The shape of the attack does not.
The weaknesses that keep showing up
Adversarial testing of Copilot Studio agents repeatedly surfaces the same weakness classes. They are described here as general patterns rather than incidents, because the point is not any single organisation; these failures are systemic to how the platform is used today. In each case the impact can be demonstrated safely, without disrupting a live environment.
- Indirect injection to exfiltration. An agent’s own grounded content can be turned into a working data-exfiltration path by planted instructions, with no action required from the user.
- Confidential content disclosure. Agents can be made to reveal internal documents, and the structure of those documents, well beyond what their authors intended to expose.
- Personal data exposure. Names and contact details can be recovered from document metadata, the kind of information that fuels targeted social engineering.
- Instruction and scope disclosure. An agent’s own instructions and guardrail logic can be reconstructed through patient questioning, and the gaps that reveals then exploited.
- Knowledge-base enumeration. The size and naming patterns of an agent’s document store can be mapped, enabling systematic guessing of adjacent records.
- Capability abuse. Agents can be driven to generate working attacker tooling and to perform their own value-triage of what an attacker would want most.
The methods behind these failures are rarely technical exploits. They are pretexts the model wants to believe: posing as the agent’s own administrator, layering authority with urgency, asking the agent to describe rather than quote, or encoding a request so it slips past filters that only watch for obvious keywords. The lesson for defenders is uncomfortable but clear. The strongest attacks read like ordinary, reasonable requests, and the agents that fail are usually not badly built.
Agents that fail security testing are rarely badly built. They are built the way the platform encourages, which is exactly why this is an industry problem and not a one-off.
Securing Copilot Studio: where to start
The encouraging news is that almost every weakness above has a corresponding control, and Microsoft provides a genuine, layered security model. The problem is rarely that the controls do not exist. It is that they are off by default, spread across several admin centres, or quietly relaxed by a business user who simply wanted their agent to work. In priority order, this is where organisations should start.
- Remediate oversharing first
Before scaling agents, fix the data estate they will read. Identify over-broad permissions, open sharing links, and broken inheritance, and bring access back to what is actually needed. An agent only amplifies the oversharing that already exists, so this step pays for itself.
- Govern the platform
Use Power Platform environments as security boundaries, apply data loss prevention and connector policies to control what agents can touch, and pay particular attention to the default environment, where every user is a maker. Managed environments add sharing limits and policy enforcement at scale.
- Set a deliberate authentication posture
Treat anonymous, unauthenticated agents as a conscious decision rather than an accident. Keep tools running on the end user’s own credentials wherever possible, and treat any agent that uses the maker’s credentials, or that runs automatically on a trigger, as privileged and subject to extra scrutiny.
- Turn on Microsoft Purview
Use Data Security Posture Management for AI to gain visibility into how agents are used, data loss prevention to keep labelled content out of agent grounding, sensitivity labels to enforce protection on the underlying data, and auditing to keep an accountable record of agent activity.
- Constrain the tools
Apply least privilege to every connector, require human approval for high-impact actions, and lock down general-purpose web-request capabilities that can be abused for exfiltration or for reaching internal systems.
- Red team continuously
Finally, test agents the way an attacker would, both before they go live and on a recurring basis. The attacks evolve, the agents change, and a point-in-time review ages quickly. Continuous adversarial testing is the only way to know what an agent will actually do under pressure, rather than what it was designed to do.
Building with eyes open
AI agents are not a passing trend, and Copilot Studio has made them a standard part of the modern workplace. That is a good thing. The organisations that benefit most will be the ones that treat an agent as what it really is: a piece of software with an identity, real permissions, and the ability to act, deserving the same security rigour as any other privileged system. Built and governed with that mindset, these agents are a genuine advantage. Deployed without it, they become a fast and quiet path to the very data they were meant to protect. The difference is not the technology. It is the discipline applied to securing it.
Securing Copilot Studio: where to start
The encouraging news is that almost every weakness above has a corresponding control, and Microsoft provides a genuine, layered security model. The problem is rarely that the controls do not exist. It is that they are off by default, spread across several admin centres, or quietly relaxed by a business user who simply wanted their agent to work. In priority order, this is where organisations should start.
- Remediate oversharing first
Before scaling agents, fix the data estate they will read. Identify over-broad permissions, open sharing links, and broken inheritance, and bring access back to what is actually needed. An agent only amplifies the oversharing that already exists, so this step pays for itself.
- Govern the platform
Use Power Platform environments as security boundaries, apply data loss prevention and connector policies to control what agents can touch, and pay particular attention to the default environment, where every user is a maker. Managed environments add sharing limits and policy enforcement at scale.
- Set a deliberate authentication posture
Treat anonymous, unauthenticated agents as a conscious decision rather than an accident. Keep tools running on the end user’s own credentials wherever possible, and treat any agent that uses the maker’s credentials, or that runs automatically on a trigger, as privileged and subject to extra scrutiny.
- Turn on Microsoft Purview
Use Data Security Posture Management for AI to gain visibility into how agents are used, data loss prevention to keep labelled content out of agent grounding, sensitivity labels to enforce protection on the underlying data, and auditing to keep an accountable record of agent activity.
- Constrain the tools
Apply least privilege to every connector, require human approval for high-impact actions, and lock down general-purpose web-request capabilities that can be abused for exfiltration or for reaching internal systems.
- Red team continuously
Finally, test agents the way an attacker would, both before they go live and on a recurring basis. The attacks evolve, the agents change, and a point-in-time review ages quickly. Continuous adversarial testing is the only way to know what an agent will actually do under pressure, rather than what it was designed to do.
Building with eyes open
AI agents are not a passing trend, and Copilot Studio has made them a standard part of the modern workplace. That is a good thing. The organisations that benefit most will be the ones that treat an agent as what it really is: a piece of software with an identity, real permissions, and the ability to act, deserving the same security rigour as any other privileged system. Built and governed with that mindset, these agents are a genuine advantage. Deployed without it, they become a fast and quiet path to the very data they were meant to protect. The difference is not the technology. It is the discipline applied to securing it.
See also:
Dubai