Claude Enterprise

Claude Enterprise is Anthropic's plan for an organisation rather than a person. What you buy is a tenancy : one administered space in which every member signs in with the company identity, meets the same Claude in every tool, and leaves behind a record you can audit. Since the unified experience reached general availability for Enterprise on 23 October 2026, a conversation that begins as ordinary chat can carry on in Cowork , an isolated cloud sandbox that opens files, runs code and comes back with results, and then return to chat without the user changing window. The seat also opens Claude Code for engineers, Claude Design, Docs and Slides, Claude for Microsoft 365, Claude in Chrome, Claude in Slack and Claude Security, together with Projects, Artifacts, memory, Skills, plugins and connectors.

What changed between 2024 and now is less the model than the shape. The first Enterprise was a very good chat window with corporate identity attached. The 2026 product is an agentic workspace. Cowork appeared as a research preview in January 2026, reached enterprise release with connectors and plugins in February, and became generally available on 9 April with an Analytics API and OpenTelemetry support. The admin side grew in step: custom roles that decide which connectors, and even which connector tools, a role may use (28 May 2026); spend limits by organisation, group and member; pooled group budgets announced on 23 October 2026; a Compliance API that feeds your SIEM.

The popular myth is that an enterprise plan is the consumer product with a logo on it. It is not. The consumer product has no Compliance API, no SCIM, no retention you choose, no customer-managed keys, and no way to restrict what a sandbox may reach. The plan is the admin plane plus the models.

A seat on Claude Enterprise is one identity, not one application. The same person, signed in once through your identity provider, opens Claude in the browser at claude.ai, in the desktop app on macOS or Windows, on an iPhone or an Android phone, inside Excel, PowerPoint, Word and Outlook through Claude for Microsoft 365 , in a Chrome side panel, in a Slack thread and, for engineers, in the terminal, the IDE or the web through Claude Code. Behind each door stand the same models, the same memory and Projects, and the same organisation policy. Anthropic's plan page lists the surfaces a seat includes; the admin guides on support.claude.com say how each is enabled, and the release notes date them: Claude for Excel entered beta on 24 November 2025, Claude in Chrome gained site allowlists and blocklists on 18 December 2025, and tagging Claude in Slack to delegate a task arrived on 23 June 2026.

More doors mean more places to configure. Claude in Chrome can browse and act on websites, so it carries its own allowlist. The Microsoft 365 connector's write tools, which let Claude send mail or edit files, need consent in Microsoft Entra and explicit admin enablement (7 July 2026), as does any connector that can act rather than merely read. The desktop app accepts MDM policy keys, so a device team can forbid local MCP servers or limit which folders Claude may open. None of this is difficult; all of it is a decision somebody must make.

The myth to correct is that each surface is a separate product with its own data rules. It is one tenancy, one set of commercial terms, one retention setting, one audit log, and inputs and outputs are not used to train models by default on any of them.

There are three ways into Claude, and the honest answer is that most organisations of any size end up with two of them. Team is the self-serve plan for small groups, roughly two to 150 people; it includes single sign-on and, since 16 January 2026, Claude Code on standard seats, but at the time of writing it does not include SCIM provisioning, audit logs or fine-grained roles. Enterprise is the governed tenancy this book is about: identity, compliance evidence, retention you choose, customer-managed keys, model and spend controls. The Claude Platform is the API, for software you build yourself, reached directly from Anthropic or through Amazon Bedrock, Microsoft Foundry and Google Cloud's Vertex AI, with zero data retention available by agreement.

Choose by need, not size. Ask three questions. Who may join and who must leave, automatically? If the answer involves your HR system, you need SCIM, which means Enterprise. Who will ask us for evidence? If a regulator, an auditor, a client's security questionnaire or a works council will one day ask what was done with the tool, you need audit logs and the Compliance API. Are we building a product? If Claude will sit inside something your customers use, that is the Platform, with your own logging, your own keys and your own evals, which the sister volume Agents in Production covers.

The myth is that Enterprise is for big companies. It is for organisations with obligations. A 60-person law firm bound by professional secrecy may need Enterprise more than a 600-person start-up that handles no personal data. In the European Union, a public body that must document a data protection impact assessment will want the audit trail from day one; in the United Kingdom the same logic follows the ICO's guidance; in the United States it is more often a client contract that forces the question.

A seat does not give you a model; it gives you a family of them, and a set of dials. In late October 2026 the family is Opus 5.5 , Sonnet 5.5 and Haiku 5.5 , the 5.5 generation that arrived on 7 October 2026, alongside Fable 5.1 and a Mythos-class tier with restricted access. The dials are effort (how long the model is allowed to think before answering), the per-role entitlements that say which models a member may pick, and Efficient mode, which restricts the unified experience to Sonnet and Haiku and starts every new session on Sonnet 5.5 at low effort. How we know: the model pages on docs.claude.com, and the release notes for model and effort controls for members (beta, 1 July 2026) and for model defaults and entitlements by role (2 July 2026).

Three illustrative settings. A Madrid insurer pins its claims-triage group to Haiku, because the job is sorting, not writing. A Dublin law firm entitles its lawyers to Opus for opinions and Sonnet for correspondence, and measures which they actually use. A Kraków city office turns on Efficient mode for 1,200 administrative staff and leaves the higher dials to a dozen analysts. Each of these is a role setting, made once by an admin, not a preference each person rediscovers.

The evidence that matters is your own. Run a real task through two models, time it, and have colleagues rank the outputs without knowing which is which. A pilot measurement of that kind is worth more than any public leaderboard, and it is what the Evals in a Nutshell volume is for.

An enterprise buyer cannot inspect a model's weights, but can read what its maker has committed to in public, and that reading is worth an afternoon. There are four layers. The Responsible Scaling Policy , first published in September 2023 and revised since, is Anthropic's framework for catastrophic risk: it defines AI Safety Levels and commits the company to safeguards before training or deploying models past stated capability thresholds. Claude's constitution , published in January 2026 and running to around 23,000 words, describes how Claude is meant to think, behave and weigh competing goals. The usage policy and commercial terms govern your tenancy, including the commitment that inputs and outputs are not used to train models by default. The Trust Center at trust.anthropic.com holds the evidence: SOC 2 Type II, ISO 27001, and certification against ISO/IEC 42001, the AI management…

That last distinction is where buyers trip. A SOC 2 report says the provider's controls operated as described over a period; it says nothing about whether your claims team should paste medical notes into a chat. ISO/IEC 42001 says the provider runs an AI management system with objectives, risk assessment and review; it does not run yours. The NIST AI Risk Management Framework (January 2023, with a Generative AI Profile in July 2024) makes the same point from the other side: the Govern and Map functions are the deployer's work.

In the risk register, write each commitment as a control with five fields: the control, the source URL, the date you checked it, the owner and the next review. That is a dull sentence, and dull is what an auditor likes.

The commercial shape of Claude Enterprise has two parts, and understanding both is more useful than knowing either price, which this book will not quote. The first part is the seat : a flat fee per person on an annual commitment, with a minimum number of seats stated on the pricing page. The second is usage : the tokens those people consume, billed at API rates, over and above the seat. You can buy sales-assisted, with an invoice and net terms, or, since 12 February 2026, self-serve online with a single seat type; you can also buy through AWS Marketplace and draw the cost down against an existing AWS commitment. How we know: the pricing and enterprise pages on claude.com and the self-serve release note; the shift from bundled to unbundled usage, reported in the trade press across late 2025 and early 2026, is best treated as context rather than quoted precisely.

Forecasting is a pilot exercise, not a spreadsheet guess. Run thirty days with a real group, export usage by user, and look at the distribution. A Birmingham council that pilots with 40 people in revenues and benefits will see a few heavy users and a long tail, and can budget the year from that shape. A Munich manufacturer will find that its works council takes an interest in per-user spend data, because a report that ranks employees by consumption is, under the Works Constitution Act, a technical system capable of monitoring performance, and needs agreement before it is used that way. A US software firm buying through AWS Marketplace cares mostly that the drawdown counts towards its commit.

The seat is a cost you forecast; usage is a behaviour you manage.

Every rollout meets the same five myths in its first month, usually from intelligent people, and each has a dated answer. Myth one: it trains on our data . On Claude Enterprise, inputs and outputs are not used to train models by default; the commitment is in the commercial terms and documented on the Trust Center at trust.anthropic.com. How we know is the contract you signed, which is the best kind of knowing. The sensible follow-up is retention: you can set a custom period, with a minimum of thirty days, and you can ask about customer-managed keys and US-only inference if your regulator cares where the maths happens.

Myth three: one licence per person is the whole cost . The seat is a flat fee, usage is billed on top at API rates, and the real cost includes an admin's time, a champion's time and training. The EU AI Act's article 4 has expected deployers to ensure AI literacy among staff since 2 February 2025; that is a cost, and a worthwhile one, in every member state, and a good idea in Leeds or Lyon regardless.

Myth five: the AI team owns it . An AI lead can run the use-case inventory and the champions network, but the Primary Owner sits in IT, the audit logs belong to security, the DPIA belongs to the data protection officer, the budget belongs to finance and, in Germany, the works council has a legal seat at the table. The next two chapters are about that cast. Myths survive because nobody dates them; the moment you write "checked 29 October 2026, source: admin guide" beside a claim, it becomes a fact with a shelf life.

The most expensive sentence in enterprise software is "let's switch it on and see what people do with it". It sounds open-minded; it is actually a decision not to decide, and it guarantees that six months later nobody can say whether the thing worked. The alternative fits on one page, and this chapter is about writing it. Call it the intent statement : three to five measurable goals, the non-goals, the risk appetite, the baseline measures, and a signature from an executive sponsor who will still be in post at the review.

Goals should be outcomes, not features. "Deploy Claude to 2,000 staff" is a feature. "Cut the median time to draft a claims letter from forty minutes to fifteen" is an outcome; so are "reduce the backlog of policy queries by 30 per cent", "no increase in error rates found at quality review" and "staff report less drudgery in the quarterly survey". Pick measures you already collect, or can collect in the pilot's first two weeks; a baseline measured after the tool arrives is not a baseline.

Risk appetite goes on the page in plain words, by category: low for anything that leaves the building under the organisation's name, medium for internal drafting, and a named person who can raise it. Then the signature. A sponsor who signs a page will turn up to the thirty-day review; a sponsor who approved a budget line will send a delegate.

No setting in the admin console matters as much as the ten names on this page. Claude Enterprise is governed by people before it is governed by policy, and the first job of whoever is reading this is to fill in the roster. At the top sits the executive sponsor , who owns the intent statement from the previous chapter and turns up to the reviews. Beneath the sponsor are four pillars, and each pillar has a small cast.

The second pillar is the brakes. The security lead owns the audit logs, the Compliance API feed into the SIEM and the periodic settings review. The data protection officer, mandatory under the GDPR for most public bodies and many private ones, owns the data protection impact assessment and the retention decision. In Germany the works council is not a courtesy invitation: under section 87 of the Works Constitution Act, a technical system capable of monitoring employee conduct or performance needs its agreement, and usage analytics by user is exactly such a system. In the UK and the US there is no equivalent legal seat, but staff representatives consulted early turn into champions, and those consulted late turn into the grievance.

Who decides what is the sentence worth writing on the wall: the sponsor decides why, the Primary Owner decides who, security and privacy decide what may be done, finance decides how much, and the AI lead decides what to try first. How we know this cast works is the evidence of every rollout that failed without one: a pilot owned by an enthusiast with no sponsor, a rollout blocked at month four by a works council nobody had met, a renewal nobody had budgeted.

The first month should be boring, and boring takes planning. Anthropic's own rollout guidance for the unified experience is a reasonable skeleton: involve IT, security and procurement; do a security review; pilot with one role; review the settings; monitor for two to four weeks; expand in waves. Here is that skeleton with dates on it, written for the admin who has to do it on Monday.

Week two is the pilot group. One SCIM group, one role, twenty to fifty people who share a job, so that the measurement means something: revenues and benefits in a council, claims handling in an insurer, a research group in a university. Defaults are conservative because changing them later is cheap and undoing them is not: the unified experience stays off until security has read the sandbox guide, network egress for cloud sessions stays off, memory is already off by default for Enterprise organisations since 25 August 2026, and connectors sit at "needs approval". Model entitlements are set for the role, and Efficient mode is a fair starting point for most non-technical groups.

What not to do yet is as important as the plan. Do not open network egress to all domains. Do not approve every connector or install every plugin from the marketplace. Do not turn on "skip all approvals" for anyone. Do not share cloud sessions across the whole organisation. Every one of those is a legitimate setting for month three, once you know what the pilot actually did. A German organisation also uses this month to brief the works council before usage analytics by user is ever looked at; a UK or US organisation uses it to tell staff, in writing, what the tool is for and what it is not.

A business case for Claude Enterprise is not a brochure for the board; it is a short record of a decision you want someone to make, written so that it can be checked later. The useful version fits on one page and has six blocks: the problem, the outcome you expect, the cost range, the risks and how each is mitigated, the measures you will report, and the date by which the organisation will decide. Everything else is appendix. If you cannot say what problem the seats solve in two sentences, you are not ready to buy them, which is a respectable place to be.

A better case ties the spend to two or three named workflows with a baseline. A 4,000-person insurer might choose first-draft claims correspondence, policy-wording comparison and the monthly management pack. For each it records today's cycle time and error rate, who touches the work, and what "better" would look like in numbers that already exist in the organisation's systems. Anthropic's own Claude Code admin Value tab, added in July 2026, shows its estimated productivity lift with the formulas visible and the inputs adjustable; borrow that honesty. Write your assumptions where a sceptic can change them.

End with a decision date and the name of the person who owns it. A one-page case that says "we will decide on 15 March on the basis of these three measures" is a stronger document than twenty pages of potential. Decide what you want first, then buy exactly that.

Before anyone switches on a connector, somebody has to find out what the organisation would actually do with Claude. A use-case inventory is the unglamorous list that answers this: every candidate task, who does it, how often, what data it touches and what a good result is worth. You gather it by asking departments rather than guessing for them. A short form, a thirty-minute conversation with each team lead and a look at the ticket queue will surface more than a strategy offsite. A university's registry, a city council's planning desk and an insurer's claims team each produce different lists, and that is the point.

How we know which tasks sit where comes partly from law. The EU AI Act, in force since 1 August 2024, lists in Annex III uses it treats as high-risk, including decisions about recruitment, worker management, credit and access to essential services; using an assistant to draft a job advert is ordinary, using it to rank applicants is not. The GDPR's Article 9 names special categories of personal data, and the UK ICO's guidance on AI and data protection asks for a data protection impact assessment before high-risk processing. Those lists are a ready-made sensitivity column. Anthropic's Economic Index, published from March 2025 onwards on anonymised Claude conversations, found actual use concentrated in software development and writing, with augmentation more common than full automation; your inventory will probably look similar, and it is useful to know that in advance.

Keep the inventory alive after launch. Tasks move between quadrants as controls arrive and as people learn what the tool is good at, and an inventory from January is a historical document by June.

A pilot exists to teach the organisation something it does not yet know, which is a different purpose from proving that the sponsor was right. Design it that way and the result is useful whichever way it falls. The ingredients are familiar from any field trial: a size large enough to see an effect, a duration long enough for novelty to wear off, a baseline or control group, success thresholds written down before the first login, roles that differ from one another, and exit criteria that say what happens at the end.

A baseline is the part most pilots skip, and then regret. Measure the chosen workflows for two weeks before anyone gets a seat, using numbers the organisation already collects: tickets closed, documents produced, cycle time, rework. Where you can, keep a comparison group of similar people without seats for the same period. The published research explains why this matters. Brynjolfsson, Li and Raymond's 2023 study of 5,179 customer-support agents found an average productivity gain of about 14 percent, concentrated among newer staff. Dell'Acqua and colleagues' 2023 field experiment with 758 consultants at Boston Consulting Group found large gains on tasks inside the model's competence and worse results on a task deliberately placed outside it, the "jagged frontier". And METR's July 2025 randomised trial found experienced open-source developers were around 19 percent slower with AI tools…

A pilot that teaches ends with a short note: what we measured, what moved, what surprised us, what we will switch on next and what we will not. That note is the first page of your rollout plan.

Every enterprise purchase passes through a security questionnaire , and the questions are more standard than their senders think. Most are drawn from a handful of published frameworks: the Cloud Security Alliance's CAIQ, the Shared Assessments SIG, the UK NCSC's fourteen Cloud Security Principles, Germany's BSI C5 catalogue, and increasingly the clauses of ISO/IEC 42001 for AI management. Knowing that lets you plan the review as a mapping exercise rather than a correspondence. The job is to find, for each question, the document that already answers it, and to spend your own analysis time on the few that are genuinely about your organisation.

The questions that need real thinking are about data flows, and here Claude Enterprise has a published architecture to read. Chat and Cowork sessions that need code or files run in a per-session cloud sandbox, separate from Anthropic's corporate, research and training environments; the sandbox cannot reach private or metadata addresses, all its outbound traffic goes through a mandatory proxy, the Enterprise default is no network access, and connector tokens never enter it because connector calls happen server-side. That paragraph, from Anthropic's support documentation, answers a dozen questionnaire rows at once. Add your own diagram showing identity (SSO and SCIM), the connectors you intend to approve and the systems they reach, retention you will set, and where audit logs and the Compliance API feed your SIEM.

A 2,000-person Dutch engineering firm, a US hospital group and a UK council will weight the frameworks differently, but each will finish faster for having mapped the questions first. The questionnaire is not an obstacle; it is the first draft of your operating controls.

The contract for Claude Enterprise arrives as a stack of documents, and reading it well means knowing which layer answers which worry. At the top sits the order form: seats, term, the seat minimum, the usage arrangement at API rates, renewal and notice. Beneath it the commercial terms of service govern the relationship. Beneath that the data processing addendum governs personal data, with its annexes on sub-processors, security measures and international transfers. Each layer binds; the trick is to find the clause rather than the reassurance.

For organisations in the EU and the UK the DPA has to satisfy Article 28 of the GDPR, which lists what a processor must promise: act only on documented instructions, keep confidentiality, assist with data-subject requests and breach notification, delete or return data at the end, and allow audits. International transfers to the United States rest on one of two mechanisms. The European Commission's adequacy decision for the EU–US Data Privacy Framework of 10 July 2023 covers transfers to certified US companies; the UK's extension to that framework, the "data bridge", took effect on 12 October 2023. Where a transfer falls outside the Framework, the 2021 Standard Contractual Clauses, or in the UK the International Data Transfer Agreement or Addendum, do the work, usually with a transfer risk assessment on file. Ask which mechanism the DPA relies on and record the answer.

Finally, renewal. An annual term with a seat minimum is a floor, not a forecast; make sure the notice period and the true-up rules are on your calendar, not just in the file. A contract read once, properly, is a contract you will not need to read again in a hurry.

The question "how many seats" is really the question "who, in what order, and how will we know". Claude Enterprise is sold per seat on an annual commitment with a seat minimum, and since February 2026 the self-serve route offers a single seat type, so the arithmetic is simple; the planning is not. Two honest strategies exist. Give everyone a seat on day one, which treats the tool like email and removes the politics of who was chosen. Or build cohorts , which costs less at first and matches the way Anthropic recommends rolling out agentic features: one role, a monitoring window, then waves.

Edge cases need decisions in writing. Part-time staff count as whole seats, so decide whether a two-day-a-week role gets one. Contractors and agency staff usually sit in a separate directory group with a shorter lifecycle; if they get seats, their offboarding must be as automatic as their onboarding, which is exactly what SCIM deprovisioning is for. Do not plan for external guests as a substitute for seats; check the current sharing settings before promising a law firm or agency anything. Service accounts for automation belong on the API, not on a seat.

Growth is the last line. Seats usually true up at renewal or at agreed points; put the first review at day 90, when the pilot note is in and the quick wins have either spread or stalled. A roster of named groups with owners is a plan you can defend to finance, to security, and to the colleague who asks why they were not in wave one.

The per-seat fee is the easy half of the bill. The other half is usage , billed at API rates, and it depends on what people actually do: a few chats a day costs very little, while an afternoon of agentic Cowork sessions or a developer running Claude Code across a large repository consumes tokens by the million. Forecasting that half is a matter of profiles, model mix and guardrails, and the honest output is a range with a floor and a ceiling.

Model mix is the second lever. Opus-class models cost more per token than Sonnet, and Sonnet more than Haiku; the organisation can set model defaults and entitlements per role, and Efficient mode , which restricts the unified experience to Sonnet and Haiku with new sessions defaulting to Sonnet 5.5 at low effort, can be applied org-wide or per role. A forecast therefore needs a column for "which model, how often", and that column is also a policy decision: a council might run everyone in Efficient mode and lift the restriction for a named group; a software firm might do the reverse.

Countries add frictions. A German firm will want group-level reporting aggregated enough to satisfy its works council; a UK public body will want the range on a single page for its spending control.

There are three ways to pay for Claude Enterprise, and the choice is mostly about whose budget line the money leaves and how fast procurement can move. The first is direct with Anthropic's sales team: an order form, an invoice and net payment terms, suited to larger organisations that want negotiated terms, a security review in parallel and a named account contact. The second is the AWS Marketplace listing, through which the subscription can be bought as a private offer and drawn down against an existing AWS spending commitment. The third, available since 12 February 2026, is self-serve online with a card, offering a single seat type and the standard terms, suited to a department or a smaller company that wants seats this week rather than this quarter.

Seats and platform access are different purchases, and it helps to say so in the business case. Seats are for people: chat, Cowork, Claude Code, Design, the office integrations. Platform access is for software you build: Claude models through Anthropic's API, through Amazon Bedrock, through Google Cloud's Vertex AI, and, since late 2025, through Microsoft Foundry. The sister volume Agents in Production covers that side; here the point is that an organisation can hold both, often under the same cloud commit, and that automations belong on the platform side rather than on a human seat.

Whichever door you choose, you end up in the same building with the same admin console. Buy through the door that is open, and spend your negotiating energy on the terms that matter, not the invoice address.

The fastest way to stall a deployment is to let a small "AI team" own everything. They become the bottleneck for every connector request, budget question and nervous email from legal, and within a quarter the organisation concludes the tool is slow when it is the queue that is slow. A RACI chart, naming who is Responsible, Accountable, Consulted and Informed for each area, is the ordinary remedy. It is not glamorous, and it is exactly what ISO/IEC 42001 asks for in its clause on roles and responsibilities, and what the NIST AI Risk Management Framework means by its Govern function.

The sensible pattern spreads ownership along existing lines. IT owns settings and provisioning because it already owns identity. Security owns connector policy and incident response because it already owns both for every other system. The data owner in each department, not the AI team, approves connectors into that department's data, because the connector respects the user's existing permissions in the source system and someone must vouch for those permissions. Finance owns budgets. The people team owns training, with the champions responsible for delivery. The transformation lead is accountable for the programme and the use-case inventory, and is consulted everywhere, which differs from doing everything.

How we know a RACI is working is the audit log: connector approvals granted by the right role, settings changed by named admins, budgets adjusted by finance. A chart that matches the log is governance; a chart that does not is a poster. Keep it to one page and review it when the organisation changes, not when something breaks.

Every good programme has a moment when someone can still say no. The go or no-go meeting at day 30 or day 60 is that moment, and its quality depends on what was decided before the pilot began: the thresholds, the measures, the risks that had to be closed. If those were written down, the meeting is a reading of evidence. If not, it is a negotiation between the enthusiastic and the anxious, and the enthusiastic usually win, which is how a rollout nobody can explain begins.

Six questions make the pack. Did the pilot meet the thresholds, with the baseline shown beside the result and the comparison group if there was one? Are the named risks closed, meaning the security review signed, the DPA executed, the retention and network settings reviewed, and the connector policies set? Is the budget approved as a range with the spend limits configured as the ceiling? Is training ready, with the champions named and the first sessions scheduled? Are communications ready, including the AI policy people will actually read and the no-go list? And is the operating model in place, the RACI agreed and the incident path tested at least once? Each gets a green, amber or red, and a line of evidence: a dashboard screenshot, an audit-log extract, a signed document.

How we know the decision was sound is the record: pack, evidence lines and written outcome, filed with the business case. A year later the answer to "why did we do this" should be a page, not a memory. Decide, write it down, and go to the next gate.

Single sign-on is the first switch you throw, and the only one that makes every later switch mean anything. Until Claude trusts your identity provider rather than a password, a role is just a label on an account anyone could have created. With SSO, the account is your account: it exists because Okta, Microsoft Entra ID, Google Workspace or another SAML provider said so, it carries the groups that provider holds, and it stops working when that provider says stop. Anthropic's admin guide describes it in those terms.

How do we know it works? Not from the green tick. A 2,000-person Dutch logistics firm I would describe as typical ran a one-hour test with four people in four roles, screenshots of each sign-in, and the audit log open beside them, before flipping enforcement at 07:30 on a Tuesday when the help desk was fully staffed. That is the evidence: the audit log shows the login events, and the help desk ticket queue shows what you missed. Decide now where the keys live. Only one Primary Owner exists per organisation, it uses a seat, and Anthropic's roles article says it may be a service account rather than a person. A named individual who leaves on holiday with the Primary Owner role is a risk you chose.

The myth to retire is that SSO is an IT nicety you can add later. Later means after people have personal accounts full of work, and after domain capture (the next chapter) becomes an awkward conversation rather than a tidy migration. One domain, one provider, one enforced path in. Everything in this part of the book stands on that.

Most organisations discover, on the day they verify their domain, that Claude already has dozens or hundreds of accounts on it. People signed up with work email for a free trial, a Pro subscription paid on a personal card, a Max plan expensed quietly. Domain capture is the process by which an Enterprise admin finds those accounts, claims them and brings them into the organisation. Anthropic's support article calls it claiming and migrating accounts on your domain, and it is Enterprise-only: a Team plan can verify a domain and block new personal sign-ups, but cannot claim existing ones.

From confirmation the clock runs for thirty days, one deadline for the whole claim rather than a timer per person, and it cannot be lengthened. Each person is told immediately by email and by an in-product banner, and chooses: merge and join, which brings chats, projects, files and memory into a new Enterprise account, or join fresh. At the deadline, unmigrated personal accounts are deactivated, paid Pro and Max subscriptions are cancelled with a prorated refund, and anyone who never chose gets a fresh account with their old data emailed to them. HIPAA-ready and CMEK organisations are the exception: people may only join fresh, and nothing transfers.

Two details catch people. A claim covers only the domains verified when it starts, and only one claim runs at a time, so verify every domain and subdomain first or you will wait another month. And subscriptions bought through Apple's App Store are not cancelled for you; those users must do it themselves. Capture is not a punishment for using Claude early. It is the moment the organisation says: your work is our work, and we will keep it safe.

Provisioning is the difference between an organisation that knows who has Claude and one that hopes it does. Anthropic offers five modes in Organization settings, Organization and access, User provisioning: Invite only (the default), just-in-time (JIT), JIT with group mappings, SCIM directory sync, and SCIM with group mappings. The choice decides how joiners get in, how movers change role and how leavers go out. That lifecycle, joiner-mover-leaver, is the oldest idea in identity management, and Claude's admin guide maps onto it cleanly.

The provider matters more than the protocol. Setup guides exist for Okta, Microsoft Entra ID, Google, OneLogin and JumpCloud, with other providers through WorkOS. Entra ID pushes SCIM changes only every forty minutes, so a leaver removed at 09:00 may still have access at 09:35, which your offboarding runbook should state rather than discover. For custom roles under SCIM, the guide prescribes two passes: save with group mappings off, let the sync finish, attach the synced groups to roles, then enable mappings. Skip a pass and people land with no permissions at all.

The myth is that JIT is the lazy option. It is the right option for small organisations with a tidy provider and a disciplined leaver process, and it costs nothing. It becomes the wrong option the day you cannot name who removes leavers by hand. Groups are also how you run rollout waves: a pilot group this month, a department next, each mapped to a role. Provisioning is not plumbing. It is the organisation chart, made executable.

Claude Enterprise ships with four built-in roles and one escape hatch. The roles, per Anthropic's roles and permissions article, are User , Admin, Owner and Primary Owner , each a superset of the one below. A User creates and modifies chats and uses projects. An Admin also invites and removes members and, on Enterprise, views usage analytics. An Owner adds billing, integrations, capabilities, project sharing, SSO, audit logs, data retention and feedback settings, and may appoint or remove Admins and Owners. The Primary Owner, of which there is exactly one, can additionally request data exports and transfer primary ownership. The escape hatch is the Custom role, whose permissions come from groups rather than from the ladder.

How do we know who holds what? The Members page shows effective roles and exports a CSV; the audit log records every change of role. Anthropic's own guidance says to export that CSV before touching roles, migrate a pilot group first and keep a rollback plan. One trap the article names outright: Identity & Access at Manage can edit roles and groups, including its own, so a member with it can widen their own access. Reserve it for the people you would trust with the domain controllers.

The myth is that more Owners means more resilience. It means more people who can change retention, disable SSO or open external sharing on a bad afternoon. Two Owners who are awake, plus a vaulted Primary Owner and a handful of narrow custom roles, is a tenant you can explain to an auditor in one breath.

A custom role in Claude Enterprise is a bundle of four things attached to one or more groups: capabilities, admin permissions, connector access and model access. Group-based role controls arrived on 9 April 2026; on 28 May 2026 roles gained control over which connectors, and which individual tools inside a connector, each role may use. Roles live under Organization settings, Roles, with tabs for Capabilities, Permissions, Connectors and Models; groups live under Organization settings, Groups. A member whose role is set to Custom gets only what their groups' roles grant. A custom member with no group has nothing.

Design five or six roles, not fifty. A roster that keeps appearing: Everyone: chat, projects, artifacts, web search, memory per the organisation's policy, Sonnet by default. Engineering: adds Claude Code with cloud sessions and remote control, Cowork, GitHub and the ticketing connector, Opus with a high effort cap. Analysts and finance: adds Cowork and the Microsoft 365 connector with read tools only, and the Analytics area at Can view. Regulated work (legal, HR, clinical): a narrower set, connectors at Needs approval, no Chrome, memory off, and Privacy at Can view so they can see retention without changing it. Admin-lite: Billing or User Management at Can manage, no Owner status. Each maps to one identity-provider group, so joining the group is the whole onboarding.

The myth is that fine-grained roles are the secure choice. Fifty roles nobody can explain are a hiding place for stale access. Six roles you can draw on a whiteboard, attached to groups your identity provider already has, are a control. Anthropic's guidance to export the member CSV, pilot one group, and keep a rollback plan is not caution for its own sake; it is the difference between a role migration and an outage.

Under Organization settings there is a page called Capabilities . It is the most consequential page in the tenant and the least dramatic to look at: a column of toggles for Chat, Memory, Web search, Claude Code, Cowork, Claude in Chrome, Artifacts, Design, Scheduled tasks and, since 23 October 2026, Chat and Cowork unified. Some have sub-toggles, such as Cloud sessions and Remote control under Claude Code. Owners and Primary Owners can change them; a custom role with Identity & Access at Manage can see them. Anthropic's custom-roles article explains the four-level precedence that gives the page its weight: a platform override from Anthropic sits above everything, then the organisation toggle, then role grants, then the member's own setting. If the organisation toggle is off, no role can grant the feature. If it is on, a custom-role member still needs a role that grants it, while Users,…

So write it down. The audit log records configuration changes, but it records the what, not the why. A change log that pairs each toggle with a date, a name, a ticket and a sentence of rationale is what an ISO/IEC 42001 auditor, an EU AI Act article 4 literacy reviewer or a works council will actually read. A 3,000-person Canadian retailer keeps that log as a Project in Claude itself, shared with the organisation, so anyone can ask why Chrome is off for the stores and get the answer the Owner wrote in March.

The myth is that an enabled capability is a decision made once. Anthropic adds toggles, renames them and moves some from beta to general availability every month; the page you reviewed in spring is not the page you have in autumn. Put a quarterly review in the calendar (Part 10 covers the ritual), and treat every new toggle as off until someone owns the reason for on. The Capabilities page is not where features live. It is where your intentions become settings.

Every Claude Enterprise seat can reach the whole model family: Haiku 5.5, Sonnet 5.5 and Opus 5.5 as of October 2026. Whether a given person should reach all of them is a question about work and money, and since July 2026 it is a question the admin console can answer. Model access , in beta under Organization settings, Models, works at two levels. The organisation level enables or disables each model for everyone, Owners included, and is the ceiling. The custom-role level grants a subset of the enabled models, sets an optional maximum effort per model from a gear icon, and sets the role's default model and effort. All models start enabled at both levels, so nothing changes until you decide. Haiku models are always available and cannot be disabled.

Efficient mode is the blunt instrument. Switched on from the Models page for the organisation or from a role's Models tab, it restricts the unified Chat-and-Cowork experience to Sonnet and Haiku, and new sessions start on Sonnet 5.5 at low effort. It suits a front-line role whose work is drafting, summarising and looking things up, and a pooled group budget (Part 10) that must last the quarter.

The myth is that restricting models is how you save money. Defaults save money; restrictions mostly create workarounds. Give capable people the capable model, make the cheap one the starting point, and let the usage data tell you which you got wrong.

Shadow AI is not a people problem. It is a network problem, and Claude Enterprise gives you two network-level tools for it. The first is tenant restrictions : your web proxy injects a header, anthropic-allowed-org-ids, carrying the UUIDs of the organisations allowed from that network, and Anthropic refuses any sign-in to an organisation not on the list. The second is IP allowlisting : Anthropic checks the source address of every authenticated request against CIDR ranges you supply, and blocks the rest. One keeps personal accounts off your network; the other keeps your accounts off other networks. They answer different questions and most organisations end up wanting both.

IP allowlisting is Enterprise-only and not self-service: you compile the ranges (offices, VPN exits, approved cloud egress) in IPv4 or IPv6 CIDR and send them to your Anthropic contact or Support. Miss a range and you lock people out. The allowlist covers chats, projects, artifacts, Docs and connected tools. It does not cover artifacts shared externally; to keep those behind it, turn off External sharing and outside email invitations under Organization settings, Artifacts.

The myth is that blocking is enough. Blocking personal Claude on the corporate network sends people to their phones on mobile data. The pairing that works is a closed door and an open one: tenant restrictions on the network, an enterprise seat for everyone who needs one, and a policy (Part 9) that says why. Walls are cheap. Doors are what people use.

The desktop app is where Claude touches the machine: local folders, local MCP servers, desktop extensions, Claude Code and the Cowork virtual machine. It is also the one surface you can govern with the tools you already own. Anthropic publishes a set of MDM policy keys for Claude Desktop, applied on Windows through the registry under HKLM, SOFTWARE, Policies, Claude, and on macOS through a configuration profile for the domain com.anthropic.claudefordesktop. Only Team and Enterprise administrators can use them.

The catch is the format. On Windows, forceLoginOrgUUID with several organisations must be a REG_SZ string holding JSON text, not a REG_MULTI_SZ; booleans are DWORDs of 1 and 0. On macOS the array is a string containing JSON. Anthropic's article says to restart the app after changes and to confirm them under Help, Troubleshooting, Generate Diagnostic Report. That report is also your evidence: a screenshot of it from a sample of machines is what you hand the auditor, alongside the MDM console's compliance view.

How we know the keys work is the diagnostic report and the MDM's own reporting, and Anthropic's article is explicit that a key set to false at machine level overrides the in-app extension allowlist, so leave the extension keys unset or true if you intend to use that allowlist. A Belgian hospital group disabled local MCP on clinical workstations and left it on for the data team, using two MDM profiles, after its DPIA found that local servers could reach patient files outside the connector controls. A Japanese trading house did the opposite and allowed extensions only from an internal directory. Both wrote the decision down. The desktop is not a loophole in the tenant. It is the tenant, extended to the keyboard, and it takes the same deliberate switches.

Offboarding is where identity work is graded. The leaver is a Friday afternoon with HR, a laptop in a drawer and a question nobody has asked yet: what happens to the chats? Anthropic's support article on removed users answers most of it. Removing someone does not delete their account or data. Other members lose access to the leaver's chats, including snapshots shared with the organisation, and a shared link now says Conversation not found; the data remains in organisation exports. Private projects become unreachable to colleagues, so the leaver must grant edit access before they go. Projects shared with the organisation move to the Team tab; those shared with named people stay under Shared with me. Re-adding the same email restores their chats, projects and unshared skills.

The mechanics are the SCIM chapter run backwards. Unassign in the identity provider and SCIM removes the account; under JIT with mappings the removal lands at the next login, and under plain JIT a human must act. Remove only in Claude and the person is re-added at their next SSO login, so the runbook says both places, every time, and notes Entra ID's forty-minute sync. Movers are the quieter risk: a transfer from engineering to sales should drop Claude Code and the GitHub connector, which group mappings do automatically and manual role assignment never does.

The myth is that offboarding is an IT task. It is a records task, a legal task and a kindness: the colleague leaving should know what they can take, what stays and why. Write the three sentences now, while nobody is leaving. Control the process, which is yours; let the rest be what it is.

Start with the question every security questionnaire asks in its first paragraph: where does the data go? For a Claude Enterprise seat the honest answer fits on one page. A prompt leaves the browser, desktop or mobile app over an encrypted connection, lands in Anthropic's systems, is held encrypted at rest, is sent to the model for inference, and the response comes back the same way. If the person attached a file, the file follows the same path. If a connector is involved, Claude's servers fetch what the person is allowed to see in Google Drive or Microsoft 365 using a token that stays on the server side, and that content joins the conversation.

Geography is the part that differs by country. Anthropic says it may process data in the countries where it or its partners operate, and for transfers out of the EEA and the UK it relies on adequacy decisions and Standard Contractual Clauses. A 4,000-person insurer in Munich will have its works council ask exactly this, and the clean answer is the DPA plus the US-only inference toggle described in chapter 33, not a hand-wave about "the cloud". A UK council will put the same facts into its DPIA. A US health system will add the BAA.

What this means on Monday is modest and useful. Write the one-page data-flow diagram yourself, in your own words, with the Trust Center documents attached. The people who approve this will trust a drawing they can check over a brochure they cannot.

By default a Claude Enterprise organisation keeps conversations until someone deletes them. Custom data retention turns that into a policy: a Primary Owner or Owner opens Organization settings, Data and Privacy, and sets a period, with 30 days as the minimum and each month counted as 30 days. Anthropic's admin article on retention controls, updated for the unified experience in October 2026, is the source for everything that follows, and it is more precise than most people expect.

Deletion is a cascade and a schedule, not a moment. When a period ends the data is removed from back-end systems and cannot be recovered. If you shorten a period, everything now out of range is queued for permanent deletion the moment you save, handled by a daily background process that can take several days; the article warns you not to rely on that delay to reverse a mistake. Content flagged by Trust and Safety, or held because the law requires it, may be kept longer. Every change to the retention setting, and every deletion event, is written to the audit log, which is how you prove the policy ran.

Pick a number you can defend to both a regulator and a works council. For most organisations that is somewhere between 90 days and a year, written down with the reason.

Two controls answer the question that board members ask after the data-flow page: can we hold the key, and can we keep it in one country? Customer-managed encryption keys (CMEK) and US-only inference are the answers, and both come with limits you should read before you promise anything.

US-only inference is simpler. A Primary Owner, Owner or a custom role with the Privacy permission set to Can manage opens Organization settings, Data and privacy, and turns on the toggle. From then on model inference, the processing that generates a response, runs on servers located in the United States across every Claude app, including Claude Code and the desktop app, and including background jobs such as conversation titles and memory. It does not change where data is stored, it does not cover what a connector such as Slack or Google Drive does on its own infrastructure, and it is available on usage-based Enterprise plans only, with a usage premium on the newer models. Organisations whose contract already required US routing find the toggle on and locked.

Hold the key if your policy requires it, and know that holding it makes you responsible for it.

An audit log is the difference between believing your settings and proving them. On Claude Enterprise it is an Enterprise-only feature, and Anthropic's admin article on accessing audit logs describes it plainly: an Owner or Primary Owner opens Organization settings, Data and Privacy, presses Export logs, and receives an email with a download link that expires 24 hours after it is sent. Each export covers the past 180 days. Chat and project titles and content are not included, only their identifiers, so the log tells you who did what and when, never what was said. Primary Owners can export chat content separately through a data export, and organisations using customer-managed keys use the Compliance API because the Export button is unavailable to them.

How we know it is enough is the standard you are audited against. ISO/IEC 27001:2022 control A.8.15 asks for logs that are produced, stored, protected and analysed; SOC 2's monitoring criteria ask much the same; the GDPR's accountability principle asks you to demonstrate compliance, not assert it. A quarterly access review at a UK university, for example, takes the export, joins it to the HR leavers list and confirms that each leaver's last sign-in precedes their leaving date. An investigation at a Canadian bank starts from a conversation identifier in the log, then pulls the content through the Compliance API under legal supervision.

The log is not surveillance of your staff. It is the receipt for your own decisions.

If the audit log is the receipt, the Compliance API is the filing cabinet with a door you can automate. It gives an Enterprise organisation programmatic access to its activity feed, its conversation content (chats, uploaded files, projects and attachments), its session transcripts and its directory data, through endpoints under api.anthropic.com/v1/compliance. Anthropic's developer documentation and the admin article on integrations are the sources, and both were refreshed when Anthropic announced partner integrations on 21 May 2026.

Switching it on is a Primary Owner act, under Organization settings, API; Owners can see the page but not the toggle, and Admins cannot see it at all. Keys are scoped, and the activity feed is available to any key holding the read activities scope. All compliance endpoints share a budget of 600 requests a minute per parent organisation, with remote sessions carrying a second budget on top. This is a pull model: you ask, it answers, after the fact. For a control that acts before a prompt reaches the model, Anthropic points to inference hooks, which are a different product.

Use it to answer questions you can state in advance. A compliance feed nobody has a question for is just another copy of the data.

Your security operations centre already drinks from a hundred firehoses, and it will ask for one more. Claude Enterprise obliges through OpenTelemetry : an admin sets an OTLP endpoint, a protocol (HTTP with JSON or protobuf) and headers such as a bearer token under Organization settings, Cowork, and from then on structured events stream to your collector. Nothing flows until the endpoint is configured, which is the first thing to tell a nervous privacy officer. Anthropic's article on monitoring Cowork activity with OpenTelemetry is the source; Claude Code has its own, long-established telemetry, which the sister book covers.

Content capture is a device policy, not an admin toggle, which is the clever part. The otlpContentCapture key is deployed through your device management tool, and prompt text, responses and tool inputs are off by default in current desktop versions. Email addresses, folder paths and API error messages are always included, and errors can echo parts of the request, so filter at the collector. Coverage has edges: the content policy applies to Cowork sessions started from the desktop app, local or cloud; sessions started on the web or mobile, scheduled cloud tasks and chats moved to the cloud in the unified experience carry metadata only.

Telemetry is a view, not a verdict. Decide what you would do with an alert before you create the alert.

A hospital does not ask whether Claude is "HIPAA compliant", because no product is; it asks whether Anthropic will sign a Business Associate Agreement and which features the agreement covers. Since 12 January 2026 the answer for Claude Enterprise has been yes, with a HIPAA-ready configuration, and since 14 July 2026 a Primary Owner can manage it without a sales call: open Organization settings, Data and privacy, turn on HIPAA compliance and accept the BAA. A separate step applies the HIPAA configuration to Claude Code and Cowork in local mode. Anthropic's support article on BAAs for commercial customers is the source, and it is organised as three columns that every covered entity should copy into its own policy.

How we know it holds is the audit trail, not the contract. The Compliance API captures local-mode sessions and keeps them readable for up to 30 days, and the configuration pushes several surfaces, such as transcript export and third-party crash reporting, off entirely. A US regional health system with 11,000 staff would, in practice, enable the configuration, restrict connectors by role, and run a 60-day pilot in a clinical documentation team with a privacy officer sampling conversations through the API. That sample is the evidence for the risk analysis the HIPAA Security Rule requires.

The myth is that a signature makes you compliant. The configuration, the columns and the pilot evidence do; the signature just makes it possible.

Two European laws govern a Claude rollout, and they ask different questions. The GDPR asks whether you may process personal data this way; the EU AI Act asks whether the AI system is used responsibly. Treat them as one project with two checklists, starting with the older one.

The AI Act runs on a timetable. It entered into force on 1 August 2024. On 2 February 2025 the prohibited practices and the article 4 AI literacy duty took effect, the duty that chapter 79 turns into a training plan. On 2 August 2025 obligations for general-purpose AI model providers began, which is Anthropic's problem rather than yours. On 2 August 2026 the article 50 transparency duties apply, including telling people when they are interacting with an AI system. The high-risk obligations were due the same day, but in May 2026 the EU institutions reached a provisional agreement on the digital omnibus that moves the stand-alone Annex III deadline to 2 December 2027 and the embedded-product deadline to 2 August 2028; the new dates take legal effect only on publication, so check the Official Journal before you plan around them.

Do the DPIA, keep the logs, tell the people. The law will move its dates; those three duties will not.

An assistant that reads documents, browses the web, calls connectors and runs skills has an attack surface no chatbot had. The useful frame is the OWASP Top 10 for LLM Applications , 2025 edition, which is the consensus list security teams already use. Four of its entries do most of the work for a Claude Enterprise deployment: prompt injection (LLM01), sensitive information disclosure (LLM02), supply chain (LLM03) and excessive agency (LLM06). Think of them as four ways in or out, with one gate.

Reach is excessive agency: a connector with more permissions than the task, a Google Drive that exposes the whole company, an MCP server with write tools nobody reviewed. Connectors inherit the person's own permissions, and custom roles can allow or block individual connector tools. Supply is skills and plugins. Since 2 October 2026 Enterprise organisations scan third-party skills and plugins by default when they are uploaded or edited, with a Pass, Warn or Fail verdict, a banner that must be acknowledged, and an Allow anyway override reserved for Owners and roles that can manage libraries, applied per version. The article is honest about the edges: it looks for malicious intent, not bugs; it does not scan MCP servers; and it is not available with CMEK, ZDR or the HIPAA configuration. Exit is exfiltration, and the control is network egress, off by default in Enterprise cloud sessions,…

Assume the document is hostile, the connector is too wide and the skill is unreviewed. Then switch on the controls that make those assumptions cheap.

A certificate proves that someone else checked something, once, within a scope. That is valuable and it is limited, and a good auditor knows both. Anthropic's commercial products carry SOC 2 Type I and Type II attestations, ISO/IEC 27001:2022 for information security management and ISO/IEC 42001:2023 for AI management systems, which Anthropic obtained in January 2025 as one of the first model developers to do so, plus the HIPAA-ready configuration from chapter 37. The support article on certifications and the Trust Center at trust.anthropic.com are where you request the reports; the SOC 2 report is under NDA, the ISO certificates are public. For government buyers, the route is usually a FedRAMP-authorised cloud, such as AWS GovCloud through Bedrock, rather than the Enterprise plan itself, and a UK public body will ask about Cyber Essentials and G-Cloud listing for its own procurement,…

So build your own evidence pack, and keep it boring. Layer one is Anthropic's documents: the SOC 2 report, the ISO certificates, the DPA, the sub-processor list and the BAA if signed, each dated. Layer two is your configuration: the directory and effective-settings output from the Compliance API, or dated screenshots of the Capabilities, Data and privacy, Connectors and Plugins and skills pages. Layer three is your records: the DPIA, the AI policy people signed, the training register for the article 4 literacy duty, the monthly audit-log exports and the works-council agreement where one exists. Layer four is the measurement: the pilot results, the usage analytics and the incident log, including the day nothing happened. An ISO 27001 auditor in Stockholm, a SOC 2 reviewer in Austin and a BaFin examiner in Frankfurt will each start at a different layer, and each will find what they need.

Certificates open the door. Your settings and your records are what you are judged on once inside.

A project is the simplest way to give Claude standing context without pasting it in every time. You make a room, put the reference documents on the shelf (knowledge files), pin the house rules to the door (project instructions), and decide who holds a key. Every chat that starts in that room sees the same files and the same instructions, and nothing else from the rest of the organisation leaks in. On Team and Enterprise a project can stay private to its members or, if an Owner has allowed it, be shared with the whole organisation, with each member set to Can view or Can edit. The Projects page shows three tabs: Your projects, Organization, and Shared with you.

The working rule is one project per team process, not one per team. A 4,000-person insurer in Zurich runs a project called Motor Claims Letters: the claims-wording standard, twelve model letters, the regulator's plain-language guidance, and an instruction to write at reading age twelve in German, French and Italian. A university research office keeps Grant Costing: the funder's eligible-cost rules and the institution's overhead rates, shared with the organisation so any principal investigator can use it. A city council in Ohio has Public Records Requests, with the state statute and the council's response templates, private to the four clerks who answer them.

People confuse projects with skills. A project is a place with a door: context plus members. A skill is a procedure that travels with the person who invokes it, wherever they are. Put the facts of a process in the project and the method in a skill, and both stay small.

An artifact is the thing Claude makes rather than says: a document, a slide deck, a working app, a dashboard, a Claude Doc. In an organisation the question is never whether people will make them but where they will go afterwards. Anthropic's sharing article for artifacts, dated 23 September 2026, draws four circles. Private is the default; nothing leaves until the maker shares it. Organisation sharing lets you give an artifact to named people, to groups (Enterprise only) or to everyone in the tenancy, at Can view, Commenter or Can edit. Anyone with the link extends it to any signed-in Claude user, but only if an Owner has turned on External sharing, and an artifact that connects to your apps or calls Claude cannot use that option at all. Email invitations (in beta) reach up to fifty people outside the organisation per artifact; pending invitations lapse after thirty days.

Three scenes. A pharmaceutical affairs team in Copenhagen builds a medicines-shortage dashboard as an artifact; because it pulls from a connector, it cannot be given a public link, which is exactly right. A Welsh housing association's communications lead shares a tenant-letter template with the organisation at Can edit so every office improves it, then archives the project when the campaign ends. A US federal contractor finds, during an audit, that External sharing was on since the pilot and that four artifacts had links in the wild; the fix was one switch and a review of the four.

When should public sharing be off? When your sector regulator would ask you to prove where a document went and you could not. Otherwise leave it on for the roles that need it, through a custom role, and keep the default off for everyone else.

Memory is Claude's record of what it has learned about a person across their chats: their role, their projects, how they like things written. Anthropic brought it to Team on 11 September 2025 and to Enterprise a week later, and then, on 25 August 2026, changed the default: memory is now off for every Team and Enterprise member until they turn it on, and an Owner must first make it available under Organization settings > Capabilities. Sensitive topics (health, religion, politics and the like) are never remembered unless the user separately switches on Include sensitive topics in memory, and even then Claude shows a notice each time it saves one. Some things are never saved at all: government identification numbers, criminal history, financial account numbers, immigration status.

Incognito is the ghost icon in the top right of a chat. An incognito chat adds nothing to memory, is not saved to history, and will not be found by Search past chats later. It is not a privacy cloak against the organisation: on Team and Enterprise, incognito chats still appear in data exports and follow the retention policy, kept for at least thirty days. Tell staff both halves of that sentence; the first half is a courtesy, the second is the law of the tenancy. Search past chats, controlled by the Search and reference chats toggle, shows its searches as tool calls with citations to the original chat, and is not available where customer-managed keys are in use.

In Germany a works council will treat memory as a tool that can, in principle, build a profile of an employee, which brings BetrVG §87 into the conversation; in the EU generally, a memory store is personal data under the GDPR and belongs in the record of processing. A UK council's DPIA took half a page to cover it: off by default, user-controlled, admin-invisible, deleted with the account. Write that paragraph before the first member turns it on, not after.

A connector is how Claude reaches a system you already run: your mail, your files, your CRM, your ticket queue. Without one, Claude knows only what is typed or uploaded. With one, it can search live data and, if you allow it, act: send the email, create the ticket, update the record. Every connector on the plan speaks the Model Context Protocol (MCP), the open standard Anthropic published on 25 November 2024 and which the big vendors have since adopted. Pre-built connectors are the ones Anthropic lists in its directory (Google Workspace, Microsoft 365, Slack, Salesforce and others); custom connectors are remote MCP servers your own teams or vendors host. Building a server is the sister volume The MCP Field Guide ; this chapter is about running them.

Read and write are different animals. Read tools search and fetch. Write and delete tools change the world, and each can be set by an Owner to Always allow, Needs approval or Blocked. Blocking the write tools makes any connector read-only, which is where a first rollout should start. Some write tools cannot be set to Always allow at all: Microsoft Teams message sends, for instance, are limited to Ask or Blocked.

A popular myth says a connector gives the AI company your data. The record says otherwise: connector content retrieved for a chat is stored with that chat and deleted with it, is not used to train models under the commercial terms, and the credentials belong to the user, revocable in Claude or in the source system. The real risk is subtler: a connector reads what the person can read, and many organisations have never checked how much that is.

The Google Workspace connectors are three doors and a side door. Gmail lets Claude search, read, draft and, if allowed, send, reply and forward. Google Calendar lets it read events, find mutual free time and manage invitations. Google Drive lets it search and read files and, if allowed, upload, share, move and trash them. The side door is a set of separate connectors for Google Docs, Sheets and Slides that open the file in a pane beside the chat for live editing, while Drive still does the finding and sharing. Anthropic's guide is precise about what Claude can see: email text and attachment metadata but not attachment contents; text extracted from Docs, Sheets, Slides, PDFs, images and Office files, but not the images embedded inside a document; comments and suggestions in a Doc, but again no pictures.

The practical first use, and the one most pilots start with, is meeting preparation. A programme manager at a Melbourne university asks on Monday morning: "Prepare me for the 2pm with the faculty finance team." Claude reads the Calendar entry and its attendees, finds the agenda and the last two sets of minutes in Drive, scans Gmail for the thread with the finance director, and returns a one-page brief with open actions and three questions to ask. Four tool calls, nothing written, every claim cited. A Swedish municipality does the same for committee meetings; a London architecture practice does it for client calls with Drive and Calendar only, mail being out of scope for the first quarter.

On data protection, the European reading is simple: Claude processes the mailbox on the user's instruction under your existing Google terms and Anthropic's processor terms. Record it in the DPIA and move on.

The Microsoft 365 connector lets Claude search SharePoint, OneDrive, Outlook and Teams for the signed-in member, and, since write tools arrived on 7 July 2026, send mail, manage calendar events, create and update files and post Teams messages on their behalf. It is a different thing from Claude for Microsoft 365, the add-ins that put Claude inside Excel, PowerPoint, Word and Outlook; the add-ins work on the document in front of you, the connector reaches across the tenant. Both are in the Enterprise seat. The connector needs a Microsoft Entra tenant on a business plan; personal Microsoft accounts cannot use it.

The real risk is not the connector. It is oversharing in SharePoint, a problem Microsoft itself documented when Copilot arrived and answered with Restricted SharePoint Search in 2024. Fifteen years of sites created with Everyone except external users as the default visitor group means the member can already open the salary spreadsheet from 2019; a search tool merely makes it findable. Anthropic's guide is candid: SharePoint search covers the whole tenant and site-level restriction is not supported. Picture a 12,000-person NHS trust in England that discovers this in its pilot and spends the first month on SharePoint permissions, not on Claude; or a German manufacturer whose works council makes that review a condition of agreement under BetrVG §87, which is the right condition.

Claude does not open the drawer; it only tells you the drawer was never locked.

Beyond mail and files sit the systems where work is actually recorded: the CRM, the ticket queue, the project board, the wiki. Anthropic's connector directory now lists dozens of them, and the question for an organisation is not which are available but which to connect first, and in what state. The headline newcomer is Salesforce in Claude , the first product of the Claudeforce partnership, offered as a plugin with 37 pre-built sales skills (daily briefing, pipeline review, account plan, call prep, log activity) and announced for open beta in September 2026 after a pilot with selected customers. It reads live CRM data through Salesforce's own interfaces, writes only through Salesforce so business rules still apply, and respects the user's existing Salesforce permissions; an administrator can require Claude to check with the user before any email leaves the company.

Which first? Three tests, in order. Does the data matter to a measured use case from your pilot plan? Is the connector read-only enough to start, with write and delete tools on Blocked or Needs approval? Does the system's own permission model already match reality, or will the connector expose years of over-generous access, as SharePoint so often does? A Toronto software firm connected Jira first because engineering wanted sprint summaries and nothing needed writing. A Madrid retailer connected HubSpot read-only for the sales team and only enabled deal updates after two months of clean logs. A Nairobi microfinance lender connected Notion for its policy wiki and nothing else, because the loan system had no MCP door yet.

In the EU and the UK, a CRM connector touches customer personal data and belongs in the DPIA for the sales process; the GDPR's processor terms cover the CRM vendor and Anthropic's commercial terms cover the chat. In the US the question is usually contractual: whether the CRM licence permits automated access.

Sooner or later someone asks for the system with no pre-built connector: the policy administration platform, the clinical trial register, the forty-year-old ERP. The answer on Enterprise is a custom connector , a remote MCP server that exposes a handful of tools over that system. Anthropic's guide sets the mechanics plainly. An Owner, Primary Owner or a custom role that includes Manage access to Libraries adds it under Organization settings > Connectors > Add > Custom > Web, with a name, the server URL and an authentication choice: Sign in now, Sign in when needed, or No sign in. For sign-in, the OAuth client can be Claude's published identity (recommended), registered automatically, or your own. Fixed credentials can go in request headers instead, but then everyone shares one identity; prefer OAuth so each member connects as themselves.

Who owns it is the real question. The business owner states the use case and the data. The platform team builds or buys the server, hosts it behind your identity provider, and keeps a changelog of tools. Security reviews the tool list, the scopes requested and the egress path, and signs off the first version and every change. The Claude admin adds the connector, sets write tools to Needs approval or Blocked, and scopes it to a role. The member connects with their own sign-in. A Finnish energy utility runs exactly this for its asset register; a Texas hospital system for its bed-management board, with no write tools at all; a French ministry reviews against its national security agency's rules.

A custom server is a processor of your own making: in the EU it needs a record in the processing register and, for special-category data, a DPIA; in the US your sector rules apply unchanged, because the data never left your estate.

A connector policy is not one switch but a stack of five, and a request has to pass every layer before any data moves. Anthropic's own enterprise course describes the first three as gates. The organisation gate : an Owner or Primary Owner adds a connector to the tenancy; if it is not there, nobody sees it, whatever their role. The role gate : since 28 May 2026 custom roles decide which connectors, and which individual connector tools, each role may use, and with group-based roles from April 2026 the mapping can follow your SCIM groups. The member gate : the person must connect their own account; a granted connector nobody has connected is a door with no handle. Beneath those sit the per-tool policy and, last, the source system's own permissions, which Claude inherits and cannot exceed.

Each layer answers a different person's question. The security lead asks whether it can reach the system at all: the organisation gate. The department head asks whether analysts can use Jira but not the finance system: the role gate. The user asks whether it will send without telling them: the tool policy. The data owner asks whether it can read the restricted library: the source system, as always.

The myth to retire is that approval prompts are friction to be removed. They are the one moment a person sees what the agent is about to do in their name. Remove them for read, keep them for write, longest where the write reaches outside the organisation.

The open web is the one source nobody in your organisation controls, which is why it needs a habit rather than a policy. In Claude, web search is a capability an Owner or Primary Owner turns on under Organization settings > Capabilities; in the unified Claude there is no per-chat toggle, Claude searches when it judges that live information will help, and every answer that used the web carries citations. Give Claude a URL and it will fetch the page. Research goes further: from the plus menu a member starts a run in which Claude plans several searches, follows what it finds, and works through the open questions, drawing on the web and on any connectors enabled in the chat. Research runs on Opus 5.5, falling back to Opus 4.8, whatever model the chat selected, so a role with both Opus models switched off cannot use it at all.

When to allow it is a question of what you are protecting. A law firm in Frankfurt allows web search for every role because precedent lives on public sites, and keeps Research on for partners only. A defence contractor in Bristol keeps web search off for the engineering role and on for the bid team, a decision the custom roles page makes in a minute. A Brazilian university turns everything on and spends its effort on teaching the habit.

Mixing internal and external sources is where Claude earns its seat: a procurement officer in Auckland asks for the current regulatory position on a packaging rule and how the organisation's own policy compares, and gets both, the internal citations pointing to a project file and the external ones to a government site. Keep them visibly separate.

A skill is a folder. That is the whole trick, and it is why the idea has travelled so fast. Inside the folder sits a file called SKILL.md with a short YAML header giving the skill a name and a description, then a body of instructions in plain Markdown, and beside it whatever the job needs: scripts, templates, reference documents, a logo file. Anthropic introduced Agent Skills on 16 October 2025 and, on 18 December 2025, released the format as an open standard with a specification at agentskills.io, which Microsoft took up in VS Code and GitHub. Anyone who can write a checklist can write a skill.

How do we know what a skill does, rather than what the brochure says? Read the file. A skill is inspectable in a way a fine-tuned model never is: the instructions are text, the scripts are code, and a reviewer can read both before anyone provisions it. Anthropic's support article on skills is equally plain about the risk: a skill from an untrusted source can carry prompt injection or attempt to move data, so install only from sources you trust and audit the rest.

Two myths are worth retiring. Skills do not train the model; nothing in your folder changes Claude's weights, and your skill stays in your tenancy. And skills are not magic: a vague description means the skill never fires, a bloated one fires when it should not. Treat the folder like any other controlled document, with an owner, a version and a review date, and the rest of this part follows naturally. A skill is procedure you can read, which is the kind of AI an organisation can govern.

The first skill most organisations should write is the dull one: house style . Spelling (organise, not organize), date formats, how you refer to customers, which words you never use, the structure of a letter, where the logo goes and what the alt text says. It is dull because every piece of writing needs it and nobody enjoys enforcing it, which is exactly why a procedure that loads itself is worth having. Written well, it also doubles as the AI literacy exercise that article 4 of the EU AI Act has expected of deployers since 2 February 2025, because the people who write it have to say, precisely, what good looks like.

Then write the test cases before you finish the skill. Take ten real paragraphs, the sort residents actually receive about parking, bins and council tax, and write the version you would be proud of. Run each through Claude with the skill off and on, and read the difference. That is how you know the skill works: not a feeling, but a dated set of before-and-after pairs that a second person can repeat. Keep the pairs in the folder as resources; they are the skill's regression test when someone edits it in March.

Finally, decide what the skill is not for. It does not check facts, it does not sign anything off, and it should say so in its own body so that Claude never implies otherwise. A house-style skill makes every draft sound like you; whether the draft is true remains your job.

Once three departments have written skills, you have a management problem, and Anthropic has given it a page. Since org-wide skills management arrived on 18 December 2025, an Owner opens Organization settings, then Plugins & skills, and finds three tabs that carry the whole lifecycle: Policy, Inventory and Requests. Policy holds the switches; Inventory lists every skill and plugin the organisation governs, with source, version, audience and 30-day usage; Requests is the queue where members' submissions wait for review.

The decisions live in Policy. User-created skills can be on or off; when on, people on custom roles also need the Create skills capability. Publishing to the organisation library has three modes: Requires review, where an Owner approves each submission; Open, where anything publishes at once (behind the security scan, where that is on); and Off, which hides the Publish to org button. Enterprise organisations default to Requires review, though Anthropic has said that from 4 November 2026 organisations with scanning on will move to Open unless they have chosen a setting, so choose one. Two further toggles, Skill sharing and Share with groups, govern peer-to-peer sharing; shares are view-only, end when the recipient leaves, and appear in the audit log and Compliance API as role_assignment events, which is how you later prove who could use what.

Two cautions from the same guide. Admins see metadata, sharing status and scan results, not the contents of members' private skills, so governance is of the published layer. And if the Primary Owner applies the HIPAA configuration, Skills and User-created skills switch off until an Owner turns them back on, and skills are not covered by the BAA. The product gives you a catalogue, a queue and a version history; the judgement about what belongs in them is still yours.

A plugin is a box of skills with the rest of the kit packed in: slash commands, sub-agents, hooks that run at defined moments, and the MCP servers a workflow needs. Where a skill teaches one procedure, a plugin equips one role. Anthropic made this concrete on 24 February 2026, when the Cowork release for teams and enterprises added ten starter templates (HR, Design, Engineering, Operations, Brand voice by Tribe AI, Financial analysis, Investment banking, Equity research, Private equity and Wealth management) and partner-built plugins from Slack by Salesforce, LSEG, S&P Global, Apollo and Common Room. The same release introduced private, organisation-specific marketplaces and admin control over which connectors a plugin may bundle.

Each plugin then carries one of four states: Installed by default, Available to install (it shows on members' Discover tab), Not available, or Required, which installs for everyone and cannot be removed. On Enterprise, group overrides sit on top, and where a member is in several groups the most permissive setting wins, Required first and Not available last. The guide's own advice for a hard block is to set the organisation-wide state to Not available and grant only the groups that need it. How we know all this: the admin article is unusually precise, down to the case-sensitivity of GitHub organisation names in the strictKnownMarketplaces and blockedMarketplaces managed settings that allowlist or block Git-based marketplaces.

A skill is text and scripts someone else wrote, and a plugin can carry hooks and MCP servers that run on a colleague's laptop. That is the risk, plainly. The software world has learnt it the hard way: the event-stream npm package carried a wallet-draining payload in 2018, the SolarWinds build pipeline was poisoned in 2020, and in March 2024 an engineer named Andres Freund noticed a 500-millisecond delay in SSH and uncovered a backdoor in xz Utils. None of those were AI; all were trusted components. Skills and plugins join that supply chain with a twist: an instruction file can steer the model as well as the machine, and Anthropic's support pages warn about prompt injection from untrusted skills.

Read the exclusions as carefully as the feature. The scan does not cover items installed before it was switched on, skills created with Claude itself, skills arriving through a connected MCP server, or MCP servers at all; and organisations using customer-managed keys, zero data retention or the HIPAA configuration install without a scan. A Pass means no malice was found, not that the skill behaves as you hope. OWASP has begun an Agentic Skills Top 10 project with poor scanning on its list: a scanner is a floor, not a ceiling.

The law is catching up with the habit. The EU's Cyber Resilience Act, in force since 10 December 2024 with its main obligations from 11 December 2027, will make component provenance a legal question for products sold in Europe; the United States has asked federal suppliers for software bills of materials since Executive Order 14028 in 2021. The principle is the same everywhere and older than both: know what you run, and know who wrote it.

Three new doors opened in 2026 that produce things people edit rather than things they read once. Claude Design appeared as a research preview on 17 April 2026 and makes prototypes, mock-ups, microsites and decks from conversation; Claude Docs gives a live rich-text editor where you and Claude write in the same document; Claude Slides drafts a deck you present from Claude or download. Docs and Slides arrived in beta on 16 September 2026, and on Enterprise an Owner had to turn them on; Anthropic's admin guides now say they switch on by default for Enterprise from 15 October 2026 and that the separate, standalone Design site at claude.ai/design is planned to close on 14 December 2026 once everything lives in the main app.

Outputs leave the building, so know the formats. Design exports HTML bundles, PPTX, PDF and Google Slides; Docs export to Word, PDF, Markdown or Google Docs. On Team and Enterprise, Docs can be shared with people, groups or the whole organisation but not externally by link; viewers read, editors edit, and every change is attributed to the person or to Claude. Previews run in sandboxed iframes on a separate content domain with short-lived signed tokens, so removing someone's access takes effect at the next open.

The brand now lives in a file you own, extracted from assets you chose. Give that file an owner, as you gave the style skill one, and the designs, documents and decks stay yours.

Every rollout produces a library. Most libraries are graveyards: forty starter prompts written in week two, a Project per department nobody enters, three skills with the same name. The difference between a library people use and one they ignore is not the quality of the writing; it is naming, placement and measurement. Treat the library as a product with users, and give the product a dashboard.

Then measure, because Anthropic now lets you. The analytics update of 2 July 2026 reports, beside cost, what people actually produced: artifacts created, files edited, skills and connectors used, by SCIM group and by user, with skills reporting their own usage and cost and the Analytics API adding endpoints for plugin adoption. The Inventory tab shows 30-day usage per item. That is the honest measure. A 3,000-person Australian council we would call typical found after ninety days that two of its fourteen skills carried most of the use, both of them letter templates, and that the elaborate procurement skill had been used eleven times, by the person who wrote it. They retired six, merged three and promoted the two.

Three habits keep the library alive. Every entry has an owner and a review date, visible in the catalogue. New entries go through the Requests queue even where Publishing is Open, because a second reader catches the duplicate. And the quarterly review starts from the usage table, not from the wish list: the question is not what we should add, but what people reached for, and what they built themselves because we had not. Shared with you is where real demand shows first; the skills colleagues pass to each other are the ones worth promoting. A library is a measurement of what people need, published back to them.

The most valuable skills encode procedure in regulated work, and they are also the ones where a mistake has a regulator's name on it. A claims-handling checklist for an insurer, a clinical-letter template for a hospital, a clause playbook for a legal team: each is a document that already exists, often in a binder, and each becomes far more useful when Claude applies it to the case in front of someone. The design question is not whether to encode the procedure but where the human stays.

The approval step has to be real in two places. In the skill, the instructions say stop, present and wait; they never say send. In the tenancy, the permission that lets people skip approvals or automatically approve connector tools stays off for these roles, so a skill cannot be combined with a mail connector into a send. The EU AI Act makes this more than taste: article 14 requires effective human oversight for high-risk systems, and Annex III lists life and health insurance risk assessment and pricing among them, with the high-risk timetable phased in from 2026 and still being adjusted in Brussels. US rules are sectoral, HIPAA for health and state insurance regulators for claims; the human-in-the-loop principle is the same.

Encode the checklist by all means; it is the best use of the technology this book describes. Keep the signature.

Skills rot. The style guide changes, the claims form gains a field, the connector gets renamed, and the skill that was right in January quietly makes everyone slightly wrong by June. Nothing in the product stops that; what the product gives you is a version history, a usage count and a way to make a skill disappear gracefully. The rest is ownership, which is a rota, not a feeling.

The cadence should match the risk. A house-style skill can live on a six-month review; a claims skill tied to a regulated process follows the procedure's own review date; a skill that wraps a connector is reviewed whenever that connector changes. ISO/IEC 42001, the AI management system standard Anthropic itself certified against in January 2025, expects an organisation to manage its AI resources through their lifecycle with defined responsibilities, and the NIST AI Risk Management Framework's Manage function says the same in American. A catalogue entry with an owner, a version, a review date and a usage figure satisfies both auditors and, more usefully, the colleague who inherits the skill when the owner moves on.

Two product details make retirement safe. Removing a provisioned skill takes it out of members' lists but leaves the version history, so a mistaken retirement is reversible. And because reviewers approve versions rather than authors, a departing owner's private edits never reach anyone; handover is a matter of reassigning the name in the catalogue and the review date in the calendar. Own the file, measure the use, and let the dead ones go.

By the end of year one a mid-sized organisation has around thirty skills that matter, and the Inventory tab, however good, is a list of files. A skills catalogue is that list turned into a document people and auditors can read: for each skill, its category, its owner, its risk level, the data it touches, its audience and its adoption. The Inventory stays the source of truth for versions and states; the catalogue adds the judgement the product cannot hold.

Consider an illustrative 4,000-person insurer's catalogue: thirty skills, five pillars, one catalogue owner, the AI lead who chairs the review. Writing and style holds the house-style skill, the plain-English letter, the French and German letter variants, a complaints reply and a social-media voice. Analysis holds a board pack, KPI commentary, variance explanation, survey summary, meeting notes and chart style. Regulated procedure holds the claims checklist, the underwriting referral, the clause playbook, the DPIA drafting aid, the sanctions-screening summary and complaints root cause, all marked high, all with a human approval line. Engineering holds code-review conventions, the incident write-up, the runbook format, API documentation style, the test plan and the data-pipeline checklist, most of them synced into Claude Code. Administration holds onboarding, expenses, travel, HR…

A catalogue is what turns thirty clever folders into a system you can explain to a regulator, a works council, a new joiner and yourself on a bad day. The product gives you the inventory; the catalogue is the organisation saying what it meant by it.

On 23 October 2026 Anthropic made the unified Claude experience generally available on the Enterprise plan, after Pro and Max had it from September. The idea is simple to state and took most of a year to build: there is no longer a choice between chat and Cowork. Every conversation starts as a chat. When the task needs code, files or a browser, Claude continues in an isolated cloud sandbox managed by Anthropic, does the work, and comes back with a document, an analysis or a deck. Close the laptop and the work carries on. Projects, connectors, skills and plugins carry over unchanged.

The date that matters for you is 16 November 2026. The experience is off by default in organisations that existed before launch, and on that day it turns on by itself unless an Owner or Primary Owner has chosen Keep disabled. The notice in the console says so in plain words, with Enable now beside it. If Chat or cloud code execution is off, nothing changes automatically. An existing choice, either way, is preserved. A 4,000-person insurer that does nothing will wake up on 17 November with agentic work switched on for everyone whose role allows it. That is not a disaster, but it should be a decision.

Anthropic's own recommended rollout is the sensible one, and this part follows it: involve IT, security and procurement; finish the security review, which for most teams means reviewing chat and Cowork in the cloud, since a review already in progress carries over; pilot with one role, assigned through SCIM in waves; check egress, connector, sharing and remote control settings before enabling; monitor for two to four weeks; then expand. Chapters 62 to 70 take those settings one at a time. The unified Claude is not so much a new product as a new default, and defaults are where organisations are quietly governed.

When a conversation crosses into agentic work it lands in a sandbox : an isolated, temporary virtual machine on Anthropic-managed infrastructure, created for that session and destroyed when the session ends. Anthropic's Claude Cowork architecture overview on support.claude.com describes it plainly, and it is the document your security team should read first. Each session gets its own VM. Sandboxes share no state with each other or across organisations. The infrastructure is kept separate from Anthropic's corporate, research and model-training environments, which answers the first question every CISO asks.

The third question is credentials, and here the design is the most reassuring part. The sandbox holds only session-scoped tokens that expire within hours. Connector authorisation tokens never enter it: when Claude calls Google Drive or Salesforce from inside a session, the call runs server-side, outside the VM, against the policy you set in Part Four. A prompt injection that persuades the agent to print its secrets finds nothing worth printing. Local files and the browser are reached through the Claude Desktop app over an Anthropic-brokered connection, limited to folders the member has connected, with each tool call checked against the member's permissions; if the desktop app is offline, the session cannot touch the device.

There is also a local mode , used by existing desktop deployments and by tasks created before 6 October 2026. The agent loop runs on the device; code runs in a Linux VM separated from the host by the platform hypervisor, Apple's Virtualization.framework on macOS and Hyper-V on Windows, with its own egress filtering, syscall restrictions and per-session user isolation. If that VM fails, file and web tools continue while shell commands report "workspace unavailable". Either way the rule is the same: the sandbox is where work happens, and the walls are the point.

Every byte that leaves a cloud session passes through one proxy, and one setting decides what the proxy lets through. Allow network egress sits under Capabilities, Code execution, and has four levels: off, package managers only, a custom domain list, and all domains. For Enterprise organisations the default is off. Whatever you pick, the proxy still blocks private, internal, link-local and cloud-metadata addresses, so the choice is about the public internet, not your intranet. The same setting governs local Cowork and chat, and the unified-experience guide lists it first among the settings to review before enabling anything.

So who should have what? Treat the four levels as roles, not as an organisation-wide choice, because custom roles can carry different capability settings. A 4,000-person insurer might give the analysts who build models package managers only, which lets a session install a Python library from the standard registries and nothing more. A marketing team that needs the company's own CMS and a stock-image supplier gets a custom list of three domains. A research group at a Dutch university asks for all domains to crawl the open web; the sensible answer is a custom list that grows on request, plus the Research feature in chat, which was built for the open web and runs outside the sandbox.

A note for the EU and the UK. A data protection impact assessment under the GDPR asks where personal data can travel; an egress setting of off makes that answer short, and a custom list makes it enumerable, which a German works council or a French CNIL reviewer will appreciate far more than a promise. Egress is the setting you tighten first and loosen last.

An agent is only as safe as the moment it reaches for a tool. In the unified Claude that moment is permission-gated : when a session wants to use a connector tool, edit a file, run a command or browse, it either asks the member or acts under a standing grant. Anthropic's admin guide lists three organisation-level switches that shape this, and the names are worth learning exactly. Always allow for connector tools: when off, members cannot grant a standing approval and Claude asks every time. Allow "Skip all approvals" mode : when off, users cannot let Claude act without approval at all, and the restriction applies to scheduled tasks and the built-in browser too. Allow "Automatically approve" mode : when off, users must approve each action, including tool use, file edits and browsing.

Where should humans stay in the loop? The practical rule is to classify tools, not tasks. Reads are cheap to approve once: calendar, Drive search, a Jira query. Writes to a system of record deserve a click: a Salesforce update, a Confluence edit, a Git push. Sends and payments deserve a click every time; Claude for Outlook enforces this itself, since a draft opens in the compose pane and nothing goes until the member presses send. A 4,000-person insurer gave its claims handlers Always allow for reads and manual approval for every write, and found the write prompts rare enough that nobody complained; its finance team keeps Skip all approvals disabled.

Set the three switches deliberately, write the tool classification into the AI policy of Part Nine. The agent should ask when the answer matters and not otherwise; that is the whole art.

A scheduled task is a prompt that runs itself. The member writes the instructions once, picks a cadence, and Claude runs them as a fresh Cowork session each time, with the member's connectors, skills and installed plugins available. The support article on recurring tasks lists the cadences: hourly, daily, weekly, on weekdays, or manual. Most tasks run remotely, on schedule, while the laptop is asleep or the desktop app is closed. A task that needs local files or local applications runs only on the member's computer, which is where the Remote control setting of Chapter 66 comes in. Upcoming and past runs appear in a Scheduled section of the sidebar.

How do we know what a task can and cannot do? The support article is clear on cadence and on where runs happen; it is silent on what a failed run reports, how many tasks a member may hold and how long run history is kept. Treat those silences as pilot questions: break a task's connector deliberately once and record what the member sees. The unified-experience guide adds the fact that matters most to a compliance lead: scheduled tasks and their runs are not covered by custom data retention. They continue after the source conversation is deleted, and the only way to stop them is the organisation-wide Scheduled tasks switch, which when off disables remote tasks and prevents new cloud tasks being created.

A good scheduled task is a small, boring contract: these inputs, this cadence, this output, this person reads it. Keep a list of them. The organisation that knows what runs at 06:00 on its behalf is the one that can answer the auditor, and the one that can switch it off.

Remote Control lets a member continue a Claude Code session that is running on their own computer from a phone, a tablet or any browser. The execution and the files stay on the machine; the conversation travels. Anthropic's documentation describes the plumbing: the local session makes outbound HTTPS requests only and never opens an inbound port, it registers with the Anthropic API and polls for work, and when a device connects the server routes messages between the two over a streaming connection using several short-lived credentials, each scoped to one purpose. While connected, the transcript is stored on Anthropic's servers so devices stay in sync.

The second half of the title is the control that makes the first half acceptable. Trusted Devices , in beta and off by default, requires each member to verify a device before it can view or steer a remote session. Two things must be true at once: the browser, phone or desktop app has enrolled its own credential, and the member's sign-in is no more than 18 hours old, refreshed by Face ID, Touch ID, Windows Hello or a passkey rather than a password. Anthropic stores only the device's public key and metadata, never biometrics. An Owner turns it on under Organization settings, Capabilities, Remote sessions, with the toggle Require trusted devices; it applies to every member and to sessions started after that moment, with no per-team scope. Members manage their enrolled devices on their account page; for a lost phone, an admin's Sign out everywhere revokes every session and every enrolment…

How do we know? From the Remote Control page in the Claude Code documentation and the unified-experience guide, which carry the exact names; device verification dates from June 2026 and is still beta, so check before writing policy. Remote Control is a convenience. Trusted Devices is what lets a careful organisation say yes to it.

Claude in Chrome is a browser extension that lets Claude act in the member's browser: open pages, read them, click, scroll and fill forms, in a side panel. Anthropic opened a pilot in August 2025 and added organisation controls in December 2025. It is the surface that reaches the applications nobody built an API for: a council's planning portal, a supplier's ordering site, the expenses system from 2011. It is also the surface most exposed to the open web.

The risk the lists cannot fully remove is prompt injection : text on a web page that tries to instruct the agent. How do we know how bad it is? Anthropic published numbers. In November 2025 it reported that an adaptive attacker with 100 attempts per environment succeeded 7.6 per cent of the time against the launch safeguards with Opus 4.5 and 1.4 per cent after improved training and classifiers; the current safety article cites internal testing with a later model at under 0.08 per cent and adds, carefully, that this is not zero. Two classifiers run: one screens incoming content, one checks each action before it runs; flagged actions are blocked or paused for approval. Claude also asks before financial sites, confirms downloads and sensitive entries, and will not trade stocks or solve captchas.

The published numbers say the defences are good and imperfect. Allowlist first, approve by hand on new sites, and give the capability only to roles whose work it clearly serves.

There have been two Claudes in Slack. The first, from 8 December 2025, let a member tag Claude to start a Claude Code session: context from the thread was pulled in and the thread ended with a link to the session and a pull request. The second, Claude Tag , announced on 23 June 2026 and still in public beta on Team and Enterprise, replaces the earlier app and widens the idea to any work. Anyone in a channel can tag Claude; it posts a checklist in the thread as it goes, and the whole exchange stays visible to the channel. Fix a bug, turn a decision thread into a document, watch a dashboard.

Who can see results? Everyone in the channel, which is the point and the risk. A connector's credential is shared by every member of the channels where it applies, so Anthropic's advice is to connect a dedicated identity per service, such as a claude@ mailbox or a native service account, never a personal login, and to keep sensitive credentials, finance for instance, attached to one private channel. A Slack Connect channel exposes its attached credentials to the other company's people, so check before sharing. Money is per usage from an organisation balance under a spend limit, not per seat, with a per-channel breakdown on the usage page, and an Owner can restrict use to roles that hold the Claude Tag in Slack capability.

Claude in Slack is a colleague with its own badge, its own keys and a very public desk. Configure it once, scope its keys narrowly, and remember that a channel is an audience.

Most of an organisation's numbers live in Excel and most of its decisions are presented in PowerPoint. Claude for Excel opened as a beta on 24 November 2025; on 7 May 2026 Anthropic made Excel, PowerPoint and Word generally available on paid plans and put Outlook into public beta. Each is a sidebar inside the Microsoft application, and one conversation can span an open workbook, a deck, a document and the inbox. Change an assumption in the model and, with the files open side by side, the linked chart in the deck and the figure in the memo follow.

Checking the numbers is the practice that decides whether this is a gain or a liability. Anthropic's own documentation says the add-in is not recommended for final client deliverables without human review, for audit-critical calculations without verification, or for highly sensitive data without proper controls. The useful discipline is three steps: ask Claude to walk through the figure and click every citation, recompute the workbook, and have a second person read the assumptions. Note too the prompt-injection warning in the Excel documentation: a downloaded template or a vendor's spreadsheet can carry hidden instructions, and Anthropic's testing found it could be manipulated if allowed to act unverified. Use trusted workbooks, confirm risky operations.

The office add-ins are agents in the rooms where decisions are actually made. Verify like an auditor, deploy like an admin, and remember that the person who clicks send is still the person who sent it.

Security teams have built a decade of confidence on the endpoint. Endpoint detection and response agents watch every process on every laptop, and a SOC expects to see what runs. Anthropic's architecture overview says, in one sentence, why Cowork breaks that expectation: "The VM is isolated from host-based security tools by design." The local Linux VM is invisible to the EDR on the host, and a cloud session runs on Anthropic's infrastructure, outside your endpoints entirely. The article adds: if your compliance posture depends on endpoint visibility, account for this before rolling out.

Identity first. SSO and SCIM from Part Three decide who has a seat; custom roles decide who has the unified experience, cloud sessions, Chrome and Remote Control; Trusted Devices ties remote access to an enrolled device and an 18-hour-fresh sign-in; tenant restrictions keep personal Claude accounts off the corporate network. Policy second. Network egress off or enumerated, connector policies of Blocked and Needs approval with per-tool scope, the three approval switches, the Chrome allowlist, and the MDM keys that disable local MCP servers and desktop extensions. None needs to see inside the VM; all shape what it can do.

Response last: a named owner, the Sign out everywhere button, the Scheduled tasks switch and the egress setting, each of which can stop a session's reach in minutes. Regulators have moved in the same direction. The EU's NIS2 directive asks for risk-management measures, not particular sensors; the NIST Cybersecurity Framework speaks of identify, protect, detect and respond, not of any one agent on a laptop. The myth to retire is that the EDR saw everything before; it never saw inside a browser tab or a SaaS tenant either. The sandbox is a blind spot with four walls around it, and walls you can inspect are better than a camera you cannot.

Every Claude Enterprise seat now carries Claude Code : the terminal tool, the IDE extensions, the web version that runs in a cloud sandbox, and the Slack entry point. Anthropic released it as a research preview in February 2025, made it generally available in May 2025, added premium Claude Code seats for Team and Enterprise that August, and put it on the web in October 2025; since 16 January 2026 even standard Team seats include it. The sister volume, Claude Code: The Ultimate Guide 2026 , covers what a developer does with it hour by hour. This part covers the organisation around the developer: who gets it when, what is locked, what is measured, and who signs off a merge.

A staged pattern works. Wave zero is the platform or developer-experience team, five to ten people who will write the managed settings (chapter 72), the repository CLAUDE.md files and the review rules (chapter 75). Wave one is two or three product teams that asked, with a named lead each, for four weeks. Wave two is every team that wants it, provisioned through SCIM groups so that joining a group is joining the rollout. The last wave is the long tail of people who did not ask, who need a champion more than a licence. A 4,000-person insurer in Zurich ran exactly this shape across a quarter; a 60-person SaaS firm in Austin did it in a fortnight with the same four steps, because the steps are about trust, not size.

What it means now: treat the rollout as a change programme with a product in it. Name the waves, the dates and the people, write down what each wave must show before the next starts, and let the audit log rather than enthusiasm tell you when to open the gate.

Claude Code reads its configuration from a stack of sources, and the one that matters to an administrator is the top layer, called managed settings . Anthropic's settings documentation at code.claude.com lists the order: user settings in the home directory, project settings committed to the repository, local project settings, command-line arguments, and above them all the managed tier, which no lower layer and no flag can override. Whatever you put there is simply true on that machine, in that session. That is the whole point.

What goes in the tier is a short list of things you genuinely want fixed. Permission rules: a deny list such as reading .env files or running curl , with allowManagedPermissionRulesOnly so users cannot widen it, and disableBypassPermissionsMode so nobody runs with permissions off. MCP control: allowedMcpServers and deniedMcpServers , matched by URL or exact command rather than by a name a user can choose, and allowManagedMcpServersOnly to lock the list; a standalone managed-mcp.json , MDM-only, takes exclusive control or disables MCP entirely with an empty map. Hooks, which run your audit script after every edit, though users see a security approval dialogue before a hook delivered from the server applies. And forceRemoteSettingsRefresh , which makes the client exit rather than start without policy if it cannot reach Anthropic.

Lock what matters, leave the rest to the developer, and remember that a setting nobody can see enforced is a setting that does not exist.

Coding is the heaviest thing anyone does with a Claude seat. A chat question is a few thousand tokens; an afternoon of agentic refactoring across a monorepo is millions, and because Enterprise usage is billed at API rates on top of the seat, engineering is where the usage line of the invoice is written. The temptation is to treat the biggest numbers as a problem. Often they are the point.

Now read the distribution rather than the total. In every engineering rollout the spend curve has a long tail, and the tail contains three different people. The first is the builder: a senior engineer who has moved real work onto the tool and whose cost per merged pull request, visible on the Value tab (chapter 77), is lower than the team average. The second is the runaway: a session that has been retrying a failing test suite for two hours, a scheduled task nobody cancelled, or a background agent looping on a flaky build. The third is the idle seat, which costs the seat fee and nothing else and is a different conversation. The same number at the top of the chart means opposite things, and only the session list tells you which.

What is in your control is the shape of the budget and the attention you pay to its tail. Cap the organisation, pool the teams, alert early, and never punish the best users for being the best.

On 20 February 2026 Anthropic announced Claude Code Security , at first as a limited research preview for Enterprise and Team customers with priority for open-source maintainers, and by October 2026 listed on the Enterprise page simply as Claude Security, part of every seat. It scans a codebase for vulnerabilities, assigns each finding a severity and a confidence score, runs its own layered verification to cut false positives, and drafts a targeted patch for a human to review. Nothing is changed until someone accepts it. How we know: Anthropic's launch post and the product page, which also said that the model behind the preview had already found hundreds of previously unreported vulnerabilities in open-source projects.

So pair, do not replace. Keep the SAST tool in the pipeline for the rule-shaped bugs and the compliance evidence; run Claude Security on the logic-shaped ones and on the triage of what the first tool found. Route findings into the same tracker, with the same severity vocabulary, ideally the CWE identifiers and the OWASP Top Ten categories your auditors already recognise. A patch drafted by Claude goes through the same pull-request path as any other change (chapter 75), with the AI-assisted label on it. If a finding is a true positive in production code, your incident process, not the tool, decides whether it is a vulnerability disclosure.

The tool finds and drafts. Your engineers decide, and your records show they did.

The rule fits on one line: a human approves every merge, and the human is accountable for it. Everything else in this chapter is machinery to make that line hold when a large share of the diff was typed by a model. The machinery is familiar, because the industry built it for human authors who were also fallible: branch protection, required reviews, required status checks, code owners, and a label that says what the change is.

Then the gates. Branch protection on the default branch with at least one approving review from someone other than the author, and no exceptions for bots. Required checks: the test suite, the SAST scan, and whatever Claude Security (chapter 74) raised as high severity. A CODEOWNERS file so that a model-written change to the payments module is seen by someone who owns payments. A rule that a reviewer who asked Claude to write the code is not the reviewer who approves it, which is the same rule you already have for pairing. For background agents (chapter 76), the person who triggered the run is the author of record.

A Stockholm payments firm requires two reviews on any AI-assisted change touching money and one elsewhere; a Melbourne university lab requires none for notebooks and all of the above for the production pipeline. Both wrote it down. Decide the rule, automate the gate, and let the four keys tell you whether the model is helping.

A developer at a keyboard is one kind of Claude Code user. The other kind has no keyboard: a session started from the web and left to run, a GitHub Actions job that wakes when someone writes a mention in a pull request, a scheduled task that opens a fix at six in the morning. These are background agents , and they change two things for the organisation: where the code runs, and whose name is on the result.

GitHub Actions is the other common home. Anthropic's action runs Claude Code inside a workflow in response to a mention; it needs a credential, and the right credential is not a long-lived API key pasted into repository secrets but a short-lived token from Workload Identity Federation (chapter 79), which GitHub's OIDC issuer supports. Independent security researchers have noted that the action imposes no network restriction of its own, that the agent installs packages it chose, and that the runner therefore needs the same hardening as any other job that executes code. Treat it as a build step, because it is one.

Let the machine run while you sleep, with the keys locked in a box it cannot open, and a human name on everything it hands back.

On 2 July 2026 Anthropic's post on giving admins more visibility over Claude spend added two tabs to the Claude Code section of the admin console. Usage shows active developers, sessions, top commands, lines of code accepted, the suggestion accept rate and, per member, an email address beside a monthly count. Value takes the same data plus cost and produces three estimates: productivity lift, cost per commit and estimated annual value. Every formula is shown inline and every input can be changed. How we know: the post itself, the support article on Claude Code usage analytics, and the Claude Code Analytics API, which hands the same daily figures to whatever you prefer to chart with.

Read the Value tab as a model, which is what it is. A productivity lift estimate rests on an assumption about how much time each accepted line or each session saved; an annual value rests on that and on a loaded salary figure. Anthropic shows the formula and lets you change the inputs, which is more honest than most vendor dashboards, and it means the number on the screen is partly your number. Put your own assumptions in, write them down, and present the result as a range. If the committee wants one figure, give the lower end and the formula.

The Usage tab tells you what happened. The Value tab tells you what you assumed. Keep the two apart in your own head and in every slide.

The best test of an engineering rollout is a stranger. A new hire has no habits to unlearn and no idea which of your rules are real, so the path you give them on day one is the path the tool will actually be used on. Design it as a path, with a start, a few stops and a finish line you can measure: time to first merged pull request with Claude Code in the loop.

Afternoon. A small, real task, chosen by the mentor from the backlog: a bug with a failing test attached, or a documented refactor. The engineer asks Claude to plan before it edits, reads the plan, lets it work, runs the tests, and opens a pull request with the AI-assisted label (chapter 75). The mentor reviews it that day. The point is not the fix; it is that the new person has seen the whole loop, including the part where a human says no to something the model proposed.

A Lisbon bank's platform team cut its median time to first merged pull request for new engineers from eleven working days to four after adding CLAUDE.md files to its twenty core repositories; a US federal contractor measured the same thing and found the bottleneck was approval queues, not the tool. Either answer is useful, which is the argument for measuring at all.

A seat is for a person. Beside the seats stands the Claude Developer Platform , the API and the tooling for software that calls Claude without a person at the keyboard: the chatbot on the website, the pipeline that classifies tickets, the agent that reconciles invoices overnight. It is bought by the token, administered in the Console at platform.claude.com rather than in the claude.ai admin settings, and it is the subject of the sister volume Agents in Production . The question here is only when an organisation that owns seats should also build on it.

How we know is the platform documentation itself, which also lists the identity objects: a service account that is the non-human principal, a federation issuer per environment, and a federation rule mapping token claims to the account and a scope. The practical effect is that the question security asked in chapter 76, where does the key live, has a boring answer: nowhere.

Seats put judgement beside a person. The platform puts a model inside a system. Know which one you are buying, and give each its own keys.

Every engineering leader with an Enterprise contract hears the same request several times a month: can we have Claude do X. The answer is one of four, and the mistake is to default to the most interesting one. Use the seat as it ships. Configure it with a skill, a plugin, a project or a connector. Build on the platform. Or wait , because Anthropic has announced it. The quadrant on the plate puts those four answers on two axes: how specific the need is to your organisation, and how settled it is, meaning both whether the requirement is stable and whether the product already covers it.

Bottom-right is build. The need is specific, stable, high-volume and must run without a person in the loop: inside your product, at scale, in your own systems. That is the platform (chapter 79), with its own identity, budget, evaluation suite and on-call. Build only when the use-and-configure answers have been tried and found wanting, and only with the evidence from a pilot (chapter 13) that the volume is real. A build that would have been a skill is the most expensive mistake in this book.

A Copenhagen pension fund wanted a bespoke agent to answer member queries; the pilot showed the queries were generic and the answer was a project with the policy documents in it. A Singapore logistics firm wanted the same tool to reroute shipments overnight at scale; that one was a build, and it was budgeted as software. Decide which cell you are in, write the cell on the ticket, and keep the judgement with people.

A champion network is the cheapest and most reliable part of an Enterprise rollout, and the one most often skipped. The idea is old: pick one person in every team of 25 to 50 who already likes the tool, give them a little time, a shared channel and a direct line to the people who run the platform, and let them teach by example. Nobody learns to use Claude from a slide deck. They learn from the colleague two desks away who shows them how a Project with the team's templates in it saves an hour on Monday.

The roles in the network matter more than the title. At the root sits the AI lead, who owns the use-case inventory and the feedback loop. Under them, champions cluster by function: a finance champion who maintains the close-commentary Skill, a legal champion who owns the contract playbook, an operations champion who turns casework into templates, a sales champion who knows which CRM connector is approved. Each champion holds office hours, 30 minutes a week, and posts one worked example a fortnight in the shared channel. A German manufacturer we worked with added a works council member to the network from day one, which turned a potential veto into a co-author.

The network is also your early-warning system. Champions hear the complaint before the audit log shows it: the connector that asks for approval too often, the Skill that drifted, the model default that feels slow in Efficient mode. Route that upward every fortnight and the platform team stops guessing. A rollout without champions is a licence purchase; with them it becomes a habit.

Since 2 February 2025, Article 4 of the EU AI Act has required providers and deployers of AI systems to take measures to ensure a sufficient level of AI literacy among their staff and anyone operating AI on their behalf, taking account of their technical knowledge, context and the people affected. It is the earliest obligation in the Act to apply and the vaguest. The European Commission's own Q&A says there is no prescribed course, no certificate and no fixed number of hours; what counts is that the training fits the role and the risk. If your organisation has staff in the EU, or serves people there, you are a deployer the moment a Claude seat is used for work.

A practical curriculum has four tiers. Everyone gets 45 minutes: what Claude Enterprise is, what it is not, that inputs are not used for training under the commercial terms, what a Project and a connector are, and how to verify a claim before it leaves the building. Regular users get a role-based session, two hours, built on their own documents: a finance analyst learns the Excel patterns, a lawyer the clause-review flow, a caseworker the plain-English letter. Power users and champions get a half day on Skills, Projects and the unified Claude's sandbox. Admins and the security team learn the console, roles, connector policies and the audit log, ideally before the first wave rather than after the first incident.

The honest measure of literacy is not attendance. It is whether people catch errors. Sample outputs monthly, count the corrections, and watch the trend. A workforce that can say "I checked" is the only compliance evidence that survives contact with a regulator.

Lawyers were the first profession to be publicly embarrassed by a language model and are now among its most careful users. In Mata v. Avianca in June 2023, Judge P. Kevin Castel of the Southern District of New York sanctioned two lawyers who had filed a brief containing six cases that did not exist, invented by a chatbot. In June 2025 the High Court of England and Wales, in Ayinde v London Borough of Haringey , warned the profession in plain terms after fictitious citations appeared in two unrelated cases. Neither court banned the tools. Both said the duty to verify is the lawyer's and cannot be delegated.

The clause-review playbook is the workhorse. A Skill holds the firm's or the department's positions: preferred limitation of liability, acceptable governing law, the indemnity language the board approved in 2024, the data-protection terms required under Article 28 of the GDPR. Claude reads an incoming contract, marks each clause as standard, negotiable or escalate, drafts the fallback wording and lists what it could not assess. A 4,000-person insurer we know of runs supplier agreements through this flow and reports that the first-pass review time fell from days to hours; the lawyers still read every escalated clause, and the Skill is updated when a position changes.