Microsoft Copilot Cowork — Complete Admin Playbook
↗ the IT admin playbook — turning Cowork on, governance controls, oversharing protection, pilot rollout, and the things that catch teams off-guard
On this page
The hub for this series — Microsoft Copilot Cowork — The Complete Guide — covers what Cowork is and how it works. This spoke is the IT admin playbook.
TL;DR
- Cowork is off by default — nothing happens until an admin turns it on and chooses who gets access
- It inherits user permissions — it can only reach what the user already can; it acts as them, inside the same guardrails
- Set up billing and spend caps before users start — task work is billed in Copilot Credits, so wire up the Cost Management dashboard, set limits, and turn on alerts first
- Audit SharePoint before broad rollout — Cowork surfaces over-sharing fast
- Pilot first — start with 10–20 users, set a spend cap, review the outputs and spend, then decide go/no-go
- Governance is identity-bound — Cowork acts as the user, with sensitivity labels, encryption handling, and Communication Compliance supported today; several other Purview controls (audit, eDiscovery, DSPM, Insider Risk, DLP, and more) aren’t enabled for Cowork yet — check the Cowork Purview page
The rollout at a glance
Five moves take you from “off by default” to “rolled out with the budget under control.” Each one has its own section below.
flowchart TD
A[Make Cowork visible - Copilot Settings] --> B[Set up billing and a spending policy]
B --> C[Pilot via a Specific-groups policy]
C --> D[Review usage and what it did]
D --> E{Go or no-go?}
E -->|Go| F[Expand to more groups]
E -->|Not yet| C
The order matters: billing and caps come before the pilot, so no one runs up a surprise bill while you’re still learning what Cowork costs for your team’s work.
How to enable Cowork at GA
If you’re an IT admin, here’s how to turn Cowork on:
- Make Cowork discoverable — in the Microsoft 365 admin center → Copilot → Settings, turn on “AI experiences enabled by usage-based billing.” This controls visibility — whether users can see Cowork. It’s off by default. One nuance worth knowing: setting up usage-based billing for a user overrides this toggle. A user who’s in a spending policy will see Cowork even when discovery is off — so the toggle really only hides Cowork from users you haven’t set up for usage-based billing yet (Microsoft’s own words).
- Set up billing and a spending policy — go to Copilot → Cost Management and select Get Started. Activating usage-based billing with a spending policy is what actually turns Cowork on and scopes who can use it (All users or Specific groups). Its work is billed in Copilot Credits, so do this before users start. Full walkthrough in the next section.
- Check model availability — Cowork runs on Anthropic models (Opus 4.8, Sonnet 4.6) through Microsoft’s multi-model system. If your tenant manages AI model providers, confirm Cowork’s models are allowed.
- Scope the pilot — keep access tight at first. In your Cost Management spending policy, target Specific groups (a security group of your pilot users) rather than All users, and decide separately which plugins Cowork can reach (see governance below). Pilot-first is the sane default.
- Communicate — tell your users it’s available, what it does, and that it checks in before sensitive actions.

Step 1 — the discovery setting under Copilot → Settings. It even tells you the next move: go to Cost management to grant access. (Shown in a demo tenant.)
⚠️ Do this before you enable it broadly: review your SharePoint permissions and information governance first. Cowork can reach anything the user can reach — so if your permissions are messy, Cowork surfaces that mess. Full remediation playbook: SharePoint oversharing controls for Copilot.
Set up billing and cost controls
Cowork’s task work is billed in Copilot Credits — usage-based, on top of the Microsoft 365 Copilot licence each user already needs. The price of each task comes from four things: the model it uses, how much context it retrieves, how many tool calls it makes, and how long it runs. Because that varies task to task, the most important admin job at rollout is to set the budget guardrails before anyone starts.

The Cost Management dashboard (Copilot → Cost management). Note the two banners: billing doesn’t start until after the grace period, and this experience covers Cowork and the Work IQ API today.
It all lives in one place: the Cost Management dashboard in the Microsoft 365 admin center. The order I’d do it in:
- Turn on usage-based billing. Choose how you want to pay: pay-as-you-go (PayGo — flexible, billed at $0.01 per Copilot Credit), prepaid credits (P3 — commit to a volume up front for a discount), or existing capacity you already hold.
- Connect an Azure subscription if you’re billing at any real scale — that’s what carries the spend.
- Define spending policies. Decide who can consume credits, how much they can use, and where the spend is allocated. You set these at the tenant, group, and user levels — including user-level caps written inside a group policy.
- Set hard caps and usage alerts. Caps stop overspend before it happens; alerts tell you when spend crosses a threshold you care about, and let you pick who gets notified. Set both — don’t rely on remembering to check a dashboard. Not sure where to set the cap? Estimate your team’s expected monthly burn first with the Cowork Cost Calculator.
- Know your two reporting tabs. The Overview tab is your real-time “where are we spending, and are we on track?” snapshot — total consumption and remaining capacity. The Consumption tab is the drill-down — usage by user, group, service, or agent — so you can find the heavy users and the cost drivers.


Those two tabs are empty here because no credits have been spent yet. Once usage starts, the same views fill in — this is what you’ll actually be watching:

The Overview tab once credits are flowing — total used, the prepaid-vs-pay-as-you-go split, active users, and a Top actions row flagging anyone near a limit.

And the Consumption tab with real data — drill into any user, group, or service to find your heavy users and cost drivers. (Full populated walkthrough in the Cost Management hub.)
💳 Frontier grace period — your setup window. If your tenant had at least one user who used Cowork in the Frontier program (30 March–16 June 2026), you get a grace period: you’re not billed for Cowork until 1 July 2026. Treat that window as free setup time — turn on billing, set your caps and alerts, and allocate budgets before the meter starts. (Full detail in the pricing spoke.)
Two honest notes:
- The per-task price shown to the user, in credits, is coming soon after GA. At launch a user can request more credits from inside Cowork when they hit a wall, but the live “this task cost X credits” readout for them is still rolling out.
- Cost drifts down over time — models get cheaper, Cowork gets better at matching the right model to a task, and context and tool use get more efficient. So treat your first month’s numbers as a starting point to refine, not a fixed cost.
Full reference: Copilot Credits and cost management on Microsoft Learn. Our deep dive is the pricing & cost-management spoke. For the full cross-service cost-management picture — spending policies, the two admin centres, P3, and roles — see Microsoft 365 Copilot Cost Management & Billing.
What the setup looks like, step by step
Selecting Get started walks you through one short wizard. Here’s the whole thing end to end (from a demo tenant, identifiers redacted):

1. Activate the default spending policy — pick the billing method (subscription redacted) and choose whether to cap monthly spend.

2. Caps and alerts — add an optional per-user limit, and choose who gets the weekly spend alert (recipients redacted).

3. Review the policy. This is the one that matters: User and group access = All users and Agents and services = Copilot Cowork. Switch access to Specific groups to scope a pilot instead.

4. Once active, the Configuration tab lists your policy (here, 200 credits per user per month). Overview and Consumption are where you watch spend, and prepaid P3 credits live here too.

5. Done — Cowork is live for the people in that policy. Add more policies any time to scope specific groups or services.
Why a user can’t see Cowork in Microsoft 365 Copilot
The five usual suspects, in rough order of likelihood:
- The discovery setting is off — “AI experiences enabled by usage-based billing” (Copilot → Settings) hasn’t been turned on, so Cowork stays hidden for anyone who isn’t already set up for usage-based billing. (If a user is in a spending policy, that overrides this toggle and they’ll still see it — so this one mostly bites users you haven’t added to a policy yet.)
- Usage-based billing isn’t set up — Cowork is gated by usage-based billing, so until an admin creates a spending policy in Copilot → Cost Management, there’s nothing to use. (A user can request access from inside the experience; it shows up in the admin’s credit requests.)
- No Copilot licence — the user needs the paid Microsoft 365 Copilot seat (the USL).
- They’re not in a spending policy — access is scoped by policy; if the user isn’t in the All-users policy or a Specific-groups policy that includes Cowork, they won’t see it.
- The region or models aren’t available — Cowork runs on Anthropic models and is limited to Anthropic-supported regions; if your tenant manages model providers, those models may need to be allowed first.
If you’ve ruled out all five and a licensed user still can’t see it, give it time to propagate — tenant changes can take a while to roll through — before raising a ticket.
“Cowork disappeared for people who already had it” — the Frontier-to-GA gotcha
A common one right after GA: people who were using Cowork during the Frontier program suddenly can’t see it. Usually that’s not a bug — it’s the GA gating kicking in. At GA, Cowork sits behind two gates that weren’t there in the preview: the discovery setting (off by default) and a usage-based billing spending policy. If neither is in place for those users, Cowork drops out of their Microsoft 365 Copilot.
To bring it back, do either (ideally both):
- Turn on the discovery setting (Copilot → Settings) so Cowork is visible tenant-wide, and/or
- Set up a spending policy (Copilot → Cost Management) that includes those users — that’s what actually lets them use it, and it overrides the discovery toggle for everyone it covers.
Keep one thing separate in your head: the grace period is about billing, not visibility. If your tenant qualifies, you’re not billed until 1 July 2026 — but the grace period doesn’t make Cowork appear on its own. Discovery plus a spending policy is what controls who sees and uses it. So if Cowork went missing, look at the gates, not the grace period.
“My users clicked ‘request access’ — where do I approve it?”
If a licensed user opens Cowork before you’ve set up billing, they’ll see a request access prompt. Here’s the part that trips admins up: that request is for Copilot Credits (usage-based billing), not a licence. So when you follow the “View request” alert and it drops you on the licensing page, there’s nothing to add — your users are already licensed, and licensing was never the gate. It’s the spending policy they’re missing.
Approve it in the right place:
- Go to the Microsoft 365 admin center → Copilot → Cost Management → Overview.
- In the Top actions section, select View requests.
- The Credit requests page lists each requester with their licence status and current policy — anyone blocked shows as “Not in a policy.”
- Add those users to a spending policy to grant access (or create a new policy scoped to them). If you haven’t turned on usage-based billing at all yet, run the enablement steps above first — activating a spending policy is what actually switches Cowork on.
- Then give it time to land. Adding someone to a policy isn’t always instant. Like a lot of Microsoft 365 changes, it can take anywhere from a minute to around 30 minutes to propagate — so if a user still sees the Request access nudge right after you add them (even after a browser refresh), that’s usually the change catching up, not a broken setup. Wait a short while and refresh before you go hunting for a bug.
So the fix for “there’s nothing to add on the licensing page” is simple: you’re on the wrong page. The access your users need is a spending policy in Cost Management, not another licence. Full reference: Managing usage-based billing and Copilot Credits on Microsoft Learn.
Governance — what’s built in
The single most reassuring thing about Cowork for an admin: it inherits the user’s identity and permissions. It can’t see, touch, or send anything the user couldn’t already — it’s acting as them, inside the same guardrails.
Here’s what actually protects Cowork today, and what’s still on the way. Because Cowork runs long, multi-step work across apps, Microsoft documents its compliance support separately from the rest of Microsoft 365 Copilot — and several Purview solutions aren’t enabled for Cowork yet. Plan against the Cowork Purview support table for the current status.
Protecting Cowork today:
| Control | What it does for Cowork | Status |
|---|---|---|
| Entra ID identity | Cowork acts under the user’s identity and permissions — no new standing access is created. | Live |
| Approval checkpoints | Sensitive actions pause for explicit user approval (see below) — a real governance lever, not just UX. | Live |
| Conditional Access | Sign-in conditions (device, location, risk) apply through Microsoft 365 sign-in. | Live |
| Sensitivity labels | Labels are displayed, and inherited onto new Word/PowerPoint/Outlook content Cowork creates from labelled sources. | Supported |
| Encryption handling | Encrypted content is honoured — Cowork checks the VIEW and EXTRACT usage rights before returning data. | Supported |
| Communication Compliance | Cowork prompts and responses are in scope for Communication Compliance policies. | Supported |
| Auditing (unified audit log) | Cowork prompts, responses, and actions are captured in the Purview audit log. | Supported at GA |
| DSPM / DSPM for AI | Cowork AI activity shows in DSPM for AI (activity explorer) for data-risk insights and one-click policies. | Supported at GA |
| eDiscovery | Cowork content is discoverable for legal holds and investigations. | Supported at GA |
| Insider Risk Management | Cowork activity is in scope for Insider Risk Management policies. | Supported at GA |
Still rolling out — confirm current status on the Cowork Purview page before you rely on any of these:
| Purview solution | Status for Cowork |
|---|---|
| Data Lifecycle Management | GA 22 June 2026 (per Microsoft’s GA announcement) |
| Data Loss Prevention (DLP) | Coming soon |
| Data classification | Not supported yet |
| Compliance Manager | Not supported yet |
⏳ Read this before you promise compliance coverage. Cowork’s Purview support is documented separately from the rest of Microsoft 365 Copilot, and it’s a moving target. The good news at GA: audit log, DSPM, eDiscovery, Insider Risk Management, Communication Compliance, sensitivity labels, and encryption handling are all supported. Still to come: Data Lifecycle Management (GA 22 June 2026) and Data Loss Prevention (coming soon) — and data classification and Compliance Manager aren’t supported for Cowork yet. The Cowork-specific Purview page is the one to plan against, so confirm current status there before you rely on any single control.
Approving plugins and custom skills — the review
Out of the box, Cowork reaches your Microsoft 365 — Outlook, Teams, SharePoint, OneDrive, Office files. Two things widen that reach, and both deserve a deliberate yes:
- Plugins connect Cowork to systems outside M365 — a CRM, a ticketing tool, a data warehouse. (See the skills & plugins spoke.)
- Custom skills (
SKILL.mdfiles) teach Cowork a repeatable job in your own words.
Treat each plugin as its own decision, one at a time — not a blanket “allow all.” A short review to run before you approve one:
- Who’s asking, and for what job? Name the actual workflow — “Sales wants monday.com so Cowork can build campaign boards.” If there’s no real job behind it, it doesn’t need to be on.
- What can it reach — and can it write? Many connectors are read-only; some can also write (create or update records in that system). Read-only is the safer default; allow write only where the workflow genuinely needs it.
- Whose credentials does it use? Confirm how the connector signs in and whose access it inherits, so the plugin can’t quietly reach further than the user could.
- Where does the data go? Check what leaves your tenant, where it lands, and whether that’s acceptable for the data classes involved.
- How will you keep an eye on it? Plugin oversight for Cowork is still maturing (see the compliance note above), so lean on the approval checkpoints and a deliberate review rather than assuming full audit coverage.
Microsoft keeps a dedicated “Manage plugins for Copilot Cowork” page on Microsoft Learn for the admin controls — admins can deploy plugins to the org or specific groups, and restrict which plugins are visible in the store. A sensible default: keep them off until reviewed, then enable the ones a team genuinely needs.
SharePoint oversharing — the most important control to check first
The “permissions amplifier” effect: Cowork can surface anything the user has access to, even if they didn’t know they had access to it. If your SharePoint permissions are messy, Cowork makes that mess visible to the user.
For the full remediation playbook see SharePoint oversharing controls for Microsoft 365 Copilot.
Pilot rollout playbook
Don’t roll Cowork out to everyone on day one. A scoped pilot tells you what it actually costs and where the rough edges are, on a small blast radius.
A practical pilot plan:
- Pick a small group — about 10–20 users across 2–3 roles, so you see a real spread of light, medium, and heavy tasks.
- Scope access to just that group — in your Cost Management spending policy, target Specific groups (a security group of your pilot users), not All users (see enablement).
- Set a spend cap for the pilot group — a group-level budget with user-level caps inside it, plus an alert at, say, 75% of the cap so nothing is a surprise.
- Brief the group — what Cowork does, the approval-checkpoint pattern, what’s safe to automate, and what to escalate.
- Run for 2–4 weeks and collect both numbers (credit usage, which tasks) and feel (what saved time, what missed).
- Review what it did — go through the conversations and outputs Cowork produced (Cowork activity is captured in the Purview audit log — see governance above), and use the pilot as a forcing function to fix any SharePoint oversharing it surfaced.
- Decide go / no-go against criteria you set up front — for example: spend stayed within cap, no governance surprises, and the group would miss it if you took it away.
A concrete starter policy you can adapt: 10–20 users · Specific-groups access (a pilot security group) · a group spend cap with a 75% alert · 3-week run · weekly review of outputs and spend · expand only if spend held and no oversharing surfaced.
Approval checkpoints — what they protect
The checkpoint system is Cowork’s most important governance feature, and it’s worth understanding as a control, not just a prompt.
- Actions that send or change something wait for approval. Sending an email, posting to Teams, scheduling a meeting, creating a file — each pauses for an explicit yes, with a risk indicator and a button that matches the action (Send, Post, Create). If Cowork drafts the wrong thing, you simply don’t approve it.
- You can pause, resume, or cancel at any time — see a run going sideways and you stop it immediately.
- You can redirect mid-task. “Actually, focus on the financial data, not the customer emails” — and it adapts within the current task.
- A “skip future prompts” option exists. A dropdown lets users stop being asked for similar low-risk actions — convenient, but it trades safety for speed.
For an admin, the honest framing is that checkpoints reduce the blast radius — they’re not a substitute for review. A user can still approve the wrong action, or switch off prompts for an action type. And not every internal step shows a prompt — the gate is for sensitive actions like sending, posting, scheduling, and creating, each with a risk indicator on the medium- and high-risk ones. So the realistic worst case isn’t “nothing”; it’s “a user approved something they shouldn’t have.” Brief your people to treat each approval as a real decision, and to keep the skip-prompts option for genuinely low-stakes, repetitive work.
What to tell legal and security
When you bring Cowork to a security or legal reviewer, here’s the short brief — forward it as-is. Every line is something you can stand behind at GA:
- It’s off by default. Nothing runs until we turn it on and choose who gets access.
- It’s identity-bound. Cowork acts as the signed-in user, under their Entra ID — it creates no new standing access and can’t reach anything the user couldn’t already.
- Permissions are inherited, not widened. If a user can’t open a file today, Cowork can’t either.
- Sensitivity labels follow the data end-to-end, on what goes in and what comes out.
- What’s covered today: sensitivity labels are displayed and inherited, encrypted content is honoured, and Cowork prompts and responses are in scope for Communication Compliance.
- Sensitive actions wait for a human. Sending, posting, scheduling, and creating each pause for explicit approval.
- Name the gaps honestly: Cowork’s Purview support is documented separately from the rest of Microsoft 365 Copilot. Per Microsoft’s Cowork Purview page, supported at GA are auditing, eDiscovery, DSPM, Insider Risk Management, Communication Compliance, sensitivity labels, and encryption handling. The gaps to plan around: Data Lifecycle Management (GA 22 June 2026), Data Loss Prevention (coming soon), data classification, and Compliance Manager. Check that page for current status.
The one-paragraph version: Cowork operates inside your existing Microsoft 365 trust boundary, as the user, with the same permissions as the rest of your tenant, sensitivity-label and encryption handling, Communication Compliance support, and an approval gate on anything that sends or changes something. Auditing, eDiscovery, DSPM, and Insider Risk Management are supported at GA; Data Lifecycle Management (GA 22 June 2026), Data Loss Prevention (coming soon), data classification, and Compliance Manager are still rolling out — so plan around those and track the Cowork Purview page.
What Cowork can’t do (yet)
Set expectations honestly with your leadership and users — over-promising is the fastest way to lose a pilot:
- Documented limits (from Microsoft’s FAQ): Cowork can’t access or edit files stored locally on a device (it works in OneDrive and SharePoint); it can’t delete files or folders in OneDrive or SharePoint; and attachments must be under 200 MB. (Encrypted content is handled per the user’s usage rights — see the protection table above.)
- Custom skills aren’t validated by Microsoft — user-created
SKILL.mdskills run as written, so review their outputs. - Region-limited — Cowork runs on Anthropic models and is currently limited to Anthropic-supported regions, so “available worldwide” comes with that caveat. Confirm availability for your users.
- External systems need plugins or skills — Cowork reaches your Microsoft 365 out of the box; a CRM, ticketing tool, or data warehouse needs a plugin, a custom skill, or an exported file. (See the Skills & plugins spoke.)
- It’s a permissions amplifier — if your SharePoint permissions are messy, Cowork makes that mess visible to users who shouldn’t see it. Fix this before rollout, not after.
These are solvable, and several are on Microsoft’s roadmap — but check Microsoft’s GA documentation before treating any limit as temporary, and know them before you promise the world.
Known issues
Cowork is new and evolving fast. For the current, authoritative list of limitations and fixes, check Microsoft’s Cowork documentation — and remember Data Loss Prevention (DLP) support is still rolling out (see the governance note above).