Copilot Cowork Security for Microsoft Copilot Cowork with Approvals, Permissions and Admin Controls

During the Frontier and Preview programs, admins allowed or blocked people by configuring the Cowork entry under Agents, All Agents in the Microsoft 365 admin center. That control no longer works. Microsoft's admin guide is direct about it: the Cowork agent entry "is still visible under Agents, All Agents, but any configuration on it has no effect on who can use Cowork. Access is granted only through a spending policy that selects Cowork."

The guide adds a warning that catches finance-minded admins: "A spending policy is an access control, not only a budget." A policy with a limit of one credit still grants access. To keep someone out, you leave them out of every spending policy that selects Cowork. Lowering their limit does not do it.

If your security review signed off on Cowork during Frontier with an allow list on the agent entry, that sign-off described a control that has since stopped controlling anything. Microsoft's own fix is short: put the allowed users into an Entra security group, create a spending policy under Copilot, Cost Management, Configuration, scope it to that group and select Cowork. Then check for older policies that also select Cowork and reach a wider group, because any one of them grants access.

The same separation applies to models. Turning off the Anthropic model family "has no effect on whether a user can access Cowork," and Auto keeps choosing from the remaining models. That is the right design for continuity. It means a model decision is not an access decision, and neither one is an action decision.

Microsoft calls the action approval system "Cowork's primary safety mechanism." Before sending, posting, scheduling or modifying files, Cowork shows a preview and waits. Approval prompts for medium and high risk actions carry a risk level indicator. That is a good default, and it is the reason most Cowork tasks are low risk.

The approver, though, is always the user who owns the session. The approval options in Microsoft's Use Cowork guide show how quickly a careful default becomes a habit:

Microsoft limits the blast radius on purpose: "Approvals don't persist across conversations." That keeps a mistaken Always allow from living forever. It does not add a second person. For most work that is fine. For a vendor bank detail change, a refund above a threshold, a customer record export or an outside email with an attachment from a labeled folder, a US auditor will ask who besides the requester approved it. A self-approval in a chat dialog is not an answer to that question.

The pain story above is the textbook case. With an approval gate for AI agent actions on the ERP plugin, the bank detail change would have waited for a named controller, outside the clerk's session, with the source email attached as evidence.

Event-driven tasks run "when you receive a matching email, or when a Teams message arrives (including when you're @mentioned)." The user describes the trigger and the work, Cowork proposes a Set up trigger card with the event, the instructions and the permissions the task needs, and the user arms it. Scheduled prompts work the same way on a timer, up to 25 per user.

This is the part of Cowork where indirect prompt injection stops being theoretical. The content of a matching email is untrusted input, and with an email trigger the sender decides when the task runs and what it reads first. Microsoft's safeguards are sensible and worth knowing exactly:

• Runs with the user's permissions. "Each automated task runs as the user who created it."
• Draft and approve by default. "By default, Cowork asks the user for approval before an automated task sends an email, posts a message, or changes a shared system."
• Pre-authorization is allowed. "Users can pre-authorize actions when they create a task." On an unattended task, that removes the only person in the loop.
• Rate limits and loop protection. A task cannot fire too often or trigger itself in a loop.
• Audit. Automated task activity lands in the unified audit log, and Purview policies apply.

Two practical rules follow. Do not let users pre-authorize write actions on tasks triggered by external email, and route any task that changes a shared system through a gate that evaluates the call itself, not the summary the agent shows. Purview's Insider Risk Management has a Risky AI usage policy template that detects prompt injection attempts, which is useful after the fact. A gate on the plugin call decides before the action runs. Our page on prompt injection protection covers the detection side in more depth.

Plugins are where Cowork reaches outside Microsoft 365, and the admin controls are real. Admins can deploy, allow or block each plugin under Agents, Tools. Publishing a plugin to the whole organization waits for a tenant administrator. Connectors cannot be authorized on a user's behalf; each user completes the sign-in or consent flow. Plugin activity appears in Purview audit under Copilot activities.

Four details from Microsoft's plugin admin guide shape the rest of the review:

• Tools are discovered at runtime. "When a plugin declares an MCP server, Cowork calls initialize and tools/list at runtime to discover available tools automatically." The admin approves a package; the tool list behind its server URL can change afterward without a new package.
• Sharing cannot be switched off tenant-wide. "There's currently no single tenant setting that turns off plugin sharing for every user." Organization-wide publishing needs approval, but a user can still share an uploaded plugin with specific people.
• Blocking is not instant for running work. "Blocking takes effect for new conversations. Conversations already in progress that use the plugin continue until they end."
• Custom skills are unreviewed. The application card says custom skills "are not validated by Microsoft," and plugin skills and connectors come from third-party publishers.

Plugin tools can now also accept files from the session as input, so a connector tool can attach a workspace file to another system. That is useful, and it is one more argument a policy should be able to inspect.

Purview is the strongest part of the Cowork security story, and Microsoft documents Cowork's support separately because long-running, multi-step work "can result in different behaviors and feature support." As of October 9, 2026 the Purview page for Cowork lists:

Purview answers what data moved and who could see it. It does not hold an action for a second approver, and its audit records describe Cowork's activity, not the business rule that should have applied to a specific plugin call. Keep both records. Your AI agent audit trail should show who triggered the task, which call ran, which rule applied and who approved it.

1. Rebuild access as spending policies. Scope each policy that selects Cowork to an Entra security group. Remove anyone who should not have access from every such policy. Ignore the old agent entry.
2. Decide on Anthropic models deliberately. The toggle can be scoped to users or groups. Check the model list for any model that requires data retention by the provider. Microsoft flagged that for the Fable 5 preview at GA and left it off until an admin turned it on.
3. Keep browser use off until you need it. Cowork Browsing is disabled by default. When you turn it on, rely on Edge allow lists and Conditional Access, and target it to groups with the Edge policy.
4. Write a pre-authorization rule. No pre-authorized send, post or change on tasks triggered by external email. Teach users that Approve All releases everything in the queue.
5. Allow plugins by team, not tenant-wide. Block what nobody needs, approve organization-wide publishing only after review, and remember a block does not end running conversations.
6. Turn on labels and DLP. Enable sensitivity labels for SharePoint and OneDrive so Cowork can honor encryption, and extend DLP policies to Copilot.
7. Put write plugins behind a gate. For plugins you build, route the MCP server URL through a gateway that evaluates each call and holds the risky ones for a named approver who is not the requester.
8. Set credit limits per group. Usage is billed in Copilot Credits at 0.01 USD per credit on pay as you go, per Microsoft's June 16, 2026 announcement. Limits cap spend; they do not control access.

The platform neutral version of this list is our page on AI agent security best practices. If Cowork sits next to Copilot Studio agents and Agent 365 in your tenant, the Microsoft 365 Copilot security and Microsoft Agent 365 security pages cover those layers.

Three of six rows end without a purchase from us. If you are comparing options, the buyer guide for Copilot Cowork sets six of them side by side, and the MCP server security page covers the server side of the gate.