Implement Claude Enterprise security with practical guidance on SSO, roles, connectors, project sharing, retention, audit logs, and access testing.
An employee asks Claude to summarize a customer escalation. The answer might draw on a support ticket, a shared document, and an internal conversation. Each source has its own access rules. The summary creates another copy of information, and a follow-up request might ask Claude to change a record or send a message.
That is the practical scope of Claude Enterprise security: who can use it, what information it can reach, what actions it can take, and what happens to the resulting content.
As we explain in our introduction to Avaratak's Claude practice, implementation starts with understanding the workflow and its boundaries. Buying an Enterprise plan gives the organization controls to configure; the rollout must turn them into working boundaries.
Choose an initial business workflow and document its boundaries. A support team summarizing escalations needs a different design from an engineering team modifying repositories or a finance team reviewing invoices.
Inventory every Claude surface in scope, including web, desktop, Cowork, Claude Code, and custom applications. Give each an explicit control owner and validation plan.
Configure single sign-on, verify the required domains, test sign-in, and explicitly require SSO when the rollout is ready. Domain verification alone does not enforce SSO. Apply the organization's MFA and relevant access policies through its identity provider. Anthropic's SSO setup guide
Then decide how membership will be maintained. Just-in-time provisioning creates access at login, but it does not provide automatic removal when someone is unassigned from the identity-provider application. SCIM supports automatic provisioning and deprovisioning. Choose the mechanism that matches the organization's joiner, mover, and leaver process. Provisioning behavior
Before enabling synchronization or changing group mappings, review existing members and administrator assignments. Pilot the change with test accounts, preserve a supported recovery path, and document who owns certificate renewal.
Test departure as a complete workflow: block sign-in, confirm membership removal, revoke relevant connector authorization, and check any active sessions. Record observed propagation times so the incident response team knows what to expect.
Keep broad administration with a small, accountable group. Delegate billing, privacy, or other administration only where the role requires it. Treat permission to manage identity and roles as privileged: Anthropic documents that a person with Identity & Access: Can manage can edit their own role and expand their access. Custom roles and administrative permissions
For business users, a narrow baseline role with additional permissions for approved workflows is a useful starting point. Remember that custom-role grants combine. If one role permits a capability, another role cannot remove that grant. Review the View effective role result for people who belong to multiple groups. How custom roles combine
Configuration also depends on the member's assigned role type. Custom-role controls apply to members set to Custom; users retaining built-in roles receive those roles' permissions. Establish group coverage before moving members, and verify that the intended restrictions actually apply. Role-based permission setup
For user-authorized connectors, Claude remains bounded by the person's access in the connected system. Allowing an action in Claude does not grant missing permission in the source application. Review source access before connecting it, especially broad folders, shared drives, and inherited group membership. Connector permission boundaries
For organizations that also connect Jira or Confluence, our guide to auditing permissions before AI agents use them describes source-access problems worth reviewing.
Define an action policy for each connection. A sensible initial support workflow might allow searching tickets and reading approved documentation, require confirmation before creating a ticket, and block deletion or outgoing messages.
Claude's tool permissions include Always allow, Needs approval, and Blocked. Organization-wide tool policy supplies a ceiling that custom-role grants cannot exceed. Inspect existing settings carefully: when connector permissions are enabled, existing custom roles receive an All connectors: Always allow baseline, bounded by organization policy. Narrow that baseline deliberately. Connector policy setup
Custom Model Context Protocol (MCP) integrations need additional scrutiny. A shared API key gives everyone using that connector the credential's access. Use narrowly scoped credentials, enforce authorization in the service, and review tools whenever their behavior changes. Treat retrieved instructions as untrusted input and test prompt-injection attempts. Custom connector security
Organization connector permissions govern organization-added connections. Locally run connectors and Cowork on third-party platforms sit outside that boundary. Review local files, credentials, commands, and network access separately for the deployment in scope. Connector control coverage
For consequential changes, build a review step that shows the target, proposed action, and relevant content before execution. A confirmation is useful only when the person can assess what they are approving.
Claude projects have their own sharing boundary. On Team and Enterprise plans, a public project is available to the organization; a private project is limited to invited members. Can view includes access to project knowledge and instructions. Can edit also permits changes to knowledge, instructions, and member settings. Assign these permissions according to the sensitivity of the material. Project visibility and sharing
When someone uploads a document or pastes a summary, review the audience for that copy. Access to the original source and permission to redistribute its contents are separate decisions.
Review existing shares during cleanup. Turning off project sharing prevents new sharing, while existing direct shares remain. Existing public projects become private. Remove inappropriate access explicitly and verify the result with a restricted account. Organization sharing controls
Anthropic states that commercial chats and coding sessions are not used for model training by default. Participation in the Development Partner Program, explicit training opt-ins, or submitted feedback can change how submitted material is used. Explain these distinctions in employee guidance. Commercial data and model training
Define approved data categories, prohibited submissions, and review requirements for sensitive work. Include connector providers and downstream destinations in that assessment.
Configure retention for both standalone chats and projects. Anthropic documents indefinite retention by default and a minimum configurable period of 30 days. Project retention governs chats inside projects, even when only chat retention has been configured. Activity can reset the retention clock, and shortening a period schedules older content for permanent deletion. These settings have defined product coverage and exceptions; review them before applying a policy. Enterprise retention controls
Choose periods with the people responsible for records, privacy, and business operations. Document how exported content will be governed after it leaves Claude.
Assign responsibility for monitoring before expanding access. Decide which events require investigation, who receives them, and how evidence will be protected.
Enterprise audit-log exports provide event records, with up to 180 days available through the documented export process. They do not include chat or project titles and content. Audit-log coverage
The Compliance API provides a separate, privileged route to supported activity and content, including chat data and files. Only the Primary Owner can enable it. Its coverage has explicit exclusions, so verify the deployment modes your organization uses. Protect its keys and exported content as sensitive infrastructure. Compliance API access and coverage
Use monitoring records for investigation, and enforce preventive controls before data access or tool execution.
Create an incident runbook covering exposed information, unexpected tool actions, compromised credentials, and incorrect access. Name the people authorized to disable a connection, revoke credentials, preserve evidence, and assess impact.
Use synthetic records and representative accounts to test the intended workflow and its restricted states:
Keep the results with the configuration record. Repeat relevant tests when groups, connectors, tools, or deployment modes change.
Avaratak's Claude consulting practice helps organizations turn these decisions into a rollout their own teams can operate. The useful starting point is a defined workflow, named owners, and acceptance criteria that demonstrate who can see and do what.
If your organization is preparing a Claude Enterprise rollout or reviewing an existing implementation, book a 30-minute consultation with Avaratak to work through identity, permissions, integrations, and governance.
Guides only take you so far. Bring the messy specifics and we will tell you what we would actually do.
.webp)