Claude Enterprise ships with defaults that prioritize productivity. That is reasonable for a general-purpose platform. For security teams, it means onboarding must be handled like any other high-impact SaaS rollout: review each setting, understand the data path, and document accepted risk versus managed control.
This guide is designed to be executed, not skimmed. For each setting, it tells you what to configure, why it matters, and what to track for ongoing governance.
Use this guide as your implementation standard:
- Set a baseline: Apply all Critical and High recommendations first.
- Capture evidence: Record setting state, owner, approval ticket, and date changed.
- Assign ownership: Name a control owner for each category (IAM, connectors, logging, Claude Code).
- Schedule review: Revalidate settings quarterly and after major platform updates.
Table of Contents
- Identity and Access Management
- Data and Privacy
- Audit Logging and Incident Response
- Connectors
- Code Execution and Network
- Visuals and Artifact Connectors
- Session Management and Endpoint Security
- Claude Code: Desktop App
- Claude Code: Managed Settings
- Additional Features
- Skills
- Configuration Checklist
- Governance and Evidence Model
1. Identity and Access Management
| Setting | Recommendation | Priority |
|---|---|---|
| SSO / SCIM | Enforce SSO; use SCIM for automated provisioning and deprovisioning | Critical |
| Allowed email domains | Restrict to corporate domain(s) only | Critical |
| Owners | 3–5 for most orgs; scale with tenant size, minimize where possible | Important |
| Admins | Minimum necessary for day-to-day operations; review quarterly | Important |
| Groups / RBAC (beta) | Use RBAC to scope connector and feature access by user population; review beta behavior before broad rollout | Important |
SSO with SCIM provisioning is the non-negotiable starting point. It ensures users are tied to your identity provider, deprovisioning is automatic when someone leaves, and you have a single place to enforce authentication policy. Restrict allowed email domains to your corporate domain only.
Claude Enterprise has three tiers: Owner, Admin, and User. Owners have full billing and configuration access; admins can manage settings and users. For a tenant of a few hundred users, 3–5 owners and a small number of admins is a healthy starting point. The right number depends on your org structure, but the principle is consistent: each privileged account should have a documented owner, a clear reason for the access level, and a periodic review cycle to confirm it is still needed.
Claude Enterprise supports RBAC in beta. Treat this as a core control for segmentation. For RBAC design, start with what connectors are globally available for Claude lookups, then align access groups to that data exposure. High-sensitivity connector access should be limited to approved populations, such as specific business units or trusted employee groups. Validate beta behavior in your environment and keep a periodic review cadence as the feature evolves.
2. Data and Privacy
| Setting | Recommended State | Risk |
|---|---|---|
| Location metadata | Disable | High: collects location data with no business justification |
| Rate chats | Disable | Medium: users may inadvertently send internal context to Anthropic |
| Share chats | Acceptable; user discretion | Low |
| Share chats using connectors | Disable | High: can expose connector data (PII, financials) to unintended recipients |
| Public projects | Disable | High: exposes internal content externally |
Location metadata is enabled by default at the enterprise level. It collects geographic location data for all conversations. There is no productivity benefit to offset this, and the data may be shared with third-party vendors depending on your agreement. Disable this org-wide before users begin working in the platform.
The rate chats feature sends feedback to Anthropic. In an enterprise context, the feedback UI is not clearly differentiated from internal feedback mechanisms. Users may inadvertently submit internal context, including sensitive project details or PII, as product feedback. Disable this and route product feedback through a controlled channel if needed.
When a chat session has accessed connector data (Google Drive, Gmail, Outlook, etc.), sharing that chat can expose the connector-sourced content to unintended recipients. This creates a direct path from high-sensitivity data sources to uncontrolled sharing. Disable it. Sharing chats that have not accessed connector data is a lower-risk setting and can remain enabled if there is a collaboration use case.
Public projects expose internal project content externally. There is no valid enterprise use case for this. Disable it on day one and do not re-enable without a security review.
3. Audit Logging and Incident Response
| Setting | Recommendation | Notes |
|---|---|---|
| Audit log retention | Set to Permanent | Supports IR, forensics, and compliance evidence |
| Audit log fields | Review available fields | Captures access metadata; adequate for access logging |
| Conversation content in logs | Plan around the absence of this | Platform limitation; not currently available |
| Owner notification on export | Not available today | Add compensating controls |
Audit logs capture access metadata: who accessed the platform, when, from where, what event type, device ID, platform, and user agent. Set retention to permanent to preserve this for incident response and compliance. This is your primary forensic data source.
This is the most significant platform-level security gap in Claude Enterprise today. During a security incident, including data exfiltration, prompt injection, or insider threat, you will need conversation content to assess scope and impact. Audit logs alone will not give you this. Plan accordingly:
- Develop a Claude Enterprise IR playbook before you need it. Document what data is and is not available, how to export it, and when to escalate to Anthropic support.
- Investigate whether Anthropic provides an API or support mechanism to retrieve conversation content for incident response. If not, submit this as a formal feature request.
- If you have strict data handling requirements, factor this gap into your risk acceptance process for the platform.
When any owner performs a bulk data export, other owners should be automatically notified. This is a standard separation-of-duties control that prevents unilateral data exfiltration by a privileged account. Submit this to Anthropic as a feature request. In the meantime, consider a periodic manual review of export activity in audit logs.
4. Connectors
Connectors are one of the highest-risk configuration areas in Claude Enterprise because they dramatically expand the data Claude can access and surface. Evaluate each connector before enabling it.
| Connector | Data Sensitivity | Risk Level | Notes |
|---|---|---|---|
| Atlassian (Jira / Confluence) | Low-Medium | Medium | Risk profile: ticket and documentation leakage can expose architecture details, vulnerabilities, and incident context. |
| GitHub | Medium-High | High | Risk profile: source code and security configs can expose secrets, auth logic, and exploitable implementation details. |
| Gmail | High | High | Risk profile: inbox access can expose legal, financial, HR, and customer communications with broad confidentiality impact. |
| Google Drive | High | High | Risk profile: unstructured files often contain PII, strategy docs, contracts, and spreadsheets with sensitive business data. |
| Microsoft 365 (Outlook / OneDrive / SharePoint) | High | High | Risk profile: email and document aggregation creates large-scale exposure across finance, legal, HR, and operations. |
| Slack | Medium | Medium | Risk profile: channels and DMs can leak incident chatter, credentials pasted in error, and internal decision-making context. |
| Notion | Medium | Medium | Risk profile: internal wikis and SOPs can reveal system design, security processes, and sensitive project planning. |
| Salesforce | High | High | Risk profile: CRM records can expose customer PII, deal terms, support notes, and regulated data fields. |
| Zendesk | Medium-High | High | Risk profile: support tickets can include customer identifiers, logs, screenshots, and incident details. |
| Linear / Asana (project management) | Low-Medium | Medium | Risk profile: roadmap, backlog, and issue data can reveal unreleased features, vulnerabilities, and operational priorities. |
When designing RBAC groups, take into consideration which connectors are globally available for Claude lookups and adjust group access accordingly. If a connector is globally enabled, assume any user population with access can retrieve and summarize data from that source. Build restricted groups before enabling high-sensitivity connectors, and document the business justification for each group-to-connector mapping.
Connectors authenticate via individual user OAuth. Claude accesses data using the permissions of the authenticated user, not a shared service account. The blast radius for any single session is bounded by what that user can already access. However, this does not mean connectors are low risk. Claude may surface, summarize, or combine data from connector sources in ways the user did not intend, particularly when the "share chats using connectors" setting is enabled. That setting should already be disabled per Section 2.
Gmail, Google Drive, and Microsoft 365 give Claude access to PII, financial data, and sensitive internal communications. Do not enable these at the org level without a documented use case, a review of what data users can access through them, and an RBAC mapping that limits access to approved groups. If your user population includes contractors or restricted roles, verify that connector availability and RBAC policy align before rollout.
For contractors or restricted user populations, connector access should be scoped through RBAC groups with least-privilege defaults. Prioritize connector restrictions per group and confirm that global connector enablement does not unintentionally broaden lookup access.
New connectors should go through security review before enablement. The review should cover: what data the connector can access, whether that data is in scope for your AI governance policy, and how you will monitor for misuse. Connectors that have been enabled but have no active use case should be periodically reviewed and disabled if unused.
5. Code Execution and Network
Code execution means Claude can run code inside a managed runtime to complete tasks such as data transformation, scripting, or analysis. Network egress controls whether that runtime can reach external domains. Security teams should care because this combines code execution plus outbound connectivity, which can turn a bad prompt or misuse event into data exfiltration.
Why teams enable this:
- Automating repetitive engineering or analytics tasks
- Running small scripts during investigation or troubleshooting
- Installing package dependencies required for legitimate workflows
Why it needs hardening:
- Prompt injection can try to make the runtime call attacker-controlled domains
- Poor allowlists can permit unnecessary outbound access
- Broad enablement can expose users who do not need this capability
| Setting | Recommendation | Risk Level |
|---|---|---|
| Code execution | Enable only if there is a clear use case; require user opt-in as a second gate | Medium |
| Network egress | Disable unless a specific use case requires it; start with package managers only | Medium |
| Domain allowlist | Begin with package managers only; require security review for any additions | Medium |
Code execution is only valuable for a subset of your user population. Claude Enterprise supports a two-gate model: admin enables it at the org level, and each user must also opt in. This is the right approach. Neither gate alone is sufficient. Admin enablement without user opt-in applies to everyone, while user opt-in without admin control provides no organizational guardrail. Use both.
Network egress allows code execution environments to make outbound connections. This significantly expands the potential impact of a prompt injection or misuse scenario. The safest baseline is disabled. If you do enable it, start with package managers only and document that any additional domains require a security review before being added to the allowlist. Do not enable network egress speculatively. Wait for a specific, justified request.
For this feature set, security comes from layered controls:
- Population control: Restrict access with RBAC and require per-user opt-in so only approved groups can run code.
- Default-off network: Keep egress disabled unless a documented business need exists.
- Minimal allowlist: Start with package manager domains needed for your stack only, then require security approval for each addition.
- Change control: Track who requested each domain, why it is needed, approval evidence, and an expiration or review date.
- Telemetry and alerting: Send execution and audit events to your SIEM or OTEL pipeline and alert on unusual domain access patterns.
- Secret protection: Enforce managed settings that block access to sensitive files such as
.env, keys, and credential artifacts.
If your team cannot operate these controls, keep network egress disabled and limit code execution to a smaller trusted group.
6. Visuals and Artifact Connectors
| Setting | Recommendation | Risk Level |
|---|---|---|
| Interactive content (image rendering) | Disable | High: known data exfiltration vector |
| Visuals / Artifact connectors | Evaluate before enabling | Medium: data injection and trust boundary risks |
When Claude renders images, it can be tricked into making outbound requests via image URLs. This is a well-documented prompt injection attack pattern: a malicious instruction embedded in content Claude reads causes it to render an image tag with sensitive conversation data encoded in the URL query string. Disabling interactive content blocks this vector entirely.
Artifact connectors allow artifacts to pull data from external sources. Before enabling this, consider:
- Data injection risk: External sources can inject malicious content into artifacts that users interact with and may trust.
- Indirect exfiltration: Depending on implementation, artifacts pulling from external sources could be used to send data outbound.
- Trust boundary confusion: Users may treat artifact-rendered output as internal and validated when it incorporates unverified external content.
If your organization does not have an active use case for artifact connectors, leave this disabled. If there is demand, define acceptable use criteria and monitor for anomalous patterns before rolling it out broadly.
Use examples like these during security review so teams can evaluate realistic failure modes:
- Example 1: Prompt-driven image exfiltration. A user pastes internal content into a chat and Claude is instructed to "render a helpful image." The generated image URL includes encoded internal data in query parameters. Control that blocks it: disable interactive content (image rendering).
- Example 2: Untrusted dashboard feed. An artifact pulls metrics from an external endpoint. The endpoint returns manipulated text that instructs users to run unsafe remediation commands. Control that reduces risk: only allow approved data sources and label externally sourced content as untrusted.
- Example 3: Hidden data boundary crossing. A team artifact combines internal connector data with external enrichment APIs, then gets shared internally as if it were a trusted internal report. Control that reduces risk: require provenance tags and approval for artifacts that mix internal and external data.
- Example 4: Sensitive artifact oversharing. An artifact includes customer-specific details and is shared broadly because it appears generic at first glance. Control that reduces risk: apply RBAC-based sharing restrictions and periodic reviews of shared artifacts.
Security teams should define acceptance criteria before enabling artifact connectors: approved source list, data classification rules, sharing scope, and monitoring ownership.
7. Session Management and Endpoint Security
| Setting | Recommendation | Risk Level |
|---|---|---|
| Session length | Set a maximum; 8-12 hours is a reasonable enterprise baseline | Medium |
| MDM / Conditional access | Enforce device trust via your IdP where possible | Medium |
| Usage anomaly detection | Not available in the admin console; compensate via SIEM | Monitoring gap |
Claude Enterprise does not enforce a session timeout by default. A long-lived session with active connector tokens increases the window of exposure if a session is hijacked or a device is left unattended. Set a maximum session length that aligns with your existing enterprise standards. In most environments, 8-12 hours covers the working day and is a common benchmark in enterprise SaaS policies. This is especially important once connectors are enabled.
Claude Enterprise itself does not enforce MDM or device compliance. Use your identity provider (Okta, Azure AD, or equivalent) to add a conditional access policy that restricts Claude Enterprise access to managed and compliant devices. This prevents personal devices from accessing the platform without additional controls.
There is no built-in capability to detect anomalous usage patterns, such as unusual access times, geographic outliers, or session volume spikes. Compensate by feeding Claude Enterprise audit logs into your SIEM and building correlation rules for patterns that would indicate misuse or account compromise.
8. Claude Code: Desktop App
| Setting | Recommendation | Risk Level |
|---|---|---|
| Bypass permissions mode | Keep disabled; do not enable | Critical |
| Auto permissions mode | Keep disabled; do not enable | Critical |
These two settings represent the most significant security exposure in Claude Code and should be treated as critical controls:
- Bypass mode allows Claude to execute arbitrary shell commands without user approval. A single successful prompt injection in bypass mode can result in data exfiltration, credential theft, or system corruption.
- Auto mode lets Claude make tool permission decisions autonomously during a coding session, without prompting the user.
Both should be disabled org-wide. Any request to enable either setting should require a formal security review, a documented and scoped use case, and explicit risk acceptance from the appropriate stakeholder. Do not approve these as a convenience measure.
9. Claude Code: Managed Settings (settings.json)
| Setting | Recommendation | Priority |
|---|---|---|
| Managed settings.json | Configure a baseline before users deploy Claude Code at scale | High |
Claude Enterprise supports a centrally managed settings.json that overrides all user-level and project-level Claude Code settings. This is the most powerful security lever available for controlling how Claude Code behaves across your engineering org. If you are deploying Claude Code at scale, configuring this before rollout should be a priority. Available controls include:
- File access restrictions: Deny read or write access to sensitive files using gitignore-style patterns, including
.env,.env.*,credentials.json,*.pem,*.key, AWS credentials files, and similar. - Tool restrictions: Block specific tool invocations entirely, for example
Bash(curl *)orBash(wget *), to prevent arbitrary outbound HTTP. - Directory scoping: Restrict which directories Claude Code can read from or write to via sandbox filesystem controls.
- Permission mode lockdown: Enforce
disableBypassPermissionsModeanddisableAutoModeat the managed level so users cannot override these locally. - Network controls: Restrict outbound domains for code execution via
sandbox.network.allowedDomains. - MCP server controls: Define an approved list of MCP servers via
allowedMcpServers,deniedMcpServers, andallowManagedMcpServersOnly. - Hook controls: Use
allowManagedHooksOnlyto prevent users from defining their own hooks. - Org-locked login:
forceLoginOrgIDrestricts Claude Code to authenticate only against your organization. - Fail-closed behavior:
forceRemoteSettingsRefreshprevents Claude Code from starting if managed settings cannot be fetched, ensuring controls are always applied.
A good baseline prioritizes: denying access to credential files, enforcing org-locked login, locking bypass and auto modes at the managed level, and restricting MCP servers to an approved list.
10. Additional Features
| Feature | Recommendation | Notes |
|---|---|---|
| Fast mode | Disable unless you have cost controls in place | Increases token consumption |
| Remote control | Keep disabled | High risk; no typical enterprise use case |
| Code review (GitHub PRs) | Evaluate for adoption | Potential security benefit if scoped well |
| Claude in Chrome | Evaluate trade-offs before enabling | Browser extension attack surface |
| Cowork / Claude Code agent | Enable with OTEL monitoring | Monitor usage and costs |
| Cross-org knowledge search | Evaluate data boundary implications carefully | Data governance risk |
| Web search | Acceptable; document the accepted risk | Known prompt injection and data leakage risk |
Remote control allows external parties to interact with Claude sessions. There is no common enterprise use case that justifies this surface area. Keep it disabled.
Automated AI-assisted code review on pull requests can surface security issues earlier in the development cycle. Evaluate this feature with your engineering and security teams. The key questions are: what data does it access, who controls the review prompts, and how do you prevent it from becoming a backdoor for sensitive code exposure.
Claude Code supports comprehensive OTEL integration: metrics (session counts, lines changed, commits, cost, token usage), events (user_prompt, tool_request, tool_result, api_request, tool_decision), and distributed traces that link prompts to API calls and tool executions. Privacy controls redact prompt content and tool inputs by default. Without OTEL, you have no visibility into how agentic Claude Code sessions are being used. Stand up a collector (Datadog, Grafana, or equivalent) before enabling agentic features at scale.
If your Claude Enterprise deployment spans multiple business units or operating companies, features that allow cross-org knowledge base search can surface data across organizational boundaries that should otherwise be segmented. Evaluate whether cross-org search is intentional, which knowledge bases are in scope, and whether any KB content should be restricted to specific user populations.
Web search introduces two known risks: prompt injection via malicious web content that Claude retrieves, and data leakage where sensitive query content is embedded in search requests. In most enterprise environments, the productivity benefit outweighs these risks given other controls in place. The important step is to document this as a formal risk acceptance rather than an oversight.
11. Skills
| Setting | Recommendation | Risk Level |
|---|---|---|
| Code execution for skills | Disable by default; require approval to enable | Medium |
| User-created skills | Disable; require a review and approval process | Medium |
| Skill sharing | Disable until a governance process is in place | Medium |
| Share with organization | Disable until a governance process is in place | Medium |
Skills can contain executable code. Without a review and approval process, user-created skills represent an unsanctioned code execution path that bypasses normal controls. The right posture is to keep all skill settings disabled by default and treat skill enablement as a change that requires security review, documentation of the use case, and explicit approval. If your organization reaches a point where skills are being used at scale, build a formal process before enabling org-wide sharing.
12. Configuration Checklist
Use this as a starting point for your Claude Enterprise security review. Work through the immediate items at onboarding and schedule the configuration items for your first sprint.
At Onboarding: Do These First
- Enforce SSO via your identity provider; enable SCIM for automated provisioning
- Restrict allowed email domains to corporate domain(s) only
- Disable location metadata (org-wide)
- Disable rate chats
- Disable share chats using connectors
- Disable public projects
- Confirm bypass permissions mode and auto permissions mode are both off in Claude Code Desktop
- Set audit log retention to permanent
Short-Term Configuration: First 30 Days
- Set session length to a maximum (8–12 hours recommended)
- Configure managed settings.json baseline for Claude Code
- Define a connector approval process; audit and justify any currently enabled connectors
- Set network egress to disabled or restrict to package managers only
- Investigate MDM/conditional access policy via your IdP for device trust
- Develop a Claude Enterprise IR playbook covering data availability, export procedures, and Anthropic escalation
Ongoing / Strategic
- Implement RBAC group design tied to connector exposure, and revalidate group-to-connector mappings as Anthropic evolves the beta
- Stand up OpenTelemetry monitoring before enabling agentic Claude Code features at scale
- Evaluate Claude Code Review for GitHub PRs as a security-positive feature
- Establish periodic review cycles for admin accounts, active connectors, and enabled features
- Submit feature requests to Anthropic: owner export notifications, conversation content in audit logs
13. Governance and Evidence Model
If you want this configuration to hold up in audits, customer reviews, and incidents, pair each setting decision with evidence. A control that is not documented and reviewable will drift.
Track the following fields for every high-impact setting:
- Current state: Enabled, Disabled, or Restricted (with scope details)
- Security owner: Team and named individual accountable for the decision
- Business owner: Team that requested or depends on the setting
- Risk rationale: Why the chosen state is acceptable for your environment
- Approval artifact: Ticket, change request, or policy exception reference
- Last review date: Most recent validation date
- Next review date: Scheduled review checkpoint
Minimum governance cadence:
- Quarterly: Review admins, owners, connector states, and Claude Code managed settings.
- After platform changes: Revalidate controls when Anthropic ships new settings or permission models.
- After incidents: Confirm whether current settings and logs were sufficient for investigation.
- Before renewals or major procurement: Export your current control state and exceptions as an evidence package.
Use this section with the configuration checklist in Section 12 to turn recommendations into a durable operating standard.
Final Thoughts
The goal of this guide is not a perfect score. The goal is a defensible posture with clear ownership of what is enabled and why. Claude Enterprise gives security teams enough control to deploy responsibly, but the defaults assume a permissive trust model. The work is in the configuration.
Most of the high-priority items are straightforward to disable. The harder and more valuable work is building the processes: connector approval, IR planning, managed settings baselines, and ongoing review cycles. Those are the things that hold up when something goes wrong.
If you are working through this at your organization and want to discuss specific settings or use cases, reach out.