How to Accept a Claude Cowork Enterprise Mac Pilot: 2026 Checklist

Symptom → You need Claude Cowork on managed Macs, but cannot show what it can access or what your controls can observe.
Fastest fix → Run a bounded pilot, test file and extension permissions, validate endpoint evidence, and expand only after the owner signs off.

This runbook is for enterprise IT managers preparing a managed macOS pilot, security leads assessing access and monitoring, and platform owners deciding whether a separate remote Mac environment belongs in the plan.

Last updated October 26, 2026; product details checked against Anthropic’s security architecture, desktop extension guidance, and enterprise plan documentation. Recheck those documents before deployment. Your MDM, EDR, identity, and retention results must come from your own test environment.

Before the pilot: bounded tasks versus open-ended access

Start with a defined task, an accountable owner, and a stop condition. Do not treat a Cowork pilot as permission to expose production signing credentials, CI secrets, or broad engineering shares. A desktop execution boundary does not by itself establish that your organization’s device management, monitoring, or compliance requirements are met.

Write the scope down before installing or enabling anything:

• Tasks: name the specific work the pilot will test, such as summarizing approved sample documents or drafting changes in a disposable project folder.
• Data: identify allowed sample data and explicitly excluded classes, including customer records, production source, signing material, and credentials.
• People: assign an IT owner, security reviewer, pilot user, and person authorized to stop the test.
• Stop conditions: define what triggers a pause, such as unexpected file access, an unapproved extension, missing endpoint evidence, or inability to revoke access.
• Evidence location: choose an approved place to store the test record without copying sensitive prompt content into general-purpose logs.

Make the pilot task narrow enough that you can distinguish expected access from accidental reach. Use synthetic or otherwise approved samples. Record the sample file paths and the expected read or write actions before the user starts.

Keep production secrets out of the test even if the pilot appears isolated. Isolation is one control to verify, not permission to increase the sensitivity of the data.

Treat a missing owner or unclear stop condition as a failed readiness check. The pilot should not start until someone can pause it and explain what evidence is needed to resume.

At enrollment: managed-device evidence versus account assumptions

Confirm that the organization can identify and manage the Mac, distribute the application through an approved process, and recover access when a user leaves the pilot. Apple documents device and user management as separate administrative concerns; use your own MDM records to confirm how those controls apply to the specific Mac and account in scope (Apple’s macOS device and user management documentation).

Do not collapse three distinct layers into one approval:

• Cowork or organization account: who can use the service and which organization-level controls apply.
• Local Mac user: which signed-in user owns the desktop session and can access local resources.
• Organization device policy: what MDM, application distribution, and endpoint controls actually enforce on that Mac.

A successful sign-in proves only that the tested account can sign in. It does not prove that the Mac is enrolled, that the local user has appropriate restrictions, or that the organization can revoke all access. Anthropic’s documentation describes account roles and permissions; compare those roles with your assigned administrators and users rather than assuming that an account role configures macOS policy (Anthropic roles and permissions).

Before the first task, capture these evidence fields:

• Device inventory identifier and MDM enrollment state.
• Application source and the installed application version.
• User identity for the Cowork session and the local Mac session.
• The person responsible for approving access and handling departure or suspension.

Apple’s application management guidance covers installation, management, updates, and removal. Test your organization’s actual distribution and removal path; do not infer that an app is centrally controlled merely because it appears on a managed device (Apple’s application management documentation).

If account, local-user, or device ownership is unclear, stop before testing data access. Resolve that identity chain first. For enterprise data handling, review Anthropic’s published description of its role for business customer data and compare it with your organization’s contract and data-processing review; the public description is not a substitute for your own legal and security assessment (Anthropic’s data processor and controller explanation).

During access setup: user-approved folders versus connector grants

Can Claude Cowork read Mac files the user has not authorized?

Do not infer the answer from a product description or a successful test on one folder. Verify the access boundary on the deployed version with non-sensitive samples. Anthropic describes Cowork’s desktop execution isolation and file-system controls, but those product-level descriptions do not certify how your organization’s MDM, endpoint tools, or local configuration behave (Anthropic’s explanation of how it contains Claude).

Use a controlled test with distinct locations:

• Put an approved sample in the folder the user is expected to grant.
• Put a harmless marker file in a separate, unapproved location.
• Test an allowed read and, if needed, a permitted write in a disposable folder.
• Record whether the unapproved marker is discoverable or accessible, and preserve the relevant event evidence.
• Repeat after changing the folder grant or ending the session, then record whether access changes as expected.

The result should state the exact path, user identity, operation, observed result, and time of the test. “The user selected a folder” is not sufficient evidence unless you can show which folder was selected and what operations were possible. If an unapproved location is reachable, pause the pilot and investigate before exposing additional data.

How should you separate connectors from local permissions?

Treat a SaaS connector and local Mac file access as different authorization paths. A connector can use a service-side identity and grant access to data that is not stored in the tested Mac folder. Conversely, a local folder grant does not establish what a connected service can retrieve.

For each connector in scope, record its identity, granted data range, approving owner, and revocation procedure. Test revocation rather than documenting only the intended setup. Keep connector credentials and local file permissions in separate rows of the evidence record so reviewers can see which control governs each path.

For any local extension or MCP server, verify its origin, configuration, identity, reachable resources, and removal process. Anthropic’s desktop documentation explains how to get started with local MCP servers; it does not prove that every locally configured server is approved or managed by your organization (Anthropic’s local MCP server guidance). If your organization cannot identify who approved a server or how to disable it, treat it as out of scope until those answers are available.

During validation: execution isolation versus endpoint visibility

Can Cowork’s isolation affect EDR monitoring?

It can change what your endpoint tooling observes, so test the deployed combination rather than assuming either full visibility or complete blind spots. Anthropic’s security architecture describes the application’s execution isolation and its boundaries. That description is not a guarantee that your particular EDR agent, log pipeline, or incident workflow will collect every event you need.

Run a harmless, pre-approved task while your security team checks the evidence it expects to use. Confirm whether your tools can associate relevant events with the correct Mac, local user, application, and time. Check that the investigation workflow can retrieve evidence without relying on a pilot user’s recollection alone.

At minimum, ask the security reviewer to validate:

• Whether the test session appears in the endpoint inventory and monitoring console.
• Whether the relevant application or process activity is visible to the tools your team relies on.
• Whether logs can be tied to a device and user identity with usable timestamps.
• Whether an investigator can distinguish the approved test from unrelated activity.
• Whether the team can preserve evidence and follow its incident process if the test behaves unexpectedly.

These are organization-side acceptance checks, not claims about universal EDR compatibility. If the execution boundary reduces visibility needed for investigation, record the gap, the compensating control, the person accepting the residual risk, and the date for review. If no acceptable compensating control exists, pause or narrow the pilot.

Also test the normal host-security controls independently. Verify MDM enrollment, device compliance state, EDR health, and relevant alert routing on the Mac itself. An isolated execution environment does not replace endpoint protection, and a healthy EDR status does not prove that file authorization is correct.

Before expansion: extension policy versus untested controls

How can your team restrict desktop extensions?

First identify what administrators can manage in the plan and version your organization actually uses. Anthropic publishes enterprise plan and role information, but a general plan description does not confirm that every control is available to your tenant or configured as your policy requires (Anthropic Enterprise plan documentation). Treat unclear capabilities as test items for an administrator, not as presumed features.

Build an extension register with the extension or server name, source, owner, identity used, data reachable, approval status, and disable or removal method. Then test the policy boundary with an approved configuration and a deliberately unapproved, harmless configuration. Confirm what the user can add, what an administrator can prevent or remove, and what evidence records the change.

Apply the same test to account controls and data-retention settings relevant to the pilot. Record the setting, the administrative role that changed it, and the observed effect. If public documentation does not answer whether a control exists or applies to your tenant, ask the administrator to verify it in the actual environment and retain the result.

Do not approve a control based only on a screenshot of a setting. Pair configuration evidence with a behavior test: the intended user should encounter the expected restriction, and the relevant administrative team should be able to explain how it is enforced.

At sign-off: evidence score versus assumption

Before expanding access, rehearse the exit path. Disable or suspend the pilot account using the organization’s approved process, revoke connector access, remove the test data from the Mac, and check for residual credentials or extension configuration. Record who performed each action, when it occurred, and the observed result. If the team cannot show that access was removed, the pilot is not ready for expansion.

Use this decision tool. Expand only when each applicable row has a named owner and supporting evidence. Remediate when the gap is understood and a bounded fix can be tested. Pause when access, monitoring, or recovery cannot be verified.

• If file access stays within the approved sample scope and the test record shows the paths and operations, continue to the next gate; otherwise, restrict access and repeat the test.
• If each connector and extension has a known identity, data range, owner, and revocation path, keep it in scope; otherwise, disable it or exclude it.
• If endpoint evidence supports your incident workflow, document the reviewer’s acceptance; otherwise, add an approved compensating control or pause.
• If account shutdown, connector revocation, local data cleanup, and credential review all produce auditable results, consider expanding within the approved task scope; otherwise, retain the pilot boundary.

The tables below are the sign-off record, not a substitute for evidence. Use “Pass” only when a reviewer can point to a test result or configuration record. “Conditional” means a named fix and owner remain open; it is not permission to expand. “Fail” means the control is absent, ineffective, or unverified.

Choose the disposition that matches the weakest unresolved control. Do not average a failed access test against several passed administrative checks.

For teams using individual managed Macs, the current approach may create inconsistent app versions, fragmented evidence, and extra device procurement and lifecycle work. A dedicated remote Mac can offer a separate macOS workspace to evaluate, but remote desktop access does not prove MDM enrollment, Cowork policy support, or EDR coverage. Review the current MacDate Mac node options and compare them with your existing fleet; use the Mac mini pricing guide when weighing ownership costs. Choose rental when you need a temporary, separable Mac environment and the published delivery details fit your controls. Keep local hardware for workloads that require physical access or a long-lived, tightly integrated endpoint. In either case, repeat this acceptance process on the actual environment before admitting sensitive work.