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 17 is the execution checklist. Section 18 covers how to document decisions and keep them from drifting after Anthropic ships platform updates.
1. Identity and Access Management
| Setting | Recommendation | Priority |
|---|---|---|
| SSO | Enable SSO, then require it for both Claude and the Anthropic Console | Critical |
| User provisioning | SCIM directory sync from your IdP (Okta preferred), mapped to Owner / Admin / User roles | Critical |
| Verified domains | Register your organization's domains | Critical |
| Restrict verified domain connectors | Enable | Important |
| Restrict organization creation | Enable | Important |
| Message the Anthropic team | Enable | Recommended |
| Seat assignment | Assign Chat + Claude Code to all users | Recommended |
| Owners | 3 to 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 |
Enable SSO, and then take the second step teams often miss by requiring SSO for Claude and for the Anthropic Console separately. These are distinct toggles, and leaving the Console on password auth leaves your admin plane weaker than your user plane. Provision users via SCIM directory sync from your IdP (Okta is the integration we see work most smoothly), with directory groups mapped to the three Claude roles (Owner, Admin, User) so access follows your joiner/mover/leaver process automatically. Register your corporate domains as verified domains so accounts are captured into the tenant.
Three organization-level settings round out the access baseline.
- Restrict organization creation. Prevents employees from spinning up new, unmanaged Claude organizations under your corporate domain, the classic shadow-tenant problem. Enable it.
- Restrict verified domain connectors. Limits connector usage tied to your verified domains so users cannot wire tenant data into arbitrary external endpoints. Enable it.
- Message the Anthropic team. Enable this so admins have a direct escalation path into Anthropic. You will want it mid-incident, not after.
On seat assignment, assign both Chat and Claude Code to all users. Splitting entitlements by team creates a support burden without a security benefit. The meaningful controls are the capability and product settings below, not who holds a seat.
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 to 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 6.
2. Usage and Spend Governance
| Setting | Recommendation | Notes |
|---|---|---|
| Per-user usage limit | Start at $1,000 per employee | Sweet spot validated over ~6 months of production use |
| Pending limit requests | Manual approval initially, then a Slack-notification triage pipeline | Keep a human in the loop either way |
| Custom spend limits | Tie increases to team budgets, not the global pool | Makes overspend an accountable team decision |
After roughly six months of running Claude Enterprise across real engineering and business teams, a standard limit of $1,000 per employee has proven to be the sweet spot. It is high enough that normal power users never hit it, and low enough that a runaway agentic workflow or a compromised account produces a visible spike instead of a quiet five-figure surprise. Treat the limit as an anomaly tripwire, not just a budget control.
When users hit their limit they generate pending increase requests. Start with manual review, since the first month of requests tells you who your heavy users are and what they are doing. Once volume is understood, build a triage pipeline that routes requests into Slack for approval so they are handled within hours instead of sitting in the admin console. Two rules keep this governable:
- Custom limits attach to team budgets, not the global pool. When an increase is approved, the spend is attributed to the requesting team's budget. This keeps cost ownership with the team that benefits and prevents the global limit from silently ratcheting upward.
- Every increase leaves an artifact. The Slack approval thread is your evidence trail, recording who asked, why, who approved, and for how much.
3. Data and Privacy
| Setting | Recommended State | Risk |
|---|---|---|
| Chat retention | Unlimited | Deliberate choice. Retained history is your only conversation-level record for investigations |
| 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 | Enable | Low. Internal collaboration benefit outweighs the risk |
| Share chats using connectors | Disable | High. Can expose connector data (PII, financials) to unintended recipients |
| Public projects | Disable | High. Exposes internal content externally |
| Inference hooks (beta) | Enable | See Section 4. Your best conversation-level visibility mechanism |
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. Plain chat sharing (without connector data) is a genuine collaboration win, so leave it enabled.
This may feel counterintuitive from a data-minimization standpoint, but conversation content is not captured in audit logs (Section 5). Retained chat history is the only conversation-level record you have when investigating an incident, an insider issue, or a data handling question. Unlimited retention, paired with inference hooks (Section 4), is the pragmatic call for most enterprises. If your legal team requires a shorter retention window, document the investigation gap it creates as an accepted risk.
4. Inference Hooks (Beta)
| Setting | Recommendation | Notes |
|---|---|---|
| Inference hooks | Enable | Beta. Streams inference events to an endpoint you control |
| Endpoint URL | HTTPS endpoint in your environment | Terminate into your logging/DLP pipeline |
| Custom request header | Set one (e.g. x-api-key) and validate it server-side |
This is your endpoint's authentication |
| Endpoint test | Run the console test before rollout | Confirms delivery before you depend on it |
Inference hooks let your organization receive inference activity from your tenant at an HTTP endpoint you control, as it happens. That closes the single biggest monitoring gap in Claude Enterprise, since audit logs capture access metadata but not conversation-level activity (Section 5). With a hook endpoint feeding your SIEM or DLP pipeline, you finally get organization-side visibility into how the platform is actually being used, on infrastructure you own and with retention you control.
Configuration is straightforward, but each step has a security decision embedded in it.
- Endpoint URL. Point the hook at an HTTPS endpoint in your environment, typically a lightweight receiver that validates, buffers, and forwards events into your logging pipeline. Do not point it directly at a third-party SaaS ingest URL without thinking through where that data now lives.
- Custom request header. The console lets you attach a custom header to every delivery, such as
x-api-keywith a secret value. This header is the authentication for your receiver. Validate it server-side and reject anything without it, otherwise anyone who discovers your endpoint URL can inject fake events into your pipeline. Store the value in your secrets manager and rotate it like any other API credential. - Test the endpoint. Use the built-in test from the admin console to send a test delivery and confirm your receiver accepts it before enabling org-wide. A hook that silently fails delivers exactly the false confidence you set it up to avoid.
There are two operational realities to plan for. First, hook payloads can contain the most sensitive data in your tenant, so treat the receiving pipeline with the same data classification as the conversations themselves (encryption at rest, tight access control, its own retention policy). Second, this is a beta feature, and payload formats and delivery behavior can change between our reviews. Alert on delivery-failure and event-volume anomalies so a schema change or outage does not quietly blind you, and re-verify the configuration whenever Anthropic ships changes to the feature.
5. 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 remains a significant platform-level gap. 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. Prompts are not logged by the platform and cannot be exported after the fact, so the only conversation-level records you will have are the ones you capture yourself. Plan accordingly.
- Enable inference hooks (Section 4) for Claude, stand up OTEL telemetry (Section 14) for Claude Code, and set chat retention to unlimited (Section 3). Together these are your compensating controls for this gap.
- 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, including via the "Message the Anthropic team" channel you enabled in Section 1.
- 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.
6. 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 3).
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. To pressure-test connector risk scenarios before wide rollout, a red team engagement can surface how attackers would exploit misconfigured access.
7. 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, which is why the controls around them matter more than the toggles themselves.
| Setting | Recommendation | Risk Level |
|---|---|---|
| Cloud code execution | Allow (Updated) | Medium |
| Network egress | Allow (Updated) | Medium |
| Domain allowlist | None (Updated). Rely on monitoring and managed settings instead | Medium |
Our original guidance was default-off egress with a package-manager-only allowlist. After six months of running the locked-down posture in production, we have changed the recommendation to allow cloud code execution and network egress and skip the domain allowlist. Two things drove the change. First, the allowlist created constant friction. Legitimate developer workflows break on every new dependency mirror or API, and the exception queue trained teams to rubber-stamp additions, which defeats the control. Second, the meaningful protections live elsewhere, in the sandboxed runtime, per-user opt-in, secret-access denials in managed settings (Section 12), and telemetry. If you operate those layers, the allowlist adds cost without adding much security. Regulated environments that cannot accept open egress should keep the allowlist and accept the operational overhead as the price of that posture, but make it an explicit decision, not a default.
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.
With egress open, security comes from the layers around it, and that trade is what makes the Updated recommendation defensible.
- Population control. Restrict access with RBAC and require per-user opt-in so only approved groups can run code.
- Secret protection. Enforce managed settings that block access to sensitive files such as
.env, keys, and credential artifacts (Section 12). With open egress, this is your primary exfiltration control, and it is not optional. - Telemetry and alerting. Send execution and audit events to your SIEM or OTEL pipeline and alert on unusual domain access patterns and data volumes.
- Inference visibility. Inference hooks (Section 4) give you the conversation-side record when investigating suspicious execution activity.
- Change control. Document the open-egress decision itself as an accepted risk with an owner and a review date.
If your team cannot operate these compensating layers, do not adopt the open posture. Keep network egress disabled and limit code execution to a smaller trusted group.
8. Capabilities: Chat, Search, Artifacts, and Memory
| Setting | Recommendation | Risk Level |
|---|---|---|
| Chat | Allow | Low. This is the product |
| Web search | Allow | Medium. Document the risk acceptance |
| Ask Org | Allow | Low-Medium. Respects underlying access controls |
| Interactive content (image rendering) | Disable | High. Known data exfiltration vector |
| Artifact connectors | Enable (Updated) | Medium. Enable with the guardrails below |
| Inline visualizations | Enable (Updated) | Low |
| Memory | Enable for your team | Medium. Persistent context needs offboarding hygiene |
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. This recommendation has not changed, and with connectors and open egress in play it matters more than ever.
Our original guidance was to evaluate artifact connectors before enabling. Having now run them in production, we recommend enabling both artifact connectors and inline visualizations. The productivity value is real, and the risks are manageable with process rather than a platform toggle. The failure modes we flagged originally still apply, so put these guardrails in place:
- Data injection. External sources can inject content into artifacts users trust. Maintain an approved-source list and label external content clearly.
- Trust boundary confusion. Artifacts that mix internal connector data with external APIs get shared as trusted internal reports. Use provenance tags and approval for mixed-source artifacts.
- Oversharing. Customer-specific artifacts shared broadly because they look generic. Restrict sharing scope via RBAC and review periodically. For Claude Code artifacts specifically, external sharing stays off (Section 13).
Ask Org lets users query across organizational knowledge. Allow it, since it surfaces only what the querying user can already access, so the control that matters is the connector RBAC design from Section 6, not this toggle. Memory gives Claude persistent context across sessions and meaningfully improves output quality for your team. Enable it with two caveats in mind. Memory becomes another store of potentially sensitive context, so include it in your data classification and offboarding checklists, and make sure users know memory persists so they are not surprised by what Claude recalls.
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 the other controls in place. The important step is to document this as a formal risk acceptance rather than an oversight.
9. Session Management and Endpoint Security
| Setting | Recommendation | Risk Level |
|---|---|---|
| Session length | Default is acceptable for most orgs (Updated). Shorten at your discretion | Low-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 |
Our original guidance recommended an 8 to 12 hour maximum session length. In practice, once SSO is required for both Claude and the Console (Section 1) and device trust is enforced through your IdP's conditional access, session lifetime is already governed by your IdP policy, and a separate Claude-side timeout mostly adds re-authentication friction without changing the actual exposure. We now consider a shortened session length optional and leave it to your discretion. If your IdP session policy is weak or you cannot enforce device trust, the Claude-side maximum is worth keeping as a backstop.
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 5), inference hook events (Section 4), and code execution telemetry (Section 7).
10. Models
| Setting | Recommendation | Notes |
|---|---|---|
| Model availability | Enable all models for all roles | Cost is governed by usage limits, not model restrictions |
Enable all available models for all roles. Every model in the tenant operates under the same data handling terms, connector permissions, and capability settings, so restricting model access does not reduce your data exposure. It just pushes users toward whichever model is left enabled. Cost is the one legitimate concern, and that is better handled by the per-user usage limits in Section 2 than by gating model families. Revisit only if Anthropic ships models with materially different data handling or capability profiles.
11. 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.
12. 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 11 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 11 permission mode lockdown, org-locked login, MCP server restrictions, and network controls as your requirements mature. Teams without dedicated security engineering capacity can work with embedded security engineers to build and maintain this baseline before rollout.
13. Claude Code Platform Settings
These are the org-level product settings for Claude Code in the admin console, distinct from the desktop permission modes (Section 11) and the managed settings.json baseline (Section 12).
| Setting | Recommendation | Notes |
|---|---|---|
| Desktop / mobile / web access | Enable all three | Meet developers where they work |
| Remote control | Disable | High risk, no typical enterprise use case |
| Cloud sessions | Allow, with cloud sharing enabled | Collaboration benefit within the tenant |
| Quick setup | Disable | Uses users' GitHub credentials to launch cloud sessions |
| Fast mode | Disable | Increases token consumption against your usage limits |
| Routines | Enable | Scheduled agents; ensure activity lands in your telemetry |
| Artifacts | Enable, external sharing disabled | Keeps Claude Code output inside the tenant |
| Channels | Disable | No current use case; reduce surface until one exists |
Remote control lets a Claude Code session on one device be driven from another. There is no typical enterprise use case that justifies the attack surface, since a compromised phone or browser session becomes a path to a developer workstation. Keep it disabled across desktop, mobile, and web.
Quick setup streamlines launching cloud sessions by using the user's GitHub credentials. That convenience puts personal GitHub credentials in the cloud-session launch path, outside the OAuth connector governance you built in Section 6. Disable it and have users launch cloud sessions through the standard flow.
Enable desktop, mobile, and web access. Restricting surfaces does not reduce risk when the same account and controls apply to each, and it just pushes developers to personal accounts. Allow cloud sessions with cloud sharing on, since shared sessions stay inside the tenant. Enable routines, and make sure scheduled runs are covered by the same OTEL telemetry as interactive sessions, because an agent running on a schedule with nobody watching is exactly where you want monitoring. Enable artifacts but disable external sharing. Claude Code artifacts frequently contain code, architecture detail, and internal data, and external sharing is one click from a public link. Disable fast mode (cost, not security) and channels (no current use case, so enable it when one shows up, not before).
14. Claude Code Telemetry (OTEL)
Claude Code ships a full OpenTelemetry layer that exports metrics, events, and beta distributed traces to a collector you run. Enabled fleet-wide through managed settings, it is the closest thing you have to a research instrument for how your organization actually uses Claude, and it is the telemetry backbone this guide has been pointing at in Sections 7 and 13.
| Setting | Recommendation | Notes |
|---|---|---|
| Telemetry | Enable fleet-wide via managed settings | Metrics and events flow to an OTLP endpoint you control |
| Collector endpoint | Lock it in managed settings | Claude Code strips conflicting user variables so telemetry cannot be redirected |
| Content capture (prompts, responses, tool detail) | Keep off (the default) unless disclosed and governed | Each capture level is a separate, deliberate opt-in |
| Team attribution | Tag with resource attributes (department, team, cost center) | Enables per-team adoption and cost research |
The exported metrics cover session counts, cost in USD, token usage, lines of code changed, commits created, and accept/reject decisions on proposed code edits. Events fire for each user prompt, API request, tool execution, and permission decision, and they share a prompt identifier so you can reconstruct the shape of a session without reading its content. Tag the pipeline with resource attributes for department, team, and cost center, and you can answer with data the questions that usually get answered with survey anecdotes. You can see which teams have adopted Claude Code and which have stalled, what a team's spend actually buys in accepted edits and shipped commits, which tools and MCP servers get used, and where permission prompts are being rejected. All of it works with content redaction left on.
By default, prompts and responses export as redacted placeholders and tool parameters are omitted entirely. Dedicated opt-in variables (OTEL_LOG_USER_PROMPTS, OTEL_LOG_ASSISTANT_RESPONSES, OTEL_LOG_TOOL_DETAILS, and at the far end OTEL_LOG_RAW_API_BODIES) turn on progressively deeper content capture, up to full API request and response bodies. The platform treats content capture as a deliberate decision, and so should you. Flipping those variables on quietly turns a usage study into employee monitoring, with real consequences for trust, and in many jurisdictions for works-council and privacy-law obligations. Most research questions are answerable with redaction on. If you believe you genuinely need content, treat it like deploying a DLP tool. Disclose it in policy, scope it to a defined purpose, restrict who can read the pipeline, and set a retention period.
The mechanics are documented in Anthropic's monitoring guide, and we are deliberately not walking through the setup here. The hard part is everything around the config. You have to decide which attributes your questions actually require, which capture level is defensible for those questions, how to disclose the program to employees, where the data lands, who can query it, and how long it lives. Those are the decisions that determine whether you end up with an adoption dashboard your engineers trust or a surveillance program they resent. If you want to understand how your teams use Claude without crossing that line, this is a pipeline we design and build for clients, and we are happy to talk through it. Reach out.
15. Additional Features
| Feature | Recommendation | Notes |
|---|---|---|
| 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 |
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.
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. Section 14 covers what the telemetry layer exports, what stays redacted by default, and the trust decisions involved in going deeper.
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.
16. 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.
17. 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)
- Enable SSO, then require SSO for Claude and require SSO for the Console
- Set up SCIM directory sync from your IdP (Okta preferred) mapped to Owner / Admin / User
- Register your verified domains and restrict allowed email domains to corporate domain(s) only
- Enable restrict organization creation and restrict verified domain connectors
- Enable "Message the Anthropic team" and assign Chat + Claude Code seats to all users
- Set chat retention to unlimited and audit log retention to permanent
- Disable location metadata, rate chats, share chats using connectors, and public projects (leave plain chat sharing on)
- Disable interactive content (image rendering)
- Confirm bypass permissions mode and auto permissions mode are both off in Claude Code Desktop
- In Claude Code platform settings, disable remote control, quick setup, fast mode, channels, and external artifact sharing
Short-Term Configuration (First 30 Days)
- Enable inference hooks by standing up a receiver, setting a custom auth header (e.g.
x-api-key), and running the console endpoint test - Configure the managed settings.json baseline for Claude Code, which is mandatory before allowing open network egress
- Set per-user usage limits (start at $1,000 per employee) and review pending increase requests manually
- Define a connector approval process, then audit and justify any currently enabled connectors
- Enable web search, Ask Org, artifact connectors, inline visualizations, and memory, with the guardrails from Section 8
- Enable all models for all roles
- 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
- Build the Slack-based triage pipeline for usage limit requests, with approved increases tied to team budgets
- Implement RBAC group design tied to connector exposure, and revalidate group-to-connector mappings as Anthropic evolves the beta
- Stand up OpenTelemetry monitoring (Section 14) before enabling agentic Claude Code features at scale, confirm routines are covered, and leave content capture off unless it is disclosed and governed
- Evaluate Claude Code Review for GitHub PRs as a security-positive feature
- Establish periodic review cycles for admin accounts, active connectors, and enabled features
- Re-review the full settings surface after each monthly console update, since new settings frequently ship enabled by default
- Submit feature requests to Anthropic for owner export notifications and conversation content in audit logs
18. 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, and with Anthropic shipping admin console changes roughly monthly, drift is the default state, not the exception. Every settings-by-settings decision in this guide has a shelf life of about one release cycle. This is the kind of systematic review cycle a platform security program is designed to sustain, keeping the configuration current as the platform ships updates rather than setting it once.
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
At a minimum, follow this governance cadence.
- Quarterly. Review admins, owners, connector states, and Claude Code managed settings.
- Monthly, after platform changes. Anthropic ships console updates roughly once a month. Revalidate controls each cycle, since new settings frequently arrive enabled by default, and a control you configured in Q1 may have new sub-settings by Q2.
- 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 17 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 configure. What holds up under pressure is the process work (connector approval, IR planning, managed settings baselines, and the review cadence documented in Sections 17 and 18), along with the discipline to redo the review every time Anthropic ships a console update, which is roughly monthly.
That cadence is the honest challenge with this guide, because it describes a moving target. Between the original publication and this review, our own recommendations changed on network egress, artifact connectors, and session length, not because the first calls were wrong but because the platform and six months of production experience changed the trade-offs. Most enterprise security teams do not have spare capacity to re-derive Claude Enterprise best practices every month on top of everything else they own.
That is work we do for clients. If you want a team that has already made these calls in production tenants to run your rollout (configure the baseline, stand up the inference hook and telemetry pipelines, build the governance model, and keep it current as the console changes), reach out. And if you are working through it yourself and just want a sanity check on a specific setting, we are happy to have that conversation too.
Written by
Founder of PlatformSecurity and veteran security expert with over a decade of experience in offensive security. Recognized penetration testing specialist who has uncovered critical vulnerabilities in Fortune 500 companies, cloud infrastructure, and enterprise applications. Expert in red team operations, cloud security, and vulnerability research with a track record of responsible disclosures and high-impact security findings.