Claude Cowork Security Guide: Permissions & Enterprise Controls

Claude Cowork security is not something you configure once and forget. It's a layered governance model — organisation policies, team-level permissions, user-level connector access, and plugin sandboxing — and every layer matters when you're deploying an AI agent across hundreds or thousands of knowledge workers.

Most enterprises start with the wrong question: "Is Claude Cowork secure?" The right question is: "How do we configure Claude Cowork so that our security requirements are actually enforced?" This guide answers that question. Everything from admin console settings to connector scope management, data residency, and audit logging — the practical controls your CISO needs before sign-off.

If you're evaluating Claude Cowork deployment for your enterprise and need help navigating the security architecture, our Claude security and governance service covers the full review. For now, here's how the controls actually work.

Understanding the Claude Cowork Permission Model

Claude Cowork operates on a three-tier permission architecture: Organisation, Team, and User. This mirrors how enterprise IT governance typically works, and it's intentional. Anthropic designed Cowork to slot into existing IAM frameworks rather than require you to build a parallel governance structure.

At the Organisation level, your Workspace Admin sets the baseline: which connector categories are permitted, which plugin sources are trusted, whether users can install connectors independently or require admin approval, and what data handling policies apply. These are hard limits that no team or user can override.

At the Team level, team admins can further restrict — but not expand — what the organisation policy permits. A finance team might disable all external document connectors even if the organisation allows them. Legal might restrict Cowork to read-only access on all connectors. These team-level policies let department heads enforce their own compliance requirements without needing to involve IT for every configuration change.

At the User level, individuals authorise their personal connector connections — Gmail, Google Drive, Slack, DocuSign, and so on — within the bounds set by their team and organisation policies. When a user connects their Gmail account, they're granting Cowork access to their own mailbox only. That OAuth token is user-scoped, not organisation-scoped, which is a critical security boundary many teams overlook when reviewing Claude Cowork connector integrations.

Connector Security and OAuth Scope Management

Connectors are the primary attack surface in any Cowork deployment. When Claude can read email, access SharePoint, query a CRM, or write to a project management tool, you need clear boundaries on what it can actually do — and what it definitely cannot.

Every Cowork connector uses OAuth 2.0 for authorisation. Anthropic does not store credentials. When a user connects Salesforce, they authenticate directly with Salesforce, and an access token is issued to Cowork for the scopes the user approves. Anthropic's systems hold the token, not the credentials.

The key security configuration for connectors is scope restriction. By default, most connectors request broad read permissions. For enterprise deployments, you should work with your admin console to enforce minimum-necessary scopes. For example:

• Gmail: Restrict to read-only if your use case doesn't require drafting or sending
• Google Drive: Limit to specific shared drives rather than full Drive access
• Slack: Grant access to specific channels, not workspace-wide message history
• SharePoint: Scope to specific site collections relevant to the team's work

Connector revocation is user-initiated by default, but Workspace Admins can force-revoke any user's connector connections from the admin console. This is essential for offboarding — when an employee leaves, their Cowork connector authorisations need to be revoked as part of the standard departure process. We recommend integrating this into your SCIM provisioning workflow.

Data Handling and Model Training Policies

The question every enterprise legal and privacy team asks: does Anthropic use conversation data from Cowork to train Claude? The answer depends on your plan tier.

On Claude Enterprise plans, conversation data — including inputs, outputs, and file contents processed through Cowork — is not used to train Claude models. This is a contractual commitment in the Enterprise agreement, not just a product toggle. Your DPA (Data Processing Agreement) with Anthropic governs how data is handled, retained, and processed.

On Pro and Max consumer plans, default settings may include data use for model improvement, though users can opt out. If your organisation is deploying Cowork at scale, you should be on an Enterprise plan — and the absence of an Enterprise agreement is itself a compliance risk that should be flagged.

Data retention is configurable. By default, conversation history is retained to support the workspace memory and context features of Cowork. Admins can configure retention policies from the admin console, including automatic deletion timelines. For regulated industries — financial services, healthcare, legal — align your Cowork retention policy with your broader data classification framework. Our Claude security and governance service includes a full data classification mapping exercise as part of the deployment engagement.

Data residency is available for Enterprise accounts. Anthropic offers US and EU data residency for conversation processing and storage, which matters significantly for GDPR compliance and data sovereignty requirements. This requires explicit configuration at the Enterprise agreement stage — it's not a self-serve toggle.

Plugin Security and Sandboxing

Plugins extend Cowork's capabilities significantly — connecting to internal APIs, running automations, executing custom workflows. They also introduce the most complex security surface in a Cowork deployment. Claude Cowork plugins run with the permissions granted at install time, and those permissions persist until explicitly revoked.

Anthropic operates a plugin marketplace with reviewed and approved plugins. For enterprise deployments, admins can restrict Cowork to marketplace-approved plugins only — blocking any privately-sourced plugin that hasn't been reviewed. This is the recommended configuration for regulated environments.

Custom plugins built by your internal development team require a different governance posture. Each custom plugin should go through a security review that examines the OAuth scopes it requests, the external APIs it calls, what data it reads and writes, and whether it has access to any persistent storage. Our MCP server development service builds plugins with security-by-default architecture — minimal scopes, no unnecessary data persistence, full audit logging.

Plugin sandboxing in Cowork means that plugins cannot directly access each other's data or outputs without explicit user action. A plugin connecting to your ERP system cannot read from a plugin connected to HR — the data isolation is enforced at the platform level. However, a user can manually pass output from one plugin as input to another, which is by design. The governance question is whether users should be permitted to do this for certain data categories — and that's a policy decision your admin team needs to make explicit.

Audit Logging and Compliance Monitoring

Audit logging in Claude Cowork captures a detailed record of every agent action: which user initiated the session, what connectors were called, what files were read, what outputs were produced, and what external actions were taken (emails drafted, documents created, CRM records updated). This log is available to Workspace Admins through the admin console.

The audit log structure for Cowork includes the following fields by default:

• Timestamp — UTC timestamp of each action
• User ID — the authenticated user who initiated the session
• Session ID — groups all actions within a single Cowork conversation
• Connector name — which connector was called (e.g., Gmail, SharePoint)
• Action type — read, write, create, send, delete
• Resource identifier — the specific file, email, record, or document affected
• Plugin name — if a plugin was involved
• Output summary — a summary of what was produced (not the full content)

For SOC 2 and ISO 27001 compliance programmes, these logs need to be exported to your SIEM. Cowork supports log export via webhook or API, and you can configure real-time forwarding to Splunk, Datadog, or your preferred security monitoring platform. This integration is not available out of the box — it requires configuration during deployment, which is one of the tasks we handle in our enterprise implementation engagements.

Anomaly detection on Cowork audit logs is still largely manual or requires custom SIEM rules. Watch for: high-volume connector calls from a single user in a short time window, access to connector scopes a user doesn't normally use, and bulk file reads from shared document repositories. These patterns may indicate either a misconfigured automation or a security incident that warrants investigation.

Enterprise Admin Console Controls

The Cowork admin console gives Workspace Admins control over the full deployment at scale. The key settings every enterprise admin should configure before a broad rollout:

Connector approval policy: Set to "Admin approval required" rather than "User self-service" for regulated environments. This means no user can connect a new third-party service without IT review. It adds friction, but it prevents shadow IT connector sprawl.

Plugin policy: Restrict to "Marketplace only" unless you have a formal internal plugin review process. Block specific plugins by name if you've identified ones that conflict with your data policies.

Memory and context policy: Cowork's workspace memory feature retains context across sessions. This is useful for productivity but creates a persistent data store that needs governance. Configure memory retention to align with your data classification policy. For high-sensitivity teams (legal, M&A, executive), consider disabling persistent memory entirely.

External sharing policy: Cowork can draft and send communications on behalf of users (emails, Slack messages, documents). Enable the "Require user confirmation before external send" setting for all deployments. Never let the agent send externally without user approval — particularly in financial services and legal contexts where outbound communications are regulated.

SSO and provisioning: Configure SAML SSO for Cowork through your existing IdP (Okta, Azure AD, Ping). Enable SCIM provisioning for automated user lifecycle management. This ensures that when accounts are deprovisioned in your IdP, Cowork access is revoked within the standard provisioning sync window.

DLP Integration and Sensitive Data Controls

Claude Cowork does not natively integrate with DLP (Data Loss Prevention) tools in the way that, say, a Cloud Access Security Broker might. But there are several points in the Cowork architecture where DLP controls can be applied effectively.

First, connector scope restriction is itself a form of DLP. If your Google Drive connector only grants access to a specific shared drive — not personal drives — then sensitive documents in personal storage can never reach Claude's context window. Scope restriction at the connector level is the most effective data containment strategy available before content-level DLP.

Second, for outbound communications (email drafts, Slack messages), implement an approval workflow. The "Require user confirmation before external send" admin setting is a manual DLP checkpoint. For higher-sensitivity environments, consider whether you need to integrate an automated DLP scanner before anything drafted by Cowork is actually sent — this requires custom integration work, but it's achievable through the connector API.

Third, Anthropic's Enterprise terms include confidentiality commitments for your input data. Your conversations with Cowork are not visible to other customers and are not accessible to Anthropic employees for product improvement without consent. This is standard enterprise SaaS data isolation, but it's worth confirming explicitly in your DPA review rather than assuming.

If you're deploying Cowork in a regulated industry and have existing Microsoft Purview or Symantec DLP infrastructure, book a strategy call with us. We've worked through the integration architecture for financial services and legal deployments where DLP requirements are non-negotiable.

Special Considerations for Regulated Industries

Claude Cowork's security controls are broadly adequate for standard enterprise deployments. Regulated industries — financial services, healthcare, legal, government — have additional requirements that need specific treatment.

For financial services: Communications surveillance is mandatory under MiFID II, SEC Rule 17a-4, and similar regimes. Any AI-assisted communications — emails drafted by Cowork, Slack messages sent through Cowork — need to be captured in your communications archive. Ensure your archiving solution covers Cowork-assisted outputs, not just directly authored messages. See our guide on Claude Cowork for finance teams for the full compliance architecture.

For healthcare: PHI (Protected Health Information) should not flow through Cowork connectors unless you have a signed BAA (Business Associate Agreement) with Anthropic and have explicitly scoped the connector access to systems containing PHI. Anthropic offers BAAs for Enterprise customers — confirm this before connecting any healthcare system connector.

For legal teams: Attorney-client privilege and work product doctrine require careful treatment of AI-generated content. Cowork outputs that inform legal strategy should be clearly labelled as AI-assisted in your document management system. Configure Cowork's workspace memory to prevent cross-matter context bleed — a matter wall policy at the Cowork team level is essential. Our Claude Cowork for legal teams guide covers this in detail.

For government and public sector: FedRAMP authorisation for Claude is in progress as of early 2026. Until FedRAMP authorisation is confirmed, government agencies should review their ATO (Authority to Operate) requirements before deploying Cowork for official use. Our team can assist with the NIST 800-53 controls mapping for Cowork deployments.

Related Articles