Claude for Enterprise Security Guide: Controls, Data Handling and Admin Settings

A Claude Enterprise organisation is a SaaS tenant that holds chats, project files, connector grants and coding sessions, and its defaults are tuned for adoption rather than for least privilege. It spans claude.ai, Cowork, Claude Code, Claude in Chrome and the Claude Console, each with its own settings. This guide walks through the controls Anthropic currently documents for identity, roles, connectors and MCP, logging, retention and inline data loss prevention, and how to configure them as a baseline. It is written for identity, SaaS security and AI governance practitioners who own or review a Claude deployment. Settings were checked against Anthropic's documentation in October 2026; confirm them before enforcing, as the product changes often.

Key takeaways

• SCIM is the only automatic deprovisioning path. Just-in-time provisioning never removes members, so leavers keep seats until an admin deletes them; SCIM directory sync is Enterprise only.
• Custom roles are where least privilege lives. Capabilities, admin areas, connector tools and models are granted per role, but the Identity & Access "Can manage" permission can edit its own role and turn on Owner access.
• Connectors are shared trust decisions. Custom MCP connectors are not verified by Anthropic, static credentials are shared by everyone who uses the connector, and calls originate from Anthropic's cloud rather than the user's device.
• Two log sources with different reach. The audit log export covers 180 days of admin and sign-in events; the Compliance API Activity Feed keeps records for six years but only from the day it is enabled.
• Claude Code needs its own policy. Managed settings delivered by file, MDM or the admin console set permission rules, MCP allowlists and bypass-mode locks that the web admin settings do not cover.

How identity and access work in Claude Enterprise

Sign-in for Team, Enterprise and Console organisations is federated through SAML or OpenID Connect, with WorkOS handling the setup flow. Setup guides exist for Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud and Duo.

1. Verify domains: add each domain under the Domains section and publish a DNS TXT record whose value begins with anthropic-domain-verification- at the root domain. Several domains can be verified, but all must be served by one identity provider.
2. Restrict organisation creation: once domains are verified, the "Restrict organization creation" toggle stops staff creating new Claude or Console organisations, including personal ones, on those domains. This is the main lever against unmanaged tenants. See the Shadow AI Discovery Guide.
3. Require SSO: "Require SSO for Claude" and "Require SSO for Console" are separate toggles. Set both; leaving Console optional keeps an email sign-in path open for developers.
4. Choose provisioning: invite only is the default; JIT creates users on first login with the User role; SCIM creates users before first login and removes them when they are unassigned in the IdP.

SSO lockout is a real operational risk. If a SAML certificate expires while SSO is required, Anthropic's documented recovery is to contact Support from an Owner's or Primary Owner's email address; there is no documented break-glass account. Track certificate and secret expiry. See the Identity Provider and SSO Security Guide and the SCIM Provisioning Guide.

Admin roles and privileged access

Enterprise organisations use Owner, Admin, User and Custom roles, with a single Primary Owner. The Console has its own role set: Admin, Developer, Limited Developer, Billing, Claude Code User and User. Only Owners and Primary Owners can export audit logs or set custom retention, and only they hold the organization:manage permission that inference hooks require.

• Treat Identity & Access "Can manage" as an Owner: it can create groups and roles, including its own, so Anthropic recommends reserving it for trusted administrators. Put it under the same review as other tenant admin roles. See the Privileged Access Management Guide.
• Protect the Primary Owner: the Primary Owner is exempt from SCIM reconciliation and cannot be assigned by group mapping; it is transferred manually under Organization settings > Members. Use a named, phishing-resistant account, not a shared mailbox.
• Keep Owners in mapped groups: Owner and Admin roles are not exempt, so enabling group mappings removes any Owner who is not in a mapped group.
• Sync groups only for role-based access: Anthropic recommends syncing Groups (not Members) for RBAC, setting mapped users to "Custom", and enabling group mappings last. A group mapped to User but assigned a custom role gets no custom permissions.

Integrations, API tokens and service accounts

Connectors give Claude reach into Google Drive, Gmail, Microsoft 365, Slack, GitHub and any remote MCP server an Owner adds. On Enterprise, Owners, Primary Owners and custom roles with Libraries "Can manage" can add custom connectors under Organization settings > Connectors; members then connect individually. See the MCP Security Guide.

• Know where connector traffic comes from: remote MCP connections originate from Anthropic's cloud for every client, including Desktop and Cowork. A private MCP server must be internet-reachable and allowlist Anthropic's IP addresses, so put authentication on the server itself, not only on network location.
• Treat third-party MCP servers as code you run: Anthropic warns that custom connectors are unverified, can modify data and may carry prompt injection. The postmark-mcp malicious MCP server showed how one update to a trusted server silently copied every outgoing email.
• Disable write tools for Research: during Research, Claude can invoke connector tools without further approval. Block write tools for roles that use it. Members can also add personal connectors and, unless you require IdP-only connections, connect personal accounts.
• Inventory machine credentials: Compliance and Admin API keys, connector keys and Claude Code API keys are non-human identities. Record an owner, scope and rotation date for each. See the API Key Management Guide.

Claude Code managed settings

Claude Code reads settings from user, project, local and managed scopes, and managed settings take precedence over everything else. Policy reaches devices through server-managed settings in the claude.ai admin console (fetched at startup and polled hourly), MDM (the com.anthropic.claudecode macOS preferences domain, or a Settings value under HKLM\SOFTWARE\Policies\ClaudeCode), or a managed-settings.json file in /Library/Application Support/ClaudeCode/, /etc/claude-code/ or C:\Program Files\ClaudeCode\.

• Lock the permission model: set permissions.disableBypassPermissionsMode to "disable" and allowManagedPermissionRulesOnly to true so developers cannot widen allow rules; add deny rules such as Read(./.env) for secret files.
• Allowlist MCP servers: allowManagedMcpServersOnly, allowedMcpServers and deniedMcpServers control which servers load, and managed-mcp.json deploys approved ones. strictKnownMarketplaces and blockedMarketplaces restrict plugin sources.

Logging and detection

Audit log columns are created_at, actor_info, event, event_info, entity_info, ip_address, device_id, user_agent and client_platform. Events worth alerting on:

• Federation tampering: org_sso_toggled, org_sso_connection_deleted, org_sso_connection_deactivated, org_jit_toggled and org_domain_add_initiated. These map to ATT&CK T1098 Account Manipulation when an attacker with admin access weakens sign-in.
• Bulk data movement: org_data_export_started, project_visibility_changed and bursts of file_uploaded.
• Non-SSO sign-in: user_signed_in_google, user_signed_in_apple or user_requested_magic_link after SSO is required suggest a gap in enforcement or a Console path left open (ATT&CK T1078.004 Cloud Accounts).

In the Activity Feed, claude_*_viewed means a Claude app loaded content, not that a person read it, and a user_actor is not always a human. Actor types such as scim_directory_sync_actor and admin_api_key_actor separate machine activity from people. See the SIEM Guide.

Inline data loss prevention with inference hooks

Inference hooks send each governed prompt, with tool calls, results and text extracted from attachments, as a signed HTTPS POST (Standard Webhooks) to a server you or a security vendor run, and wait for an allow or deny verdict (5 second default timeout) before inference. One hook covers claude.ai, Cowork, Claude Code, Claude for Microsoft 365, Claude Tag and Claude in Chrome. Practical points:

• Set failure handling deliberately: on timeout or error the organisation setting either blocks or allows uninspected; a circuit breaker applies that choice to every request during sustained failure.
• Roll out in shadow mode: shadow mode, a rollout percentage and role exclusions allow observation before blocking.
• Know the blind spots: verdicts cannot redact, image-only content is not inspected, voice is only partly covered, and some Anthropic-run features that make their own model calls are not governed. Turn on "Validate tool calls" if tool use is in scope. See the Generative AI Data Loss Prevention Guide.

Data handling, retention and training use

• Training: inputs and outputs from commercial products (Team, Enterprise, API) are not used for training by default. Exceptions are feedback (thumbs ratings and bug reports, kept up to five years and de-linked from user IDs) and explicit opt-in. Owners can turn off the "Rate chats" setting under Organization settings > Data and Privacy to remove the feedback path.
• Default retention: without a custom period, Enterprise data is kept indefinitely. Deleted conversations leave chat history immediately and back-end storage within 30 days. Usage Policy flagged inputs and outputs can be kept up to two years, and classifier scores up to seven.
• Custom retention: Owners set periods for chats, projects and artifacts with a 30 day minimum. Deletion is permanent, runs daily and is logged. Claude Tag, Claude Managed Agents and cloud Claude Code features are not covered. See the Data Retention and Secure Deletion Guide.
• Encryption and residency: Enterprise offers customer-managed encryption keys, US-only inference and a HIPAA-ready configuration; customer-managed keys disable the audit log export, so use the Compliance API.

Hardening baseline

Pilot each phase with a group mapped to a custom role, and record the previous configuration so a toggle can be rolled back quickly.

1. Before go-live: verify domains, turn on "Restrict organization creation", configure SAML or OIDC, and require SSO for both Claude and Console. Rollback: turning off the requirement makes SSO optional again.
2. Identity lifecycle: enable SCIM with group mappings off, sync groups, assign them to custom roles, then enable mappings. Test a leaver end to end, including connector grants in Google and Microsoft.
3. Roles: build two or three custom roles (standard user, developer, admin) with only the capabilities each needs; restrict Identity & Access "Can manage" to a small named group.
4. Connectors: enable connector permissions, then change the seeded "All connectors: Always allow" to "Needs approval" or "Blocked" per role. Keep "Allow 'Always allow' for connector tools" off. Prefer managed authorization with IdP-only connections where your IdP supports it.
5. Logging: enable the Compliance API on day one (it does not backfill), issue an Admin API key for SIEM ingestion and restrict the Compliance Access Key.
6. Data: set custom retention to match your records schedule, decide on "Rate chats", and configure inference hooks in shadow mode before enforcing.
7. Claude Code: deploy managed settings by MDM and server-managed settings for cloud sessions, with bypass mode disabled and an MCP allowlist.

Small vs large organisations: a small team on the Team plan has no SCIM, custom roles or audit log export, so it must rely on JIT plus manual offboarding and on keeping Owners few. Large organisations should treat Claude as a tier-one SaaS application: SCIM, custom roles per business unit, SIEM ingestion and inference hooks routed through an existing DLP vendor. See the Enterprise AI Copilot Security Guide for controls that apply to every assistant.

Common misconfigurations

• JIT treated as deprovisioning: removing a leaver only in Claude re-adds them at the next SSO login, and unassignment in the IdP leaves the seat in place.
• Connector permissions enabled but never tightened: existing roles are seeded with "Always allow" for all connectors at enablement, so nothing changes until each role is edited.
• Shared static connector keys with broad scope: every member using the connector acts with the same credential, which removes per-user attribution in the downstream service. If the key leaks, the attacker inherits that combined reach.
• Compliance API enabled late: activity before enablement is never recorded, so an investigation into earlier events has only the 180 day audit export.
• Console left outside SSO: requiring SSO for Claude but not for Console keeps an email-link path into API keys and developer roles.
• Claude Code policy only in the web console: cloud sessions read only server-managed settings, local Cowork sessions do not fetch them, and the console cannot yet target a group, so both device and console policy are needed. See the AI Coding Agents Security Guide.

Framework mapping

In ISO/IEC 27001:2022 terms the deployment sits mainly under Annex A 5.23 (information security for use of cloud services), 5.15 (access control), 8.12 (data leakage prevention) and 8.15 (logging); in CIS Controls v8.1, Control 6 (Access Control Management) and Control 8 (Audit Log Management).

Detection and measurement

• Provisioning coverage: percentage of Claude members created by SCIM rather than JIT or invite (target: all but the Primary Owner).
• Leaver lag: time from HR termination to removal of the Claude member and all connector grants.
• Privileged role count: number of Owners plus custom roles with Identity & Access or User Management "Can manage", reviewed quarterly.
• Connector policy: share of connector tools set to "Always allow", and number of personal connectors in use.
• Log completeness: days since the Activity Feed cursor last advanced in the SIEM, and alerts raised on SSO and export events.
• Inline DLP effect: inference hook deny rate and number of requests allowed uninspected under failure handling.

Practitioner checklist

• Verify all domains, turn on "Restrict organization creation" and require SSO for both Claude and Console.
• Use SCIM with group mappings; test a leaver and confirm connector grants are revoked in each connected service.
• Name the Primary Owner, keep Owners in mapped groups and limit Identity & Access "Can manage".
• Replace seeded "Always allow" connector settings per role and keep "Allow 'Always allow' for connector tools" off.
• Review every custom MCP server before adding it; scope and vault any static connector credential.
• Enable the Compliance API on day one and stream the Activity Feed to the SIEM with an Admin API key.
• Alert on SSO, JIT, domain and data export events in the audit log.
• Set custom retention, decide on "Rate chats" and pilot inference hooks in shadow mode.
• Deploy Claude Code managed settings by MDM and server-managed settings, with bypass mode disabled and an MCP allowlist.

Standards and references

• Anthropic: Setting up JIT or SCIM provisioning on Team or Enterprise plans
• Anthropic: Set up role-based permissions on Enterprise plans
• Anthropic: Access audit logs
• Anthropic: Query the Activity Feed (Compliance API)
• Anthropic: Inference hooks
• Anthropic: Configure custom data retention controls for Enterprise plans
• Anthropic: Deploy managed settings (Claude Code)
• OWASP: Top 10 for LLM Applications 2025

Related NHI Mgmt Group resources: Enterprise AI Copilot Security Guide · Shadow AI Discovery Guide · MCP Security Guide · Gemini for Google Workspace Security Guide · AI Governance Guide