Microsoft Copilot for enterprises: custom experiences, DSPM and secure AI enablement

Why Microsoft Copilot rollouts stall in enterprises

In our experience the model is almost never the problem. What stalls a Copilot programme is simpler and more uncomfortable: you switch on a capability that reads everything an employee can already reach, and within a fortnight you learn that people could reach a great deal more than anyone intended. Copilot does not break the permission model. It just puts it on a screen, instantly, for every licensed user.

The second thing we see is a scoping mistake. Licences get bought as a productivity line item, then the value turns out to sit somewhere else entirely — a grounded agent for the claims team, a scheduled research task for the bid team, an approval-gated month-end workflow for finance. None of that arrives with a licence assignment.

The clients getting a return handle it as a platform decision, not a purchase: sort out data security posture, agree how AI is governed, then build a handful of custom experiences against named business problems.

The three layers: Copilot, Copilot Studio and Copilot Cowork

Microsoft 365 Copilot is the standard layer. It is embedded in Word, Excel, PowerPoint, Outlook and Teams, grounded in your Microsoft 365 tenant content and governed by existing identity, sensitivity labelling and compliance boundaries. The risk profile is largely read-and-summarise: the harm case is inappropriate disclosure of content the user should never have been able to open.

Copilot Studio is the build layer. It lets you create custom agents grounded in specific knowledge sources, connected to line-of-business systems through connectors, with defined topics, instructions and actions. The risk profile shifts, because you are now choosing the data an agent may retrieve, the systems it may call and the audience that may use it.

Copilot Cowork is the action layer. It carries out multi-step tasks across the Microsoft 365 environment — drafting and sending email, scheduling and managing meetings, creating documents, posting in Teams, searching organisational content, managing files, running deep research and executing scheduled or event-driven prompts. It works through steps in a visible session and pauses to ask for approval before sensitive actions, with a risk indicator on medium and high risk steps. Cowork can also be extended with custom skills and admin-deployed plugins.

Those three layers are not one control problem. A summarisation assistant, a grounded agent with write connectors, and an agent that can send external email on a schedule deserve materially different assurance before go-live.

Custom experiences are where the value actually sits

Generic assistance produces generic returns. Every measurable win we have seen came from something bounded: a tender agent grounded in an approved content library, a service desk agent drafting against current policy, a finance agent assembling the month-end pack and routing it for human approval, a research brief that lands before Monday’s leadership meeting.

Design each experience the same way you would design a process change. Name the decision or workflow, the accountable business owner, the data the agent may use, the actions it may take, the review point, the measure of success and the stop condition. Then build the narrowest version that produces the outcome.

Keep the estate small and deliberate. A tenant with twelve well-owned agents is governable. A tenant with three hundred maker-built agents, half of them abandoned, is a data-sprawl problem wearing a productivity badge.

DSPM for AI: the work that must happen before licences land

Data security posture management for AI answers a question governance documents cannot: what sensitive data is actually reachable, who is prompting for it, and what is leaving the boundary. Microsoft Purview provides DSPM for AI to discover AI usage across Copilot and third-party assistants, surface sensitive-data interactions, apply data loss prevention and retention to prompts and responses, and give compliance teams a defensible record.

The pre-deployment sequence matters. Discover where sensitive content lives, classify and label it, remediate oversharing in SharePoint and OneDrive, restrict broad access links and stale site permissions, then apply DLP policies that keep labelled content out of prompts where required. Microsoft publishes specific oversharing controls for exactly this reason, because retrieval will faithfully surface anything the permission model allows.

After deployment, DSPM becomes a monitoring discipline: which sensitive labels are appearing in prompts, which agents are touching regulated data, whether shadow AI use is rising, and whether risky interactions cluster in a particular team. Treat those signals as an operational feed into your risk register, not a quarterly report.

Identity, permissions and blast radius

Copilot inherits the identity of the user, and agents carry the connections a maker configured. Both need least privilege. Enforce multi-factor authentication and conditional access on every account with Copilot access, review privileged and service identities used by connectors, and prefer scoped, short-lived credentials over standing broad access.

For anything that can act — Cowork sessions, Copilot Studio agents with write actions, scheduled or event-driven tasks — define the bounded action set, the rate at which it may act, and the reversible path if it acts wrongly. The question to answer before go-live is unchanged from any other integration: if this is manipulated or misconfigured, what is the worst action it can take before a human notices?

Decide deliberately where approval is mandatory. Cowork asks for approval before sensitive actions and offers to skip future prompts for similar actions; that convenience setting is a governance decision, not a user preference, and should be covered by policy for external communication, financial actions and customer-facing output.

AI governance: the operating model around the technology

Governance should make useful work fast and harmful work slow. Practically, that means an AI inventory that includes every Copilot Studio agent and Cowork custom skill with its owner, data classes, connectors and autonomy level; a lightweight intake and approval gate scaled to impact; and a review cadence that reassesses agents when data sources, connectors or model versions change.

ISO/IEC 42001 provides the management system structure — scope, leadership accountability, risk and impact assessment, supplier controls, incident handling and evidence — and it interlocks cleanly with an existing ISO/IEC 27001 programme. The NIST AI Risk Management Framework is useful where you need a common language for impact assessment across business and technical stakeholders.

In Australia, add the privacy overlay early. Where Copilot output influences decisions about individuals, expect scrutiny on transparency, accuracy and the handling of personal information, alongside the sector obligations your organisation already carries. Keep the evidence pack — approvals, impact assessments, DLP configuration, audit logs and oversight records — assembled as you go rather than reconstructed under pressure.

Threats specific to Copilot-style deployments

Indirect prompt injection is the material one. A document, email or web page inside the retrieval path can carry instructions that the agent follows, causing it to disclose context or take an action on the attacker’s behalf. Test it explicitly: seed content with injection payloads and confirm the agent does not exfiltrate context or trigger a connector action.

Excessive agency is the second. An agent granted write access "because read was inconvenient" will eventually send, post or update something at the wrong moment. Third is data leakage through convenience — plugins, external connectors and unmanaged consumer AI running beside the sanctioned tenant.

The OWASP Top 10 for LLM applications is a reasonable checklist to run each custom experience against before release. Record the result against the inventory entry so the assessment is repeatable when the agent changes.

A 90-day secure enablement sequence

Days 1 to 30 — establish the baseline. Run discovery on sensitive data and oversharing, stand up Purview DSPM for AI, agree data classification and labelling, fix the worst SharePoint and OneDrive access patterns, and publish an AI acceptable use policy that names what may never be pasted into a model.

Days 31 to 60 — enable a controlled cohort. Assign licences to one or two business units with a named owner, apply DLP and retention to prompts and responses, enable audit logging, and run two custom experiences in Copilot Studio against real work with mandatory human review.

Days 61 to 90 — measure and decide. Compare against the baseline you recorded: quality, cycle time, rework, adoption and control exceptions. Confirm the governance gate, oversight model and evidence pack work in practice, then scale the pattern rather than the enthusiasm. If net benefit is not visible, narrowing scope is a legitimate outcome.

What good looks like at the twelve-month mark

A mature Copilot estate has a small, owned catalogue of custom experiences tied to business outcomes; a data boundary enforced by labelling and DLP rather than by policy statements; permissions that have been remediated and are monitored for drift; audit logs that can reconstruct what an agent did and who approved it; and a board report that explains adoption, benefit realised and open risk in one page.

The organisations that get there rarely moved fastest at the start. They fixed the data posture, picked a few experiences worth having, and made the governance gate quick enough that people actually used it. Secure enablement is not a brake on Copilot. It is the reason the rollout survives its first hard question from a regulator, a client or your own board.