Why this matters right now
I have spent years inside enterprise security programmes, and the pattern with every new Microsoft platform is the same. The vendor says it is secure by default. The makers inside the business say it is easy to use. Then someone builds an agent that can read your HR files and email them to an address it was just told to use, and the security team finds out from an incident ticket.
Microsoft Copilot Studio and the wider Power Platform are now the default way thousands of organisations build AI agents without writing much code. That speed is the whole point. It is also the whole risk. This article is the implementation briefing I wish every CISO, platform owner and AI lead had before they flipped the switch: what is actually safe out of the box, what is not, what it costs, and how to govern it at scale using Microsoft Agent 365 and Purview.
What Copilot Studio and the Power Platform actually are
Copilot Studio sits on the Microsoft Power Platform. It shares your tenant, your Microsoft Entra ID identity, and your existing data governance with Microsoft 365. That shared foundation is genuinely good news, because it means agents inherit a lot of controls you already run.
There are three agent harnesses to know:
- Copilot Chat agents, which live inside the Microsoft 365 experience.
- Standard agents, the classic Copilot Studio bots built with topics and actions.
- Custom engine agents, where you bring your own orchestration and models. These can be built in Copilot Studio, the Teams developer kit, or Azure AI Foundry.
Microsoft also separates declarative agents from custom engine agents. A declarative agent runs inside the Microsoft 365 Copilot host and uses Microsoft’s own model and orchestrator. Because of that, it inherits Microsoft 365 security, compliance and responsible AI controls. A custom engine agent brings its own brains and therefore needs its own governance.
The “secure by default” claim, tested
Microsoft is right that Copilot Studio is secure at the platform layer. It is wrong to assume that means governed. The defaults are tuned for maker convenience, not for a regulated enterprise, and several of them can be flipped off with nothing more than a warning.
The Microsoft Defender research team published the ten most common agent misconfigurations they see in real deployments. Here are the ones that bite hardest:
- Agents shared with the whole organisation. Broad sharing expands the attack surface instantly. Mitigation: sharing limits in Managed Environments plus the automatic security scan that warns at design and publish time.
- Agents with no authentication. A maker can toggle “no authentication” for convenience. The platform warns but does not block, leaving a public entry point into organisational data.
- HTTP request actions with risky config. Calls to non HTTPS endpoints or nonstandard ports bypass normal governance. Mitigation: data policies and advanced connector policies per environment.
- Email based data exfiltration. An agent with the “send an email” action can be steered by a prompt injection to leak data to an external mailbox. Mitigation: Microsoft Defender real-time protection and connector action control.
- Maker credentials. When an agent runs using the author’s own login instead of a dedicated connection, every user who talks to it inherits the maker’s permissions. That is privilege escalation and a breakdown of separation of duties.
- Hardcoded secrets. Credentials pasted into topics or actions leak. Mitigation: store secrets in Azure Key Vault and reference them as environment variables.
- Generative orchestration with no instructions. An agent allowed to plan its own steps with no guardrails drifts and takes unintended actions.
The single most important fact: tenant isolation is OFF by default. That means cross-tenant connections are permitted out of the box if the user presents valid Entra credentials. If you do nothing, data can move to external tenants. Turning tenant isolation on and maintaining a strict allow-list is the first control any enterprise should set.
Stopping bad actions at runtime
Design-time warnings are not enough. The stronger control is Microsoft Defender real-time protection for Copilot Studio agents, now in public preview. When a user sends a prompt, the agent first builds a plan of the tools and actions it intends to use. Defender inspects that plan and blocks risky tool invocations before they run, with roughly a one second decision window. Blocked and audited activity is recorded as behaviours you can hunt and automate on.
For organisations with their own security stack, Copilot Studio can also post the agent’s planned actions to an external system via a webhook (an Entra app plus a function) for approval or block. That lets a third-party or in-house tool act as the gatekeeper during the agent’s loop.
Native defences against user prompt injection and cross-domain (indirect) prompt injection are on by default through Azure Prompt Shield and responsible AI guardrails. That is a real strength. But the active runtime blocking via Defender is a separate feature you must explicitly enable and connect.
Where your data lives, and where Purview fits
Customer data in Copilot Studio stays within the Azure geography you choose, and you can confirm the storage region through the data location card. Customer Lockbox is supported for accessing customer data, but note two limits: it is opt-in and off by default, and it does not cover all outbound data from Copilot Studio, including parts of its security audit and governance telemetry.
Microsoft Purview is the data-security backstop. Its Data Security Posture Management for AI (DSPM for AI) is the front door: it discovers AI usage, surfaces risk, and offers one-click policies. The critical Purview controls for agents are:
- Sensitivity labels. When a file is encrypted with a label, Copilot and agents must have both VIEW and EXTRACT usage rights before they return that content. But this only works if you enable sensitivity labels for SharePoint and OneDrive. Skip that step and the agent inherits every oversharing gap already in those stores.
- Restricted SharePoint Search for Copilot. This limits which sites Copilot can search to curated, governance-approved locations.
- Communication Compliance, eDiscovery and Compliance Manager. These let you analyse AI interactions for risk, find AI-generated data during investigations, and track AI-regulation assessments.
Purview covers three bands: Microsoft’s own Copilot experiences and agents (including Copilot Studio), enterprise AI apps registered through Entra or Foundry, and other AI apps detected through the Defender for Cloud Apps catalogue.
Licensing, explained without the fog
The licensing model trips up even experienced procurement teams. There are distinct layers.
Microsoft 365 Copilot
At roughly US$30 per user per month, this licence is what end users need to work with declarative agents inside Microsoft 365 apps. It also unlocks a 50 percent discount on the Microsoft Purview Suite, which is why buying it early is usually smart.
Copilot Studio
The tenant licence is sold per tenant and includes Copilot Credit capacity packs of 25,000 credits, priced at US$200 per pack per month. Unused credits do not roll over. For variable or seasonal load, a pay-as-you-go meter bills through your Azure subscription for credits actually consumed, with no upfront commitment. Keep that meter linked even if you mainly buy packs, because it prevents an outage when you hit the cap.
Important nuance: under pay-as-you-go you cannot assign the free (US$0) Copilot Studio user licence. Licensing is handled entirely through Azure billing. A Copilot Studio user licence is required for each person who builds or manages agents, and Microsoft recommends buying it together with the tenant licence in one transaction.
Metering follows architecture. Declarative agents used by a Microsoft 365 Copilot licensed user for classic answers, generative answers and tenant graph grounding are zero-rated and do not consume Copilot Studio credits. Custom engine agents are metered on the Copilot Credits they consume, and they also carry their own Azure hosting cost because they run outside Microsoft 365.
Agent 365
Microsoft Agent 365, generally available since 1 May 2026, is the enterprise control plane for governing all agents, Microsoft-built and partner-built alike, inside the Microsoft 365 admin centre. It is about US$15 per user per month standalone, or included in the Microsoft 365 E7 bundle at roughly US$99 per user per month. E7 packages E5, the Entra Suite, Microsoft 365 Copilot and Agent 365 together.
Agent 365: the control plane you actually need
Agent sprawl is the quiet failure mode of enterprise AI. Agents appear in places you expect, like Microsoft 365 and Teams, and in places you do not, like local coding assistants or third-party software-as-a-service agents connected to your data. Agent 365 is the answer to that sprawl.
Its July 2026 update strengthened it as a true control plane. It brings agent risk signals from Microsoft Security (identity, threat protection, data security, compliance, device management) into one view, and it can ingest partner signals from vendors such as Cyera, Darktrace and Zenity, matched to each agent through Entra Agent ID. Registry sync, now generally available, discovers and inventories agents beyond Microsoft, including those on AWS Bedrock and Google Cloud. It also manages agents across multiple tenants from one place and tracks usage-based AI spend.
For running agents in a hardened environment, Windows 365 for Agents (public preview, United States only) provides a managed Cloud PC purpose-built for agentic workloads, governed in Intune with the same identity and security controls used for staff.
A 90 day configuration sequence that holds
The right posture is guardrails over gates. A blanket lockdown blocks productivity and still misses the real risks. Here is the sequence I would run.
Phase 0, week one, foundations. Turn tenant isolation on and allow-list only required cross-tenant partners. Enable Agent 365 in the Microsoft 365 admin centre and onboard your agents to the registry. Assign the Copilot Studio tenant licence plus a pay-as-you-go meter, and assign Agent 365.
Phase 1, weeks two to four, data boundaries. Deploy a tenant-level data loss prevention policy and classify connectors as Business, Non-Business or Blocked. Use advanced connector policies to block high-risk action verbs such as HTTP to non HTTPS endpoints and external email sends. Enable sensitivity labels for SharePoint and OneDrive. Configure Restricted SharePoint Search for Copilot.
Phase 2, weeks five to eight, environment and identity. Route makers out of the default environment and create dedicated Managed Environments per business unit. Enforce “no maker credentials” so agents use service principals or designated connections. Store secrets in Azure Key Vault referenced as environment variables, and rely on the automatic security scan to block hardcoded credentials at publish.
Phase 3, weeks nine to twelve, runtime and oversight. Enable Defender real-time protection for Copilot Studio agents and connect it. Deploy the Centre of Excellence Starter Kit, wire agent-invocation logs to your SIEM, and alert on bulk reads or financial-field edits. Activate Purview DSPM for AI with Communication Compliance and eDiscovery for AI data.
The five risks to put in front of the board
- Cross-tenant data exfiltration, because tenant isolation is off by default.
- Prompt-injection driven actions, including email exfiltration and privilege misuse, without runtime blocking.
- Maker-credential agents that escalate privilege and break separation of duties.
- Inherited oversharing from SharePoint and OneDrive gaps that Copilot surfaces.
- Agent sprawl and shadow AI with no inventory or cost oversight, addressed by the Agent 365 registry and the Centre of Excellence.
What this means for you
Copilot Studio is a capable, genuinely well-built platform, and its integration with Entra, Purview and Defender is a real advantage over bolt-on agent tools. The danger is not the platform. It is the assumption that buying the licence bought the governance. It did not. The enterprises that scale agents safely are the ones that treat Agent 365 as mandatory infrastructure, turn tenant isolation on before the first agent ships, and put a human-reviewed block on risky actions at runtime rather than trusting a design-time warning.
Secure by default describes the platform. It does not describe your configuration, and configuration is the only part of this you control. Govern the agents like production systems, because that is exactly what they are becoming.
