Copilot Studio Agent Security Review and Red-Team Test
IT Partner tests one Copilot Studio agent — or an agent built with the agent builder in Microsoft 365 Copilot or as a SharePoint agent — the way an attacker would, before or after it goes live, for a fixed $2,950. Over two weeks we review the configuration that decides what the agent can reach and who it acts as: authentication mode, sharing and channels, knowledge sources and web search, every connector, tool and flow and whether it runs under the maker's credentials or the user's, triggers and approval steps, and the Power Platform environment and data policies around it. Then we attack it: direct and indirect prompt injection, jailbreak and role-play, data leakage across knowledge sources, over-permissioned connections and unsafe or unapproved actions — an automated red-team scan built on Microsoft's PyRIT-based AI Red Teaming Agent tooling for breadth, and hand-written test cases planted in the email, documents, SharePoint content and web pages the agent actually reads for the attacks that matter. You get a risk-ranked findings report with a specific fix for each item, a readout with the agent owner and your security lead, and a retest of the fixes within 30 days. One agent per fee, up to about ten knowledge sources and tools; additional agents are quoted per agent and multi-agent estates as a whole. A test shows what was found in the build we tested — it does not certify the agent, and the report says so.
What this engagement is
Copilot Studio turned building an agent into a no-code task, and that is exactly why agents need testing. The agent a team publishes reads knowledge (SharePoint and OneDrive, Dataverse, uploaded files, public websites, connector data), calls tools (connectors, agent flows, prompts, MCP servers, HTTP requests), can act on its own when an event fires (an email arrives, a record changes), and is published to Teams and Microsoft 365 Copilot, a website, or a custom channel. Every one of those is a decision a maker made in a settings pane, and the defaults are workable rather than safe for every use case. The failures are not hypothetical. In 2025 Zenity Labs demonstrated an email-borne prompt injection that made a customer-service agent read a customer file and mail it to the attacker, then pulled CRM records in bulk through the agent's Salesforce connection — Microsoft changed the platform-side behaviour afterwards. Tenable AI Research showed a travel-booking agent disclosing customer records, card details included, and booking a trip for free. In January 2026 Microsoft addressed CVE-2026-21520, a Copilot Studio information-disclosure vulnerability rated CVSS 7.5 that let an unauthenticated network attacker reach sensitive data; the reported vector was untrusted form input concatenated into the agent's prompt. And in February 2026 Microsoft's own security team published the ten agent misconfigurations it sees most: agents shared with the whole organization, agents that require no authentication, risky HTTP request actions, email actions that can exfiltrate, dormant connections, tools running on maker credentials, hard-coded secrets, MCP tools, generative orchestration with no real instructions, and orphaned agents. Platform fixes fix the platform. None of them fix how your agent is configured. The review half of the engagement walks that configuration setting by setting. In the agent: the authentication mode under Settings > Security (No authentication, Authenticate with Microsoft, Authenticate manually) and every channel it is published to; who can chat with it and who can edit it — everyone in the organization, or named security groups; each knowledge source, and whether SharePoint grounding respects the user's own permissions or runs through a maker's connection; the Web search and Allow ungrounded responses toggles; each connector, flow and tool with its credential mode — User authentication, or agent-author (maker-provided) credentials, which make every user act as the maker; triggers, and which actions have a human approval step before they execute; the instructions and orchestration settings the model actually works from. Around the agent: the Power Platform environment it lives in, whether it is a managed environment with sharing limits, the data policies that classify Copilot Studio's own connectors (chat without Microsoft Entra ID authentication, Direct Line channels, knowledge sources with public websites, HTTP requests, MCP), the tenant and environment controls that require user authentication and restrict maker-provided credentials, whether secrets sit in environment variables backed by Azure Key Vault or in the agent itself, and who owns the agent and its connections. The agent owner tells us what the agent is supposed to do and must never do; that becomes the oracle the tests are judged against. The test half is where the report earns its keep. Direct injection and jailbreak: instruction and configuration disclosure, enumeration of knowledge sources and tools (the first thing the Zenity attack did), encoded and obfuscated payloads, role-play and multi-turn escalation. Indirect injection, planted where the agent reads: a document or page in a knowledge site, an email into the mailbox an email-triggered agent watches, a form field feeding a flow, a public web page when web search is on. Data leakage: two test identities with different permissions probing for records neither should be able to reach, and for content from one knowledge source surfacing through a question about another. Over-permission: what a maker-credential connection can reach beyond the agent's purpose when a low-privilege user drives it. Unsafe actions: whether the agent can be talked into mailing an outside address, changing a record, calling an HTTP endpoint or running a flow without the approval step — and business-logic abuse such as discounts, bookings and refunds. Two layers of tooling: an automated scan using the red-team capability of Microsoft's azure-ai-evaluation SDK (the local form of the AI Red Teaming Agent, built on PyRIT), connected to your agent with the pattern Microsoft publishes in its Azure-Samples harness for Copilot Studio — content-safety risk categories and more than twenty attack strategies at rising complexity, producing an attack success rate as a baseline; and hand-written cases for everything above, because at the time of writing Microsoft's agentic risk categories (prohibited actions, sensitive data leakage, task adherence, indirect prompt injection) run only in the cloud against Foundry-hosted agents, and a Copilot Studio agent is not a supported target for them. We say that plainly rather than let a tool name imply coverage it does not have. The output is a risk-ranked report where every finding carries its evidence transcript, reproduction steps, impact in your context and the specific fix — a setting, an instruction change, a credential-mode switch, an approval step, a data policy, a Key Vault reference — labelled by who can make it: the maker, the Power Platform administrator, or only Microsoft. We walk it through with the agent owner and your security lead, and once your team has applied the fixes we retest within 30 days and write up what closed. Fixing the agent stays with its owner or with our Copilot Studio agent development practice; the tenant-wide baseline — Purview, Defender, Entra Agent ID, environment policies across every agent — is AI Security for Microsoft 365 Copilot and Agents; agents built in Microsoft Foundry or custom code are quoted separately; the web application an agent is embedded in is a Web Application Security Assessment. And to be plain about what this is not: a structured security test of one agent under written rules of engagement, not a certified penetration test, and a point-in-time result — the next publish is a new build.
Success criteria
What you receive
How the work unfolds
We confirm the agent, where it lives, what it connects to and whether it fits the fixed fee; agree test identities, test mailbox, test content locations and test records; set testing windows and emergency contacts; and, where possible, take a copy of the agent into a non-production environment. Time-bound, least-privilege access is granted and nothing is tested until the document is signed.
Setting-by-setting review of the agent — authentication, channels, sharing, knowledge sources, web search and ungrounded responses, every tool's credential mode, triggers and approvals, instructions and orchestration — and of the environment around it: managed-environment limits, data policies, tenant and environment authentication controls, secrets handling, ownership. A short interview with the agent owner records what the agent must do and must never do.
The automated scan runs first to establish the baseline attack success rate. Then the manual cases: direct injection and jailbreak, indirect injection planted in email, documents, SharePoint content and web pages the agent reads, cross-identity and cross-source leakage, over-permission probes, and unsafe-action and business-logic cases. Anything critical is reported the same day through the emergency contact.
Findings are rated, evidenced and given their fix and owner label; the configuration workbook, test log and scan report are assembled into the evidence pack; the go-live summary and fix plan are drafted.
Walkthrough of every finding with the agent owner and your security lead — reproduction, impact, fix — and agreement on who fixes what and by when, so the retest window is used.
Once you tell us which findings were fixed, we re-run those cases and the automated scan against the fixed build and deliver the retest summary. If you fix fast, this lands inside the two weeks; the window is there so it does not have to.
Prerequisites
Who does what
IT Partner
- Define and document the scope and rules of engagement, and stay inside them.
- Perform the configuration review of the agent and its environment against Microsoft's published controls and our checklist.
- Run the automated scan and the manual test cases, and log every case with evidence.
- Report any critical finding the same day, out of band — not at the end of the engagement.
- Deliver the findings report, fix plan, go-live evidence summary and readout.
- Run the retest within the 30-day window and deliver the before-and-after summary.
- Remove temporary access and planted test content, or list exactly what remains for you to remove.
Your team
- Provide written authorization, test identities, test targets and the agreed access before testing starts.
- Confirm third-party service permissions where connectors reach outside Microsoft 365.
- Keep the agent unchanged during the testing window — a republish mid-test invalidates results.
- Own remediation decisions and their execution, and risk acceptance for anything deliberately left open.
- Tell us which findings were fixed so the retest tests the right things.
- Pay Microsoft for the metered consumption test traffic generates on your subscriptions.
What's not included
Limitations & technical notes
Frequently asked questions
Is this a penetration test?
It is a structured security test of one agent under written rules of engagement — configuration review plus adversarial testing — and much of it is what a red team would do to an agent. It is not a certified penetration test: no accreditation, no attestation, and it will not satisfy a contract or insurer that names one. For the question most teams actually have — will this agent leak data, take an action it should not, or follow instructions planted in an email — it is the right instrument, and the report is written to be handed to whoever asked the question.
What does red-teaming an agent mean, in plain terms?
Trying to make the agent do what its owner said it must never do, using the routes a real attacker has. Some of those are conversational: telling it to ignore its instructions, asking it to reveal its configuration, wrapping a payload in Base64 or a role-play. The more dangerous ones never touch the chat window: an email that arrives in the mailbox the agent watches, a document dropped into the SharePoint library it reads, a comment field that feeds one of its flows, a web page it will search. If the agent treats that content as instructions rather than data, it can be steered — into mailing a customer list out, changing a record, or approving something. We test both kinds, log each case with evidence, and rank what landed.
Which agents can you test?
Agents built in Copilot Studio — including autonomous ones with triggers — and agents built with the agent builder in Microsoft 365 Copilot or as SharePoint agents, whichever channel they are published to. Agents built in Microsoft Foundry or in custom code with the Agents SDK or another framework are a different test surface and are quoted separately. If your agent calls other agents, tell us at scoping: connected and child agents widen the scope.
Do you use Microsoft's AI Red Teaming Agent, and what does it actually cover for a Copilot Studio agent?
Yes, in the form that fits. Microsoft's AI Red Teaming Agent is built on PyRIT, its open-source red-teaming framework, and comes in two shapes. The cloud run — the one with the agentic risk categories such as prohibited actions, sensitive data leakage and indirect prompt injection — supports Foundry-hosted agents only at the time of writing; a Copilot Studio agent is not a supported target. The local run, through the azure-ai-evaluation SDK, can be pointed at any agent through a callback, and Microsoft publishes a sample harness for exactly that against Copilot Studio. That is what we use: content-safety risk categories and more than twenty attack strategies at rising complexity, producing an attack success rate we record as the baseline and re-run at the retest. The injection, leakage, over-permission and unsafe-action tests — the ones that matter for a business agent — are written and run by hand, and every case is in the log.
What does an indirect prompt-injection test look like?
We plant instructions where the agent reads and see whether it obeys them. For an agent that triages email, that is a message into the test mailbox with instructions hidden in the body or an attachment — the vector Zenity Labs used to make a customer-service agent mail out a customer file. For an agent grounded on a SharePoint site, it is a document in the test library. For one fed by a form, it is the form field — the vector reported behind CVE-2026-21520. For one with web search on, a page it will find. The payloads ask the agent to reveal its configuration, ignore a rule, include a link or address in its reply, or take an action. Everything is planted in test locations we agreed in writing, and removed afterwards.
Will testing spam our customers, send real emails or change real records?
No. The rules of engagement name the test mailbox, test records and test content locations, and every action the agent can take is pointed at those. Where an action cannot be safely redirected — an email step that only knows the production recipient list, say — we disable it for the window or reason the finding from configuration and say so. Anything critical found mid-engagement goes to your emergency contact the same day. We validate; we do not exfiltrate, persist or pivot to prove a point.
Our agent's connectors run under the maker's credentials. Is that automatically a finding?
It is always recorded, and it is usually a finding. With agent-author (maker-provided) credentials, every person who talks to the agent acts as the maker for that tool — the classic confused-deputy problem, and the route by which a prompt injection becomes an action across systems. Microsoft lists it among the misconfigurations it sees most and provides an administrator control to restrict maker-provided credentials. It can be acceptable for a low-risk tool that returns public information; it is not acceptable for anything that reads personal data or writes to a system of record. The fix is usually a switch to user authentication, and sometimes a redesign of what the tool is for.
What real incidents is this based on?
Three public threads, and Microsoft's own guidance. Zenity Labs' 2025 research showed an email-borne injection driving a Copilot Studio customer-service agent to exfiltrate a customer file and bulk CRM records; Microsoft changed the platform behaviour after disclosure. Tenable AI Research demonstrated a travel-booking agent leaking customer records, including card details, and granting a free booking. CVE-2026-21520, addressed by Microsoft in January 2026 and rated CVSS 7.5, was a Copilot Studio information-disclosure flaw reachable by an unauthenticated attacker over the network, reported by Capsule Security, with untrusted form input reaching the agent's prompt. In February 2026 Microsoft published the ten misconfigurations it sees most often in customer agents. Our checklist and test families are built from all four, and we cite the sources in the report rather than paraphrase them.
Should we test before go-live or after?
Before, if you can — the cheapest finding is the one fixed before anyone depends on the agent, and the evidence summary is what a change board or a regulated-industry sign-off is asking for. After is the honest answer for the agents already running; most were published by a maker who was never asked the questions on our checklist. Either way, the retest re-establishes the baseline, and an agent that keeps changing is better served by a standing arrangement than by a yearly test.
What do you need from us to start?
Five things: written authorization from the agent owner and your administrator; the agent named, with an owner who can answer what it must never do; test identities, a test mailbox and a test content location; time-bound read access to the agent and its environment settings; and an emergency contact. With those, the two-week clock starts at the rules-of-engagement signature. A non-production copy of the agent is the sixth thing we ask for when it exists.
What does it cost, and what does the fee cover?
$2,950, fixed, for one agent with up to about ten knowledge sources and tools: the configuration review, the automated scan, the manual test cases, the findings report and fix plan, the go-live evidence summary, the readout and one retest within 30 days. The price is quoted in writing before work begins and you pay after you approve delivery. Additional agents are quoted per agent, and a multi-agent estate is quoted as a whole after a short scoping call. Microsoft's metered consumption from test traffic is billed by Microsoft to you and is not part of the fee.
How long does it take, and how does the retest work?
Two weeks from signed rules of engagement to readout: scoping in the first two days, configuration review through day four, testing through day eight, analysis and the readout by day ten. The retest is a separate, short round any time within 30 days of the report: you tell us which findings were fixed, we re-run those cases and the automated scan against the fixed build, and you get a before-and-after summary. Fix quickly and it lands inside the fortnight.
Do you fix what you find?
Not inside this engagement — deliberately, so the test stays independent of the fixing and you keep leverage on what to change and with whom. Most findings are settings, credential modes, approval steps or instructions the maker can change in an afternoon, and the fix plan is written for that. Where a redesign is needed, our Copilot Studio development practice can take it as separately scoped work, and platform-level fixes belong in the AI security engagement. There is no lock-in in either direction; the report is yours to hand to whoever you choose.
Will the report satisfy our auditor, cyber-insurer or enterprise customer?
It is strong evidence, not a certificate. The go-live summary states scope, method, findings, fixes and residual items in the form a vendor-risk reviewer or auditor asks for, and the evidence pack backs every line. If the driver is a cyber-insurance questionnaire, the Cyber Insurance Readiness Assessment addresses the rest of the form; if it is an AI management system, the ISO/IEC 42001 readiness engagement is where this test becomes one control among many.
Microsoft already has Prompt Shields and a security scan at publish. Why test at all?
Because both are necessary and neither is sufficient. Prompt Shields and the responsible-AI guardrails run on Microsoft's side and catch a class of attacks; they did not stop the incidents above, which succeeded through configuration — a tool on maker credentials, an email action with a free-text recipient, a knowledge source wider than the audience. Copilot Studio's pre-publish security scan warns a maker about No authentication and maker-provided credentials; it is a warning, not an enforcement, and it does not know what your agent is for. We test your agent as it behaves with all of Microsoft's protections on, against what its owner says it must never do.
What happens to the payloads and test content you plant?
They are catalogued in the test log, planted only in the test locations named in the rules of engagement, and removed at the end — or, where you prefer to remove them yourself, listed precisely. Temporary access is revoked the same day. Transcripts and screenshots stay in the evidence pack you receive; we keep our working copy under the confidentiality terms of the engagement.