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.
Work through Critical and High items first. Section 12 is the execution checklist. Section 13 covers how to document decisions and keep them from drifting after Anthropic ships platform updates.
1. Identity and Access Management
| Setting | Recommendation | Priority |
|---|---|---|
| SSO / SCIM | Enforce SSO and use SCIM for automated provisioning and deprovisioning | Critical |
| Allowed email domains | Restrict to corporate domain(s) only | Critical |
| Owners | 3–5 for most orgs, scaling with tenant size and minimizing 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 ties users to your IdP, automates deprovisioning when someone leaves, and centralizes authentication policy. Restrict allowed email domains to corporate domains 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 it as a core segmentation control and validate behavior in your environment before broad rollout. Connector-specific RBAC design is covered in Section 4.
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 with 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 |
Three settings ship enabled and should be disabled org-wide before users begin working in the platform.
- Location metadata collects geographic data with no productivity benefit. Data may be shared with third-party vendors depending on your agreement.
- Rate chats sends feedback to Anthropic. The UI is easy to confuse with internal feedback, and users may submit sensitive context or PII. Route product feedback through a controlled channel if needed.
- Public projects expose internal content externally with no valid enterprise use case.
When a chat session has accessed connector data (Google Drive, Gmail, Outlook, etc.), sharing that chat can expose connector-sourced content to unintended recipients. Disable it. Sharing chats that have not accessed connector data is lower risk and can remain enabled if there is a collaboration use case.
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 (user, timestamp, event type, device ID, platform, user agent). Set retention to permanent. This is your primary forensic data source for IR and compliance.
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 | Tickets and documentation can expose architecture details, vulnerabilities, and incident context. |
| GitHub | High | High | Source code and security configs can expose secrets, auth logic, and exploitable implementation details. |
| GitLab | High | High | Source code, CI/CD variables, and pipeline artifacts can expose secrets, deployment paths, and production access patterns. |
| Gmail | High | High | Inbox access can expose legal, financial, HR, and customer communications with broad confidentiality impact. |
| Google Drive | High | High | Unstructured files often contain PII, strategy docs, contracts, and spreadsheets with sensitive business data. |
| Microsoft 365 (Outlook / OneDrive / SharePoint) | High | High | Email and document aggregation creates large-scale exposure across finance, legal, HR, and operations. |
| Slack | High | High | Private channels and DMs can expose incident chatter, credentials pasted in error, and sensitive internal decision-making context. |
| Microsoft Teams | High | High | Private chats, channels, meetings, and shared files can expose legal, HR, and incident-related communications. |
| Notion | Medium | Medium | Internal wikis and SOPs can reveal system design, security processes, and sensitive project planning. |
| Box | Medium-High | High | Enterprise file repositories can include contracts, customer data exports, and regulated internal documents. |
| Salesforce | High | High | CRM records can expose customer PII, deal terms, support notes, and regulated data fields. |
| ServiceNow | Medium-High | High | Incident and change records can reveal vulnerabilities, access workflows, and operational runbooks. |
| Zendesk | Medium-High | High | Support tickets can include customer identifiers, logs, screenshots, and incident details. |
| Linear / Asana (project management) | Low-Medium | Medium | Roadmap, backlog, and issue data can reveal unreleased features, vulnerabilities, and operational priorities. |
Start with which connectors are globally available for Claude lookups. 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, document the business justification for each group-to-connector mapping, and apply least-privilege defaults for contractors and restricted roles.
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, Claude may surface, summarize, or combine connector data in ways the user did not intend, especially if share chats using connectors is still enabled (disable 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 accessible data, and RBAC that limits access to approved groups, including contractors and restricted roles.
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 lets Claude run scripts in a managed runtime. Network egress controls whether that runtime can reach external domains. Together they can turn prompt injection or misuse into data exfiltration. Enable only where there is a clear use case, and treat outbound access as a separate, higher-risk decision.
| Setting | Recommendation | Risk Level |
|---|---|---|
| Code execution | Enable only with a clear use case and required 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. Admins enable 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.
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 the following.
- 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.
- Untrusted dashboard feed. An artifact pulls metrics from an external endpoint that returns manipulated remediation instructions. Mitigate with an approved source list and clear labeling of external content.
- Hidden data boundary crossing. An artifact combines internal connector data with external APIs and gets shared as a trusted internal report. Mitigate with provenance tags and approval for mixed-source artifacts.
- Sensitive artifact oversharing. Customer-specific details in an artifact shared broadly because it looks generic. Mitigate with RBAC-based sharing restrictions and periodic reviews.
Before enabling artifact connectors, define acceptance criteria (approved sources, 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 session timeouts or MDM by default. Set a maximum session length aligned with your enterprise standards (8–12 hours is a common baseline), especially once connectors are enabled. Enforce device trust via conditional access in your IdP (Okta, Azure AD, or equivalent) so only managed, compliant devices can reach the platform.
There is no built-in anomaly detection for unusual access times, geographic outliers, or session volume spikes. Feed audit logs into your SIEM and build correlation rules for misuse or account compromise. Use the same pipeline you rely on for export monitoring (Section 3) and code execution telemetry (Section 5).
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 the following.
- 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 Section 8 controls via
disableBypassPermissionsModeanddisableAutoModeso users cannot override 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.
Start with a managed baseline that blocks credential and secret file access. The example below denies common read and write paths for environment files, cloud CLI config, SSH keys, kubeconfig, Terraform vars, and package registry credentials. Adapt the patterns to your stack before rollout.
{
"permissions": {
"deny": [
"Read(**/.env*)",
"Read(**/.dev.vars*)",
"Read(**/*.pem)",
"Read(**/*.key)",
"Read(**/*.p12)",
"Read(**/*.pfx)",
"Read(**/*.keystore)",
"Read(**/*.jks)",
"Read(**/secrets/**)",
"Read(**/credentials/**)",
"Read(**/.aws/**)",
"Read(**/.ssh/**)",
"Read(**/.gcp/**)",
"Read(**/.azure/**)",
"Read(**/.config/gcloud/**)",
"Read(**/config/database.yml)",
"Read(**/config/credentials.json)",
"Read(**/config/master.key)",
"Read(**/config/secrets.yml)",
"Read(**/.npmrc)",
"Read(**/.pypirc)",
"Read(**/.netrc)",
"Read(**/.git-credentials)",
"Read(**/.docker/config.json)",
"Read(**/*-secrets.yaml)",
"Read(**/*-secret.yaml)",
"Read(**/.gradle/gradle.properties)",
"Read(**/gradle.properties)",
"Read(**/.m2/settings.xml)",
"Read(**/kubeconfig)",
"Read(**/.kube/config)",
"Read(**/.terraform/**)",
"Read(**/terraform.tfvars)",
"Read(**/*.tfvars)",
"Read(**/.vault-token)",
"Read(**/.pgpass)",
"Read(**/.my.cnf)",
"Read(**/docker-compose.override.yml)",
"Read(**/.dockercfg)",
"Read(**/.bundle/config)",
"Read(**/.gem/credentials)",
"Read(**/.cargo/credentials)",
"Write(**/.env*)",
"Write(**/secrets/**)",
"Write(**/.ssh/**)",
"Write(**/credentials/**)",
"Write(**/.aws/**)",
"Write(**/.gcp/**)",
"Write(**/.azure/**)",
"Write(**/.kube/**)",
"Write(**/.docker/**)",
"Write(**/*.pem)",
"Write(**/*.key)"
]
}
}
Layer this on top of Section 8 permission mode lockdown, org-locked login, MCP server restrictions, and network controls as your requirements mature.
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 with 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 with documented risk acceptance | Known prompt injection and data leakage risk |
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 it accesses, who controls the review prompts, and how you prevent it from becoming a backdoor for sensitive code exposure.
Claude Code supports comprehensive OTEL integration, including 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 |
|---|---|---|
| Skills (all settings) | Disable by default. Require security review before enabling code execution, user-created skills, or org-wide sharing | Medium |
Skills can contain executable code, an unsanctioned execution path without review. Keep all skill settings disabled until security approves a documented use case. Build a formal governance process before enabling org-wide sharing.
12. Configuration Checklist
Work through onboarding items first, then the 30-day configuration list. Details for each item are in the sections above.
At Onboarding (Do These First)
- Enforce SSO via your identity provider and 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, then 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 for owner export notifications and 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.
Pair this evidence model with the Section 12 checklist to turn recommendations into a durable operating standard.
Final Thoughts
The goal is a defensible posture, not a perfect score. Most high-priority items are straightforward to disable. What holds up under pressure is the process work (connector approval, IR planning, managed settings baselines, and review cadence documented in Sections 12 and 13).
If you are working through this at your organization and want to discuss specific settings or use cases, reach out.