Signing Up for Claude Enterprise: The Configuration Decisions That Matter cover
October 7, 2026

Signing Up for Claude Enterprise: The Configuration Decisions That Matter

Listen to this article
Claude Enterprise: Security, Governance & Configuration

7 Oct, 2026 Lana Hampicke

Your Claude Enterprise contract sets what is possible. Your admin console sets what actually happens. Several defaults are permissive by design (data kept indefinitely, Cowork on, "Automatically approve" mode allowed), so the risk posture you sign up for is decided in the first two weeks of configuration, not at signature.

This article is written for the COO, CTO or CDO who signs off the rollout. It covers the eight configuration areas that matter most, what the defaults are as of October 2026, and what a regulated firm should set before the first 100 users log in. Anthropic ships admin changes monthly, so treat every default below as something to re-check on the day you configure.

1. Claude Enterprise identity and access: close the side doors first

The biggest early risk is not the enterprise workspace. It is the personal and Team accounts your staff already opened with corporate email addresses. Fix identity before anything else.

  1. SSO (SAML 2.0 or OIDC), enforced. Pilot with one group, then make SSO mandatory for both Claude and the Anthropic Console, so API keys cannot be created outside your identity controls.
  2. Verified domains and domain capture. Verify every corporate domain, then use domain capture to route sign-ups into your workspace. Use the claim and migrate process to pull existing accounts on your domain under management, and turn on "restrict org creation" so nobody spins up a parallel workspace.
  3. SCIM over JIT. JIT provisioning creates users on first login but does not remove them. SCIM ties joiners, movers and leavers to your IdP, which is the control your auditors will test.
  4. Few owners, named admins. Roles run Primary Owner, Owner, Admin, Member, plus custom roles. A practical baseline is 3 to 5 Owners with a documented reason each, and an admin list reviewed quarterly.
  5. Network controls. IP allowlisting and tenant restrictions stop staff reaching personal Claude accounts from the corporate network, which is how you make the enterprise workspace the only path.

Board question this answers: "Can a leaver still use Claude with our data tomorrow morning?"

2. Data controls: retention is a decision, not a default

By default,Claude Enterprise chats and projects are kept indefinitely unless you set a custom period. That default rarely matches a firm's records policy.

  1. Set custom retention deliberately. The minimum is 30 days. Deletion is permanent and runs at midnight UTC. Chats moved into a project follow the project's period.
  2. Know what retention does not cover. Claude Design, Claude Tag, Claude Managed Agents and Claude Code on the web sit outside these retention policies. Local Cowork session history on a user's machine is not centrally managed or deletable by admins. Content flagged by trust and safety systems is retained separately by Anthropic.
  3. Resolve the tension with legal hold. Short retention reduces breach and disclosure exposure; long retention preserves the only conversation-level record for investigations. Decide with Legal and Compliance, then route the record you need through the Compliance API into your own archive (section 6) rather than relying on in-product retention.
  4. Training. Prompts, data and outputs are not used to train models by default. Check two leaks around the edge: the user feedback setting (thumbs up or down sends the conversation to Anthropic) and "rate chats". Many regulated firms disable both.
  5. Encryption and residency. Customer-managed encryption keys and a US-only inference option are available on Enterprise. For UK and EU firms, first-party Claude Enterprise does not offer an EU-only processing guarantee as of this writing; regional processing is offered through AWS Bedrock and Google Vertex AI. Settle this in your DPA and transfer risk assessment before go-live, not after.
  6. HIPAA. A HIPAA-ready configuration with a BAA exists; note it changes some defaults (for example, Cowork starts off).

3. Connectors and MCP: this is where your data actually moves

Connectors give Claude live access to email, files, chat, CRM and code. Each one inherits the user's own permissions, so an over-shared SharePoint becomes an over-shared Claude. Anthropic reviews directory connectors against listing criteria but does not security-audit or manage any MCP server.

  1. Tier connectors by data sensitivity. High: Microsoft 365, Gmail and Drive, Slack, Teams, Salesforce, GitHub and GitLab (personal data, client communications, source code and secrets). Medium: Atlassian, Notion, Asana (architecture, roadmaps, vulnerabilities). Enable high-tier connectors only for named groups with a documented business reason.
  2. Separate read from write. Interactive connectors can send, post and edit. "Always allow" for connector tools is off by default; keep it that way so a person approves each write action.
  3. Clean permissions before you connect. Run a sharing and access review on SharePoint, Drive and Slack first. Claude will surface whatever a user can technically open.
  4. Lock MCP for developers. In Claude Code, use managed settings with allowedMcpServers plus allowManagedMcpServersOnly: true, or a fixed managed-mcp.json deployed by MDM. Match on serverUrl or serverCommand, never serverName, which a user can set to anything.
  5. Govern skills and plugins like code. Skills can carry instructions and scripts. Start with org-wide sharing and user-created skills restricted, and put new skills through the same review as any internal tool.
  6. Disable "share via connectors" unless you have a clear use case, so connector-sourced content is not pushed onward by default.

4. Agentic features: decide how much autonomy you are buying

Claude Enterprise is no longer only a chat window. It runs code, browses, acts on desktops and works in the background. Each capability has its own switch and its own default, and several are on unless you turn them off.

Cowork (agentic desktop work) On Who gets it, and which local folders it may touch
“Automatically approve” mode Allowed by default Whether users may let Claude act without per-step approval
Cloud sessions Off; enabled via custom roles Which roles may run unattended background work
Built-in browser Turned on 10 Sept 2026 unless disabled Whether agents may sign in to and act on websites
Code execution and network egress Configurable; egress can be limited to package managers or an allowlist Whether sandboxed code may reach the internet
Claude Code bypass and auto permission modes Configurable via managed settings Keep disableBypassPermissionsMode on for most users

Three principles hold across all of them:

  1. Treat autonomy as a role entitlement. Grant it to trained groups, not the whole firm.
  2. Prefer egress allowlists or strong monitoring over open internet access. Prompt injection through a web page or document is the main exfiltration route.
  3. For Claude Code, block reads of .env, keys and credential files in managed settings, and use forceRemoteSettingsRefresh so controls fail closed.

Interactive content that renders external images is a known exfiltration vector; several security teams disable it.

5. Sharing, projects, artifacts and memory

Collaboration features are where internal content quietly becomes external. Artifacts are hosted web pages with their own link, and projects can be shared widely.

  1. Public projects and external artifact sharing: disable unless there is a business case. Internal sharing of chats and projects is usually fine and helps adoption.
  2. Project visibility: set org-wide defaults to private or team, not whole-organisation, for projects holding client or deal material.
  3. Memory: valuable for productivity, but it accumulates context about clients and colleagues. If you enable it, add memory clean-up to your leaver process and tell staff what is stored.
  4. Location metadata: turn off unless needed.
  5. Information barriers: if you run Chinese walls (advisory versus trading, for example), map them to groups, project permissions and connector access before rollout. Claude has no concept of your barriers unless your configuration encodes them.

6. Audit, monitoring and evidence: build the record your regulator will ask for

The in-product audit log is a starting point, not an evidence base. Exported audit logs cover the last 180 days, are available to Owners only, and contain chat and project identifiers but not their content. Firms using customer-managed keys cannot use the export button at all and must use the API.

  1. Turn on the Compliance API early. The Primary Owner enables it and issues keys. It exposes the activity feed, chats and messages, files and artifacts, and users, groups and roles. Cowork sessions from Claude, Desktop and Mobile are captured, but the API returns only the most recent 30 days of those sessions, so pull continuously.
  2. Stream into your SIEM. Ship the feed to Splunk, Sentinel or Elastic on a schedule, then write detections: new admin grants, connector enablement, retention changes, bulk exports, unusual file uploads. More than two dozen security vendors, including Microsoft, CrowdStrike and Palo Alto Networks, now integrate with it.
  3. Add OpenTelemetry for agents. For Claude Code and Cowork, OpenTelemetry records tool calls, file access and approval decisions. Lock the endpoint in managed settings and keep prompt content capture off unless governance and staff notice are in place.
  4. Inference hooks (beta): give near real-time conversation visibility to your own endpoint. Useful for DLP; treat the payloads as sensitive data.
  5. Analytics API: adoption and seat utilisation data, useful for the business case and for spotting shadow use.

The test: could you reconstruct, within a day, what a given user asked, what Claude did, and which systems it touched, for an incident three months ago?

7. Mapping configuration to the frameworks you answer to

Every setting above is a control. Documenting it as one turns a tool rollout into evidence for your AI management system.

EU AI Act AI literacy for staff (Article 4, in force since Feb 2025). Deployer duties for high-risk uses (Article 26), now applying from 2 Dec 2027 after the Digital Omnibus Role-based access tied to training; logs retained via the Compliance API; use-case register showing no unassessed high-risk use
ISO/IEC 42001 Third-party and supplier controls, data governance, event logging, defined roles SCIM-managed roles, connector approval records, retention decision, SIEM pipeline
NIST AI RMF GOVERN 6 (third-party AI risk), MAP and MANAGE for use-case risk Settings register with owners, risk acceptance for web search and egress, red team results
DORA (EU financial entities) ICT third-party risk, register of information, exit strategy Contract terms, data export capability, sub-processor list, incident playbook
UK FCA and PRA (SM&CR, SS2/21) A named accountable senior manager; outsourcing and materiality assessment Owner of the settings register; materiality assessment of Claude as a third party

Contract checklist before signature: DPA and international transfer mechanism, sub-processor notification, breach notification window, audit and information rights, data export and deletion at exit, and confirmation in writing of the no-training position.

8.Claude Enterprise Day-1 configuration checklist

A starting baseline for a regulated firm. Adjust to your risk appetite, record each decision, and re-check after every Anthropic release.

  1. SSO enforced for Claude and the Anthropic Console
  2. All corporate domains verified; domain capture on; existing accounts claimed; org creation restricted
  3. SCIM provisioning live; 3 to 5 Owners with documented reasons; admin review set quarterly
  4. IP allowlisting or tenant restrictions in place
  5. Custom data retention set and approved by Legal and Compliance
  6. User feedback and chat rating reviewed (usually disabled)
  7. Residency, encryption key and transfer position agreed in the DPA
  8. Connectors tiered; high-sensitivity connectors limited to named groups; "always allow" for connector tools left off
  9. Permissions review completed on SharePoint, Drive and Slack before connecting them
  10. Cowork, auto-approve mode, cloud sessions and built-in browser set per role, not org-wide
  11. Code execution egress limited or monitored; Claude Code managed settings deployed (MCP allowlist, secret file denies, bypass mode disabled)
  12. Public projects and external artifact sharing disabled
  13. Memory policy and leaver clean-up defined
  14. Compliance API enabled and streaming to SIEM, with detections for admin and connector changes
  15. OpenTelemetry enabled for Claude Code and Cowork, endpoint locked
  16. Settings register created: setting, state, owner, rationale, next review date
  17. Acceptable use policy and AI literacy training issued before access is granted

Where configuration stops and assurance starts

A well-configured tenant answers "what is switched on". It does not answer "does it hold under attack" or "can we prove it to a regulator". Three questions remain after Day 1:

  1. Does it resist misuse? Prompt injection through a connected inbox, a shared document or a web page is the realistic attack on an agentic deployment. Adversarial testing of your actual configuration, connectors included, shows whether the controls hold.
  2. Is it evidenced? A settings register, mapped to ISO/IEC 42001, NIST AI RMF and the EU AI Act, turns configuration into audit-ready proof.
  3. Does it stay that way? Defaults change monthly. Control monitoring and re-testing after each release keeps the posture from drifting.

T3 works with COOs, CTOs and CDOs in high-risk industries on exactly this: configuration review, red teaming of agentic deployments, and AI governance operating models aligned to the standards we helped write.

​Sources

Previous Post Next Post

Leave a Reply

Your email address will not be published. Required fields are marked *