Copilot Cowork Can Now Edit Your Intranet — 7 Guardrails

Microsoft made Copilot Cowork generally available on June 16, 2026 (announcement). Cowork can execute multi-step tasks that include browser automation — which means it can now log into your SharePoint intranet with a user identity and edit pages, publish news, and update lists. That is a material change in the SharePoint risk model. This post is our SharePoint Support Team's seven-guardrail baseline for governing Cowork on any tenant that has a SharePoint intranet.

The Cowork Risk Model in One Paragraph

Cowork acts on behalf of a user. It picks up the user's identity, opens a browser session with their credentials, and drives the browser through a task. That means every permission the user has, Cowork has. And every action Cowork takes appears in the audit log under the user's identity — not a separate service account, unless you configure it that way. So the risk is not "an unknown AI writing to the intranet" — it is "the intranet was edited by someone with the user's rights, at Cowork's speed, without the human being in the loop for every step."

The Microsoft doc Copilot Cowork: What's new covers the capability set. What follows are the operational guardrails to run it safely.

The 7 Guardrails

Ship these in order. The first three are non-optional for regulated tenants; the last four are strongly recommended.

Guardrail 1 — Dedicated Cowork service account (not user impersonation)

What: Configure Cowork to run under a dedicated service account with a scoped Entra role, not under the requesting user's identity.

Why: User-impersonation Cowork means every action appears in audit as the user, not as Cowork — which makes forensic investigation nearly impossible ("did Alice edit this page, or did Cowork edit it while pretending to be Alice?"). A dedicated service account makes the audit trail explicit.

How: In the Cowork admin surface, configure the "execution identity" for the Cowork agents you deploy. Create a Microsoft 365 service account (e.g., `[email protected]`), assign only the SharePoint permissions the agent needs, and require Cowork to authenticate as that account. Rotate the credentials on a defined cadence.

Guardrail 2 — Restricted site scope (allowlist, not full tenant)

What: Explicitly allowlist the SharePoint sites Cowork can access. Do not let Cowork operate against the full tenant.

Why: Cowork with tenant-wide access can be steered toward any site the identity has rights to. An allowlist reduces blast radius when a prompt injection or misconfiguration occurs.

How: Grant the Cowork service account (from Guardrail 1) explicit Contribute permissions on the 3 to 10 sites where it is intended to operate. Do not grant tenant-wide roles like SharePoint Administrator. Review the allowlist quarterly.

Guardrail 3 — Purview audit filter for Cowork activity

What: Build a saved Purview audit filter that surfaces all Cowork actions, cross-referenced with the service account identity from Guardrail 1.

Why: Cowork can execute dozens of actions in a single task. Without a saved filter, tracing what it did is a full-day forensics job. With a filter, it is a 5-minute review.

How: In Purview → Audit → Search, build a query that filters by the Cowork service account UPN and the SharePoint activities of interest (PageEdit, PagePublish, ListItemUpdate). Save the query and share it with the SharePoint operations team. Review weekly.

Guardrail 4 — DLP for Cowork prompts

What: Ship a Purview DLP policy that evaluates Cowork prompts before execution — same prompt-time enforcement model as DLP for Copilot.

Why: A Cowork prompt like "publish a news post announcing our Q3 earnings" could execute before the earnings are public. DLP for Cowork catches that.

How: Extend the 5-policy DLP pattern (see the DLP-for-Copilot post) to include the Cowork location. Confirm the "Prompt evaluation" action is enabled — this evaluates the prompt itself, not just the eventual response. This is the newest DLP surface and is worth ramping up carefully.

Guardrail 5 — Sensitivity label gating on target content

What: Any SharePoint page, list, or file with a sensitivity label of Confidential or higher should be excluded from Cowork write access via label conditions.

Why: Cowork editing a Confidential page during an autonomous task is a compliance incident regardless of intent. Label gating prevents the write action from proceeding.

How: Use Purview sensitivity label settings to enforce "no automated modification" on Confidential + Highly Confidential labels. Combine with SharePoint site-level Cowork exclusions on labeled sites. Verify by attempting a write from a test Cowork task — it should be blocked.

Guardrail 6 — Business-hours-only execution

What: Constrain Cowork execution to business hours in the tenant's primary time zone, with off-hours execution requiring explicit approval.

Why: Cowork is a new attack surface. Off-hours automated writes are much harder to catch quickly. Business-hours-only means a human is likely available to notice and roll back.

How: Cowork's scheduling controls let you define allowed run windows. Set them to 8 AM–6 PM in the tenant's business time zone, or per-user based on their working hours. Off-hours execution requires an approval workflow that pages an on-call SharePoint operator.

Guardrail 7 — Human-in-the-loop review for page publishes

What: Cowork page-write actions land in a draft state and require a human approval before publishing to the live intranet.

Why: A published intranet page is visible to every employee immediately. The blast radius of a bad Cowork publish is the whole company. Draft-plus-approval is a low-friction control that prevents the visible incident.

How: Configure the target SharePoint sites' page approval workflow. Set the workflow trigger to any page created or modified by the Cowork service account. Route approval to a named human owner. Cowork sees the draft as saved; the human sees the approval task in Teams.

Example Cowork Task — And What Its Audit Trail Looks Like

Here is a representative task and what you should expect to see in the audit log.

Task prompt: "Publish a news post on the HR site announcing the updated PTO policy. Include the policy PDF and add a link to the benefits FAQ."

Cowork actions:

• Opens SharePoint HR site with the Cowork service account identity.
• Creates a new news post page.
• Uploads the policy PDF from the source SharePoint library.
• Adds a link to the benefits FAQ (already on the site).
• Saves as draft.
• Notifies the approving human via Teams.

Purview audit events (filtered by the Cowork service account):

• `PageAdded` — new news page in the HR site.
• `FileUploaded` — the policy PDF.
• `PageModified` — link added.
• `PageDraftSaved` — draft state confirmed (Cowork did not publish).
• No `PagePublished` event — publish happens only after human approval.

That last one is the tell. If you see `PagePublished` from the Cowork service account, Guardrail 7 has been bypassed and something is misconfigured.

Reviewing Cowork Actions — Weekly Cadence

Our team's weekly review pattern:

• Open the saved Purview audit filter from Guardrail 3.
• Filter by the last 7 days.
• Scan for any `PagePublished` events attributed to Cowork — investigate every one.
• Sample 5 random Cowork tasks. For each, walk the audit trail. Does it match the intended prompt?
• Cross-reference Cowork actions against sensitivity-labeled content. Any label crossings get investigated.
• Log dispositions in the governance channel.

Fifteen minutes a week. The alternative is discovering three months later that Cowork has been publishing news posts nobody approved.

When Not to Use Cowork

Cowork is powerful. It is also new. There are cases where the answer is "not yet":

• Executive comms sites (comp, board materials, M&A). Human-only edits.
• Legal repositories with attorney-client privilege. Human-only edits.
• Compliance evidence sites (SOC 2, HIPAA audit binders). Human-only edits — Cowork edits complicate audit trails.
• Public-facing sites (extranet, partner portals). Higher blast radius, human review required.

Cowork excels at internal knowledge management, HR announcements, IT status pages, and other high-volume low-sensitivity content. That is where to start.

Getting Started This Week

• Read the Cowork GA announcement and the what's new doc end to end.
• Create the dedicated Cowork service account (Guardrail 1). Do not skip this.
• Allowlist 3 pilot sites for Cowork execution (Guardrail 2). Do not go tenant-wide.
• Build the Purview audit filter (Guardrail 3) and share it with the SharePoint operations team.
• Extend your existing DLP policies to the Cowork location (Guardrail 4).

Guardrails 5, 6, and 7 come in the second week as you calibrate on the pilot results. Do not enable Cowork for the wider organization until the seven guardrails are in place and reviewed.

Expert help from our SharePoint consultants

Our SharePoint Support Team is running Cowork rollouts for enterprises now — including the service account architecture, the audit filters, and the human-in-the-loop workflows that keep Cowork useful without creating a compliance mess. If you want help sequencing the seven guardrails, extending your Purview DLP to the Cowork location, or scoping the pilot sites, talk to our SharePoint consultants or contact us for a Cowork readiness call. The organizations getting Cowork right today are going to have a durable productivity advantage over the ones that either rushed it or blocked it entirely.