Securing Claude for Teams and Enterprise: Admin Settings That Matter

Securing a Claude organisation comes down to seven groups of settings, and the plan decides which you have. Team gives you single sign-on with a verified domain, just-in-time provisioning, the built-in roles, organisation-wide connector and tool policies, organisation skills and plugins, and managed settings for Claude Code. Enterprise adds SCIM, custom roles with per-connector permissions, custom data retention, audit logs, the Compliance API, IP allowlisting, customer-managed encryption keys and US-only inference. Set identity first, then connectors, then data, then logging, and write down who owns each.

This piece is about the controls. What the Team plan includes and how to set one up is in Claude Team plan; which MCP servers a team may connect, and how the list is kept, is in MCP governance. Both are linked rather than repeated below.

Which plan has which control

Anthropic’s page on what the Enterprise plan is↗ (opens in a new tab) lists what Enterprise adds on top of Team. Put side by side with the Team plan’s own list, as of late September 2026:

• Single sign-on and domain verification: Team and Enterprise.
• Just-in-time provisioning: Team and Enterprise. SCIM directory sync: Enterprise only.
• Built-in roles (User, Admin, Owner, Primary Owner): Team and Enterprise. Custom roles and groups: Enterprise only.
• Enabling connectors and setting organisation-wide tool policies: Team and Enterprise. Connector permissions per role: Enterprise only.
• Organisation skills and plugin marketplaces: Team and Enterprise. Targeting them at groups: Enterprise only.
• Custom data retention, audit logs, the Compliance API and IP allowlisting: Enterprise only.
• Customer-managed encryption keys and US-only inference: Enterprise only.
• Claude Code managed settings from the admin console: Team and Enterprise, set by an Owner.

If a security questionnaire asks for deprovisioning from your identity provider, an exportable log of admin actions or a retention period shorter than forever, the honest answer on Team is no. Those are the usual reasons an organisation moves up.

Identity: SSO, domain capture and SCIM

Start by verifying your email domain with a DNS TXT record, then connect your identity provider. Anthropic’s guide to setting up single sign-on needs an Owner or Primary Owner, and notes that verifying a domain changes nothing for existing users until SSO is set up and enforced. Enforce it once you have checked that everyone who should have access is assigned to the Claude app in your identity provider; people who are not assigned are locked out.

• Just-in-time provisioning adds people as they first sign in, with the User role. It never removes anyone: unassign someone in your identity provider and they cannot sign in, but they keep their seat until an admin removes them.
• SCIM, on Enterprise, provisions and deprovisions from your identity provider without anyone signing in first. With group mappings, roles follow group membership too. This is the control that makes leavers lose access on the day they leave.
• The Primary Owner is not exempt from enforced SSO. Keep that account on a domain you control and know who holds it.

Roles: keep Owners few

On both plans, Admins can invite and remove members, while billing, single sign-on, retention and audit logs are for Owners and the Primary Owner. Keep Owners to two named people. On Enterprise, custom roles are assigned to groups and are additive: a member gets the union of every role their groups carry, so one role cannot take away what another grants. Build a small base role for everyone and layer extra roles on top, rather than trying to subtract.

One trap is in Anthropic’s notes on custom roles↗ (opens in a new tab): a custom role with Identity and Access set to Can manage can edit roles, including its own, so it can widen its own access. Treat that permission like Owner. The same page describes Can view levels for billing, analytics and privacy, which suit auditors and security reviewers who need to see settings without changing them.

Connectors and MCP

An Owner enables each connector for the organisation, and each person still signs in to the service as themselves. Two settings then narrow what Claude can do with it:

• The organisation-wide tool policy, under Organization settings, Connectors, on Team and Enterprise. Allow reads and block writes for a connector, and no member can override it.
• On Enterprise, each custom role sets every connector, or every tool on a connector, to Always allow, Needs approval or Blocked. The stricter of the role and the organisation policy wins.
• Enterprise can also stop services on your verified domains being connected to Claude accounts outside the organisation.

Anthropic’s help page on using connectors↗ (opens in a new tab) warns that custom connectors reach servers Anthropic has not verified, and that they are called from Anthropic’s cloud, not from the person’s machine. Start write-capable tools on Needs approval. Which servers belong on the approved list at all is the job of MCP governance.

Skills and plugins

Skills and plugins carry instructions and, in a plugin’s case, hooks and MCP servers, so they deserve the same review as code. Owners manage both under Organization settings, Plugins & skills. The Policy tab decides whether people may create, share and publish their own; the Inventory tab lists every skill and plugin the organisation governs, including ones members made, with how many people used each in the last 30 days. Provisioned skills and plugins also sync to Claude Code for people signed in with the organisation account. Turn off publishing until someone owns the Requests tab where submissions are reviewed.

Data: training, retention and keys

• Training. Inputs and outputs on Team and Enterprise are not used to train models by default, unless someone sends feedback or reports a bug.
• Retention. By default, chats and projects are kept indefinitely. On Enterprise, Anthropic’s page on custom data retention↗ (opens in a new tab) lets an Owner set a period of at least 30 days. Chats inside a project follow the project’s period, and deletion cannot be undone. Custom retention does not cover features built on Claude Code on the web.
• Keys and location. Enterprise offers customer-managed encryption keys, held in your own cloud provider, and US-only inference.

Audit logs and the Compliance API

Audit logs are Enterprise only. An Owner exports the last 180 days from Organization settings, Data and Privacy, and receives a download link that works for 24 hours. The logs record sign-ins, SSO and domain changes, invitations, project and file events and data exports; they carry identifiers, not the text of chats. For continuous monitoring, the Compliance API↗ (opens in a new tab) pulls activity events, chat data and file content, now including audit log events. Only the Primary Owner can switch it on. Its coverage includes Claude Code through the CLI and the desktop app, but not cloud sessions or sessions run on Amazon Bedrock or Google Cloud, so a team routing Claude Code through a cloud provider needs that provider’s own logs.

Claude Code and the network

Claude Code reads a policy that developers cannot override. On Team and Enterprise, an Owner can deliver it from the admin console as server-managed settings↗ (opens in a new tab), fetched at startup and refreshed hourly; organisations with device management can push a file or registry key instead, which resists tampering better. The settings worth enforcing centrally, such as deny rules for secrets and disabling bypass mode, are covered in Claude Code for teams. Two extras fit here: availableModels limits which models people can pick, and disableAutoMode removes auto mode, which is the starting permission mode from Claude Code v2.1.283.

For the network, Enterprise IP allowlisting blocks any authenticated request from outside the CIDR ranges you list. There is no self-serve screen: you send the ranges to your Anthropic contact or support. Include every office, VPN exit and home-working route first, or people will be locked out.

A checklist for the first week

1. Name two Owners, confirm who holds the Primary Owner account, and move everyone else to User or Admin.
2. Verify your domains, connect SSO, test with a pilot group, then enforce it.
3. Choose provisioning: JIT on Team, SCIM with group mappings on Enterprise. Remove anyone who has left.
4. On Enterprise, create a base custom role and one extra role per team, and keep Identity and Access at Can manage for Owners only.
5. Enable only the connectors a real task needs this week. Set write tools to Needs approval or block them in the tool policy.
6. In Plugins & skills, turn off publishing until someone owns review, and read the Inventory tab.
7. On Enterprise, set a retention period your legal team has agreed, and decide whether to turn on the Compliance API.
8. Deliver a short Claude Code managed policy, and ask two developers to confirm it with /status.
9. Export the audit log at the end of the week and check it shows what you expect.

Keeping the decisions and findings somewhere

Most of these settings are decisions, and the reasons behind them get lost. On a fenbs board, the Decisions page records each one with the person who made it, since the decider is always a person, never the assistant. Gaps you find, such as an Owner who has left or a connector with write tools open, become bug tasks with a priority from 1 to 10, a plan, and a test status saying how the fix was checked. Every change is recorded in History under whoever made it, including Claude acting through MCP for a named person. fenbs has no due dates or assignee field, so put the owner and review date in the task note.