Team and enterprise notes

Friday, 4:40 p.m. Finance asks for a cleaned vendor folder and a one-page status deck before Monday. You already know Cowork can do most of that: dedicated working folder, clear outcome, watch the first write pass, then walk away for the boring rename work (Parts 1 through 6 of this series). You open Claude on your personal Pro plan, connect a shared drive path you “sort of have access to,” enable a connector because the demo looked friendly, and ship something that looks finished. Monday morning, Security asks three questions you cannot answer: who approved the connector, where the session logs live, and whether company data left the laptop into a product the org has never put under a data processing agreement. Same model that helped you last week. Different blast radius. The model did not invent the risk. The plan tier and the missing admin rails did.

This is Part 7 of the Claude Cowork tutorial, and it closes the series. Parts 1 through 6 covered chooser logic (chat vs Cowork vs Code), first real file tasks, folders and sheets, plugins and connectors, watch vs walk-away autonomy, and quality control against “workslop.” This part is the multiplayer and org layer: Team and Enterprise admin controls, feature flags, spend and role access, observability (OpenTelemetry first; Compliance API coverage that you must re-check in official docs), why personal Pro is not a policy waiver, and why IT belongs in the room before connectors and computer use go wide. Product names and admin screens move. Treat this as a field guide, not a frozen policy PDF. Re-check Anthropic’s Team/Enterprise and Cowork admin docs the week you write real controls.

What Team and Enterprise add that personal plans

What Team and Enterprise add that personal plans do not (admin, flags, spend, roles)
How monitoring fits Cowork today: OpenTelemetry to your SIEM, and why Compliance API coverage needs a doc check
Why a personal Pro (or Max) subscription is not company policy approval
When to stop and talk to IT before connectors, network egress, and computer-use style power
Why write-capable tools often need admin consent and per-task approval defaults
How this Cowork series fits the wider Claude path on AMS, and what to read next

Personal Pro is not a policy waiver

Cowork is available on paid plans, including personal Pro and Max, and on Team and Enterprise. That availability is a product fact. It is not the same thing as “your company said this is fine for customer files, payroll exports, or the shared legal drive.” Product can ship a feature on a credit card. Policy is about data class, retention, logging, connectors, and who can approve risk. Those live with your employer, not with the upgrade button.

People blur the two because the UI looks the same and the output looks professional. A personal plan can feel faster: no owner toggle, no group roles, no spend report, no wait for Security. That speed is real. So is the gap. On personal plans you typically lack organization-level admin controls: no central enable/disable for Cowork, no org spend caps, no role-based connector grants, no shared plugin marketplace policy. If something goes wrong, there is no org admin console to open. There is only your account and whatever your laptop stored.

A useful sentence for the next all-hands: Paid access proves you can log in. It does not prove Legal and Security signed off on this data path. If your org already has an approved Claude Team or Enterprise tenant, use that for work. If it does not, do not invent a shadow AI stack with personal subscriptions and shared folders. Escalate. The boring path is the professional one.

What Team and Enterprise actually add

Think of Team and Enterprise as the layer where Cowork stops being only an individual productivity tool and becomes something an organization can turn, shape, and observe. Exact menus change. The job of the layer does not.

Light map of Team and Enterprise notes: admin feature flags and spend, policy for data and tools, observability via OpenTelemetry to SIEM…

Admin controls and feature flags

Owners on Team and Enterprise can treat Cowork as an org capability, not only a user hobby. In practice that includes toggles such as enabling or disabling Cowork for the organization, and separate controls for whether sessions may run in Anthropic’s cloud versus local desktop sessions. Cloud vs local matters: cloud can keep work going when the laptop sleeps; local keeps conversation history on the machine in ways admins may not centrally export. Defaults also differ by plan (for example, cloud sessions may be on by default on Team and off by default on Enterprise until an owner turns them on and grants capabilities). Read the current “Use Claude Cowork on Team and Enterprise plans” article before you freeze a rollout plan.

Enterprise goes further with groups and custom roles so Cowork (or cloud Cowork) can land with specific teams instead of all-or-nothing. Team plans are often coarser: if Cowork is on, it is on for members under that org toggle. Plugins and marketplaces give owners another lever: installed by default, available, required, or not available. That is how you stop every person from inventing a different plugin stack for the same finance close process.

Spend and seat reality

Agentic office work is not free chat. Multi-step tasks, large folders, and long sessions burn usage. Team and Enterprise give admins a place to buy and assign seats, watch usage analytics, and set spend limits so one enthusiastic week of deck generation does not become a surprise invoice. Group spend limits on Enterprise are the practical answer when marketing and engineering need different ceilings. If nobody owns spend, Cowork will still run. Finance will only notice later.

Role access and least privilege

Role access is the difference between “everyone gets every connector” and “ops can use the approved ticketing plugin; interns cannot write to the production CRM.” Enterprise custom roles and connector permissions let admins decide which connectors (and sometimes which tools on a connector) a role may use. Combined with network egress settings under organization capabilities, you get a least-privilege story that matches how you already treat SaaS. If your company would never give every employee full export rights on the warehouse, do not give every employee unrestricted Cowork connectors by accident.

Control area	Why it matters for Cowork	Who usually owns it
Org enable / disable	Stop or start the surface entirely	Owner / Primary Owner
Cloud vs local sessions	Where work runs and where history lives	Owner + Security
Roles / groups (Enterprise)	Who gets Cowork and which tools	IT / IdP admins
Spend limits	Predictable cost under agent load	Finance + Owner
Plugins marketplace	Curate, require, or hide plugins	Owner + team leads
Connectors / write approvals	Limit blast radius of tools that change systems	Security + Owner
Network egress / web search	What the agent can reach on the internet	Security / Network
Monitoring (OTel)	Visibility into sessions and tool use	SecOps / Platform

Observability: OpenTelemetry first, Compliance API with eyes open

If Security asks “how do we see what Cowork did?”, do not answer with a shrug and a screenshot. On Team and Enterprise, Anthropic documents OpenTelemetry (OTel) export for Cowork activity. Owners configure an OTLP endpoint (and protocol/headers as needed) so events can stream into the collector and SIEM you already run. That path is the current operational visibility tool for tool calls, file-related activity, approval decisions, and related session signals. Setup details live in “Monitor Claude Cowork activity with OpenTelemetry” and the Cowork monitoring docs. Desktop version minimums apply; re-check before you file a ticket with IT.

The Compliance API is a separate Enterprise governance surface for programmatic access to usage and content-style data for auditing. Here you must hedge on purpose: official Cowork Team/Enterprise guidance has stated that Cowork activity is not captured in the Compliance API the same way other Claude activity is, while other docs describe remote (web/mobile) session content paths that may appear in Compliance API surfaces. Local desktop session history can live on the user’s machine in ways admins cannot centrally manage or export like normal org retention. Do not write policy from this blog post alone. Open the current Anthropic admin articles the week you design controls, note what is in OTel, what is in Compliance API, and what is local-only, then design compensating controls (SIEM alerts, MDM, folder policy, connector allowlists) for the gaps.

A practical split that most orgs can defend in a review:

OTel → SIEM: near-term visibility for Cowork operations (who ran what kinds of tools, approvals, errors, cost-ish usage signals depending on event set)
Compliance API: formal audit integrations where the product supports them; verify Cowork coverage explicitly
Human process: data-class rules, working-folder standards, and “no personal Pro for company confidential” even when telemetry is perfect

Telemetry without policy is a camera pointed at an unlocked door. Policy without telemetry is a locked door with no way to know who used the key. You want both, imperfect is fine, silent is not.

Talk to IT before connectors and computer use

Part 4 of this series treated plugins and connectors as power tools for office work. That still holds. The enterprise note is timing. Connectors that read mail, write tickets, touch drives, or call internal APIs change the threat model from “Claude helped me rename PDFs in a sandbox folder” to “Claude can act inside systems that already have production data.” Computer-use style capabilities (browser or desktop control patterns, depending on what your plan and admin settings allow) raise the same flag: the agent is no longer only editing files you pointed at. It can navigate environments humans treat as high trust.

Bring IT (and Security, and sometimes Legal) in before the first wide connector rollout, not after the first odd OAuth grant. A short preflight list:

Data classes: which folders and systems are allowed, which are forbidden (HR, regulated, customer secrets, M&A).
Identity: SSO/SCIM membership so leavers lose Cowork with the rest of SaaS.
Network egress: allowlists and whether web search / Chrome-style tools are on for the org.
Connector inventory: approved list, owner, and revoke path. Prefer org marketplace plugins over random personal installs.
Write policy: default deny or per-task approval for write tools until trust is earned.
Monitoring: OTel endpoint owned by SecOps, not a forgotten URL in a slide.
Incident path: who kills Cowork org-wide, who rotates keys, who tells Legal if a prompt-injection scare shows up.

If IT says “not yet,” the answer is not “fine, I’ll use personal Pro on the same data.” The answer is a smaller pilot: synthetic data, a clean working folder, no connectors, human-watched sessions, then expand. That is the same spirit as Part 5’s watch-before-walk autonomy, applied to the org.

Read tools are not free of risk (exfiltration is still a thing), but write tools fail louder. Tickets created wrong, sheets overwritten, CRM fields “cleaned,” calendar invites sent to the wrong list: those are production incidents dressed as productivity.

On Team and Enterprise, organization settings for Cowork include permission controls such as whether members may use “Always allow” for write-capable connector tools. Official guidance has described that setting as off by default: members approve write-capable tools per task, and saved always-allow preferences are not honored until an owner turns the setting on. Enterprise layering can make the most restrictive layer win, so a role grant cannot quietly defeat an org-wide lock. Exact labels move; the principle does not: write power should be opt-in at the admin layer, then careful at the user layer.

Translate that for non-admins:

If the approval dialog keeps asking you about a write tool, that is a feature, not a bug.
Do not beg for “Always allow” on day one of a connector pilot.
If you need always-allow for a well-scoped internal plugin, make it a ticket with a data class, a rollback plan, and an owner, not a Slack emoji.
Custom connectors that fail to mark tools read-only will often be treated as gated; plan for friction.

Code block below is a paste-friendly starter for an internal “Cowork write tools” runbook. It is process, not product config. Adapt names to your tools.

## Cowork write-tool runbook (starter)
Allowed data classes for pilot: [list]
Forbidden: HR, customer secrets, prod credentials, M&A

Connectors approved: [names + owner + revoke ticket]
Write tools default: per-task human approval
"Always allow" for write tools: OFF unless Owner ticket #____

Before first write in a session:
1. Confirm working folder / project is the pilot sandbox
2. Confirm task text names the systems to touch
3. Approve only the tool you intended
4. Spot-check the first write result before more autonomy

If something looks wrong:
- Stop the task
- Disconnect the folder / revoke connector if needed
- Notify: [Security on-call] + [Cowork owner]
- Preserve what you can for OTel / local notes
- Do not "fix forward" with more agent steps

A light rollout order that does not fight reality

Orgs that skip steps tend to bounce between ban and free-for-all. A boring sequence works better.

Phase	What you allow	What you require
0. Policy stub	Nothing production	One page: data classes, personal plans out of band, who owns Claude org
1. Desktop pilot	Local Cowork, sandbox folders only	Named pilot users, watched first sessions, no connectors
2. Visibility	Same pilot	OTel to SIEM, someone reading alerts weekly
3. Read connectors	Approved read-mostly tools	Allowlist, owner, revoke drill
4. Write connectors	Narrow write tools	Per-task approval, runbook, incident contact
5. Cloud / mobile (if used)	Only after data path review	Enterprise role grants if available; re-check Compliance API coverage
6. Scale	More seats / groups	Spend limits, plugin marketplace, training that includes Part 6 quality checks

Notice what is missing from phase 0: a six-month AI transformation program. One page of truth beats a 40-page strategy that nobody updates after the kickoff. You can expand the page later. You cannot recover trust after a careless connector week.

How this fits the rest of the Claude path on AMS

If you have been following Analytics Made Simple through the Claude block, the intended order is deliberate:

Series close path: Learn Claude, product map, Code tutorial, Cowork tutorial, then next other AI products

Learn Claude from scratch: everyday chat, plans, Projects, privacy, when not to use the tool
Claude product map: chat vs Code vs Cowork vs API-style surfaces so you pick the right job
Claude Code tutorial: deep coding-agent track for repos, diffs, skills, and team rails
Claude Cowork tutorial (this series): deep office-agent track for files, folders, plugins, autonomy, quality, and now org notes

Cowork is not “Code but easier.” Code owns software change with terminal and PR culture. Cowork owns multi-step office outcomes without pretending you are a developer. Chat still owns quick answers and drafts you paste yourself. The product map series is the chooser; these tutorials are the depth. The Learn series is the everyday floor under all of it. If someone only reads this Part 7 without Parts 1 through 6, they will over-index on admin toggles and under-index on working folders, autonomy judgment, and workslop checks. Send them back to the series start from the Learn hub.

What this Cowork series covered

Part	Focus
1	Cowork vs chat vs Claude Code (pick the surface)
2	Setup and first real file task
3	Working on folders, docs, and spreadsheets
4	Plugins and connectors for office work
5	Autonomy: when to watch vs walk away
6	Quality control and avoiding workslop
7	Team and enterprise notes (this post)

If you keep one idea from seven parts: Cowork multiplies whatever process you already have. Clear goals, sandbox folders, watched first writes, and verify-before-share habits scale. Fuzzy goals, personal Pro on company secrets, and always-allow on write connectors scale too, just in the wrong direction.

What comes next on AMS (notes)

This post closes the Claude Cowork tutorial and, with Learn Claude, the product map, and the Code tutorial, completes the deep Claude track we planned for Phase K on the content calendar. Two natural next paths (they can even run in parallel depending on what you need):

Phase P meta on-ramps: chooser guides, setup safety, and cross-tool habits that are not brand-specific (when you need orientation more than another product deep dive)
ChatGPT track: Learn ChatGPT, product map, and later Work/Codex-style depth for readers who live in OpenAI’s stack the way this track lived in Claude’s

Gemini and Grok tracks follow later in the same “from scratch, then map, then deep surfaces” pattern. Cloud and lakehouse platforms are separate phases. None of that replaces the verification culture in Practical AI or the SQL check habit in How to check AI-written SQL before you ship it. Tools change names. Fluent wrong answers do not.

Treating personal Pro as “the company already uses

Treating personal Pro as “the company already uses Claude.” Different tenant, different contract, different logs.
Enabling every connector on day one. Start with folders and read-only; earn write access.
Assuming Compliance API equals full Cowork history. Re-check docs; wire OTel; plan for local-only gaps.
No spend owner. Agent sessions will find the budget ceiling for you, usually at month end.
Admin toggles without user training. People will invent shadow workflows if the official path feels blocked and unexplained.
User training without admin toggles. Cheerleading plus open write tools is how demos become incidents.
Skipping IT because “it’s just documents.” Documents are data. Connectors are integrations. Computer use is control.
Copying Code team rails one-for-one into Cowork. PR/CI still matter for software. Office agents need folder policy, connector allowlists, and quality checks (Parts 3 and 6).
Never re-reading vendor admin docs. Cowork cloud beta, OTel events, and Compliance coverage can change faster than your wiki.

Practice: 45 minutes with an admin (or a stand-in checklist)

If you are not an owner, still run the exercise with whoever can open Organization settings, or mark each item “unknown, ticket needed.”

Confirm whether work uses Team/Enterprise or personal plans. Write the answer down. If mixed, that is already a finding.
Locate the Cowork enable toggle and the cloud-sessions control. Note current on/off state.
Check write-tool “Always allow” (or equivalent) policy. Prefer off for pilots.
Ask SecOps whether an OTel collector endpoint is configured for Cowork and which dashboard shows events.
List connectors currently visible to a normal user. Mark each approved / unknown / remove.
Draft five forbidden data examples and five allowed pilot tasks. Share with one team lead.
Schedule a 15-minute monthly “admin truth check” so toggles and docs do not rot.

Team/Enterprise add admin controls, feature flags, spend limits

Team/Enterprise add admin controls, feature flags, spend limits, and role-shaped access that personal plans lack.
Personal Pro (or Max) is not company policy approval. Use the org tenant for work data.
Monitor Cowork with OpenTelemetry into your SIEM; re-check Compliance API coverage in official docs instead of assuming parity with chat.
Involve IT before connectors and computer-use power leave the sandbox.
Write-capable tools often need admin consent and per-task approval; treat always-allow as a later privilege.
Roll out in phases: policy stub, sandbox pilot, OTel, read tools, write tools, then scale.
Claude path on AMS: Learn → product map → Code tutorial → Cowork tutorial (complete).
Next up: Phase P meta on-ramps and/or the ChatGPT track, with Practical AI verify habits kept nearby.

Close the series the way you close a good pilot: controls written down, owners named, first success measured on boring tasks, and no silent personal-plan workaround on the side.

Sources

Official and related reading for Team/Enterprise Cowork controls, monitoring, and AMS paths. Product UIs change; prefer the live docs over any secondary summary.

Claude Help Center: Use Claude Cowork on Team and Enterprise plans (admin toggles, cloud vs local, connectors, plugins, monitoring notes)
Claude Help Center: Monitor Claude Cowork activity with OpenTelemetry (OTel setup for Team/Enterprise Cowork)
Claude Docs: Cowork monitoring (OTLP fields and monitoring overview)
Claude Help Center: Get started with Claude Cowork (availability, safety pointers, monitoring caveats)
Claude Help Center: Use Claude Cowork safely (prompt injection and safer operating habits)
Anthropic: Claude Code and new admin controls for business plans (Team/Enterprise admin, spend, Compliance API introduction context)
Anthropic: Making Claude Cowork ready for enterprise (enterprise framing for roles, spend, OpenTelemetry)
OpenTelemetry (vendor-neutral telemetry standard used by the OTel export path)
Analytics Made Simple: Claude Cowork tutorial (this series)
Analytics Made Simple: Claude Code tutorial (coding-agent deep track and team rails)
Analytics Made Simple: Claude product map (chat vs Code vs Cowork orientation)
Analytics Made Simple: Learn Claude from scratch (everyday Claude foundation)
Analytics Made Simple: Learn (series index on this site)
Analytics Made Simple: Practical AI (vendor-neutral judgment and verification habits)
Analytics Made Simple: How to check AI-written SQL before you ship it (verify habit for fluent wrong outputs)