v1.0.2-draft AI Drafted
Home / Guides / Anthropic

Anthropic Platform Hardening Guide

AI/ML Platform Last updated: 2026-08-08

Platform-wide security hardening for Anthropic — the Common Controls hub (SSO, organization roles, admin API keys, integration governance) shared by the Claude Enterprise, Claude Code, and Claude API & Console product guides.

Product Docs API Docs
Claude Enterprise Administrator GuideTenant Restrictions (Network Control)
Code Packs: API Scripts Config SDK
View:

Overview

Anthropic is a multi-product AI platform: the claude.ai chat product (Team/Enterprise plans), Claude Code (the agentic coding tool), and the Claude API with its admin Console. Each product has a distinct hardening surface, so each has its own guide — this hub carries the Common Controls that span them: organization identity (SSO, roles), admin API key protection, and third-party integration governance. Anthropic provides a comprehensive Admin API for programmatic organization management alongside the web Console.

Product guides: Claude Enterprise (claude.ai) · Claude Code · Claude API & Console

Intended Audience

  • Security engineers managing AI tools and API integrations
  • IT administrators configuring Claude for enterprise teams
  • GRC professionals assessing AI compliance posture
  • Third-party risk managers evaluating AI platform controls

How to Use This Guide

  • L1 (Crawl): Essential controls for all organizations using Claude
  • L2 (Walk): Enhanced controls for security-sensitive environments
  • L3 (Run): Strictest controls for regulated industries

Scope

This hub covers platform-wide Anthropic controls: organization authentication (SSO/SCIM), least-privilege organization roles, admin API key protection, and third-party integration governance (pending invites, integration risk). Product-specific hardening lives in the product guides: Claude Enterprise for claude.ai workspace administration, Claude Code for the agentic coding tool (managed settings, MCP, sandboxing, CI/CD), and Claude API & Console for API keys, workspaces, data residency, and spend. Model behavior configuration (system prompts, safety settings) is out of scope.

Table of Contents

  1. Authentication & Access Controls
  2. Third-Party Integration Security
  3. Compliance Quick Reference

Product guides: Claude Enterprise (claude.ai) · Claude Code · Claude API & Console

Products in This Platform

Anthropic is a multi-product platform. This guide is the Common Controls hub — the platform-wide controls that apply across every Anthropic product. Product-specific controls live in their own guides:

Product Guide Covers
Common Controls (this guide) — Organization SSO & SCIM, least-privilege organization roles, admin API key protection, third-party integration governance
Claude Enterprise (claude.ai) Claude Enterprise guide Identity & provisioning, audit & compliance export, connectors & extensions, spend governance
Claude Code Claude Code guide Managed settings & policy deployment, extensions & supply chain, execution isolation & sandboxing, threat defense, monitoring & incident response
Claude API & Console Claude API & Console guide API key management, workspace security, data security & privacy, monitoring & usage controls

1. Authentication & Access Controls

1.1 Enforce Single Sign-On

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 6.3, 12.5
NIST 800-53 IA-2, IA-8

Description

Configure SAML 2.0 or OIDC-based SSO to authenticate Claude users through your corporate identity provider. Anthropic integrates SSO via WorkOS, supporting domain verification and just-in-time provisioning.

Rationale

Why This Matters:

  • Centralizes authentication and user lifecycle management
  • Enables MFA enforcement through your IdP’s Conditional Access policies
  • Eliminates standalone Claude passwords and reduces credential sprawl
  • Automatic deprovisioning when users leave the organization

Attack Prevented: Credential theft, unauthorized access, orphaned accounts

Prerequisites

  • Claude Team or Enterprise subscription
  • SAML 2.0 or OIDC compatible identity provider (Okta, Azure AD, OneLogin, Google Workspace)
  • Organization Admin access to Claude Console
  • Domain ownership for domain verification

ClickOps Implementation

Step 1: Access Identity & Access Settings

  1. Navigate to: console.anthropic.com → Settings → Identity & Access
  2. Click Configure SSO

Step 2: Configure SSO via WorkOS

  1. Select your IdP type (SAML 2.0 or OIDC)
  2. Enter Identity Provider details:
    • SSO URL: Your IdP’s SSO endpoint
    • Entity ID / Issuer: IdP entity ID
    • Certificate: X.509 certificate from IdP (for SAML)
  3. Download Claude’s Service Provider metadata for IdP configuration
  4. Map required user attributes (email, name)

Step 3: Configure Your IdP (Example: Okta)

  1. In Okta Admin: Applications → Create App Integration → SAML 2.0
  2. Enter Claude’s ACS URL and Entity ID from Step 2
  3. Configure attribute statements:
    • email → user.email
    • name → user.displayName
  4. Assign users/groups

Step 4: Verify Domain and Enforce SSO

  1. Complete domain verification (DNS TXT record)
  2. Enable Require SSO for all users
  3. Test login before full enforcement

Time to Complete: ~30 minutes

Code Implementation

Code Pack: API Script
hth-anthropic-claude-1.01-enforce-sso.sh View source on GitHub ↗ 
# Validate SSO enforcement by listing org members and checking for
# users who may not have authenticated via SSO.
# Note: The Admin API does not expose SSO status directly.
# This audit lists all members so you can cross-reference with your IdP.
info "Listing all organization members for SSO cross-reference audit..."
MEMBERS=$(anthropic_list_all "/v1/organizations/users") || {
  fail "1.1 Failed to list organization users"
  summary; exit 0
}

MEMBER_COUNT=$(echo "${MEMBERS}" | jq 'length')
info "Found ${MEMBER_COUNT} organization members"

echo "${MEMBERS}" | jq -r '.[] | "\(.name)\t\(.email)\t\(.role)"' | \
  column -t -s $'\t' -N "NAME,EMAIL,ROLE"

pass "1.1 Member list retrieved — cross-reference with IdP to verify SSO coverage"

Validation & Testing

  1. Attempt login without SSO — should be redirected to IdP
  2. Complete SSO login — should succeed and land in Claude
  3. Remove user from IdP group — should lose Claude access
  4. Cross-reference org member list (API) with IdP directory

Expected result: All users authenticate via SSO; no standalone password logins

Monitoring & Maintenance

Ongoing monitoring:

  • Monitor IdP for failed authentication attempts to Claude
  • Review pending invites monthly for unauthorized additions

Maintenance schedule:

  • Monthly: Review org member list vs IdP directory
  • Quarterly: Rotate SSO certificates before expiration
  • Annually: Re-verify domain ownership

Operational Impact

Aspect Impact Level Details
User Experience Low Users authenticate via familiar IdP login
System Performance None No performance impact
Maintenance Burden Low Standard IdP maintenance applies
Rollback Difficulty Easy Disable SSO enforcement in Console

Compliance Mappings

Framework Control ID Control Description
SOC 2 CC6.1 Logical access security over protected information assets
NIST 800-53 IA-2, IA-8 Identification and authentication (org users + non-org users)
ISO 27001 A.9.2.1 User registration and de-registration

1.2 Enforce Least-Privilege Organization Roles

Profile Level: L1 (Crawl)

Framework Control
NIST 800-53 AC-6, AC-6(1)
SOC 2 CC6.1, CC6.3

Description

Assign the minimum necessary organization role to each user. Anthropic provides six organization roles: user, developer, billing, admin, claude_code_user, and managed. Limit the admin role to a small number of trusted operators.

Rationale

Why This Matters:

  • The admin role can provision Admin API keys, manage all workspaces, and remove users
  • Admins automatically inherit workspace_admin in every workspace
  • The Admin API deliberately prevents assigning the admin role programmatically — a security design decision
  • Admins cannot be removed via API — only through the Console

Attack Prevented: Privilege escalation, unauthorized admin key provisioning, insider threat

Prerequisites

  • Organization Admin access
  • Current member inventory with role justifications

ClickOps Implementation

Step 1: Review Current Role Assignments

  1. Navigate to: console.anthropic.com → Settings → Members
  2. Review each member’s role
  3. Document justification for each admin and billing role holder

Step 2: Downgrade Excessive Privileges

  1. For each user with unnecessary admin access:
    • Click the user → Edit Role
    • Select developer or user as appropriate
  2. Ensure at least 2 (but no more than 3) admins remain for redundancy

Step 3: Establish Role Assignment Policy

  1. Define criteria for each role level
  2. Require approval for admin role assignments
  3. Schedule quarterly role reviews

Time to Complete: ~15 minutes

Code Implementation

Code Pack: API Script
hth-anthropic-claude-1.02-enforce-least-privilege-roles.sh View source on GitHub ↗ 
# Audit organization member roles — flag users with admin or billing roles
info "Auditing organization member roles..."
MEMBERS=$(anthropic_list_all "/v1/organizations/users") || {
  fail "1.2 Failed to list organization users"
  summary; exit 0
}

# Count by role
ADMIN_COUNT=$(echo "${MEMBERS}" | jq '[.[] | select(.role == "admin")] | length')
BILLING_COUNT=$(echo "${MEMBERS}" | jq '[.[] | select(.role == "billing")] | length')
DEVELOPER_COUNT=$(echo "${MEMBERS}" | jq '[.[] | select(.role == "developer")] | length')
USER_COUNT=$(echo "${MEMBERS}" | jq '[.[] | select(.role == "user")] | length')
TOTAL=$(echo "${MEMBERS}" | jq 'length')

info "Role distribution: admin=${ADMIN_COUNT}, billing=${BILLING_COUNT}, developer=${DEVELOPER_COUNT}, user=${USER_COUNT}, total=${TOTAL}"

# Flag excessive admin count
if [[ "${ADMIN_COUNT}" -gt 3 ]]; then
  warn "1.2 ${ADMIN_COUNT} users have admin role — review for least privilege"
  echo "Admins:"
  echo "${MEMBERS}" | jq -r '.[] | select(.role == "admin") | "  \(.name) <\(.email)>"'
else
  pass "1.2 Admin count (${ADMIN_COUNT}) is within recommended limit (<=3)"
fi
# Downgrade a user from a privileged role to 'user' or 'developer'
# Usage: Set USER_ID and TARGET_ROLE before running
if [[ -n "${USER_ID:-}" && -n "${TARGET_ROLE:-}" ]]; then
  info "Updating user ${USER_ID} to role '${TARGET_ROLE}'..."
  anthropic_post "/v1/organizations/users/${USER_ID}" \
    "{\"role\": \"${TARGET_ROLE}\"}" || {
    fail "1.2 Failed to update user role"
    summary; exit 0
  }
  pass "1.2 User ${USER_ID} updated to role '${TARGET_ROLE}'"
fi

Validation & Testing

  1. List all org members via Admin API — count admins <= 3
  2. Verify no user has admin role without documented justification
  3. Attempt to assign admin role via API — should fail (by design)
  4. Verify billing role holders match authorized finance contacts

Expected result: Admin role limited to 2-3 operators; all other users at minimum necessary privilege

Monitoring & Maintenance

Ongoing monitoring:

  • Alert on new admin role assignments (Console audit)
  • Monthly review of role distribution

Maintenance schedule:

  • Monthly: Review member roles via API script
  • Quarterly: Full access review with role justifications

Compliance Mappings

Framework Control ID Control Description
SOC 2 CC6.1, CC6.3 Logical access security; role-based access
NIST 800-53 AC-6, AC-6(1) Least privilege; authorize access for security functions
ISO 27001 A.9.2.3 Management of privileged access rights

1.3 Protect Admin API Keys

Profile Level: L1 (Crawl)

Framework Control
NIST 800-53 IA-5, SC-12
SOC 2 CC6.1, CC6.6

Description

Admin API keys (sk-ant-admin...) grant organization-wide management access. They can only be created through the Console by users with the admin role — a deliberate security design. Treat Admin API keys with the same care as cloud provider root credentials.

Rationale

Why This Matters:

  • Admin keys can list all users, manage all workspaces, disable API keys, and view usage data
  • Unlike standard API keys, admin keys are not scoped to a single workspace
  • Compromise of an admin key exposes the entire organization’s Claude infrastructure

Attack Prevented: Organization takeover, unauthorized workspace creation, data exfiltration via usage APIs

Prerequisites

  • Organization Admin access
  • Secrets management solution (Vault, AWS Secrets Manager, etc.)

ClickOps Implementation

Step 1: Audit Existing Admin Keys

  1. Navigate to: console.anthropic.com → Settings → Admin Keys
  2. Review all provisioned admin keys
  3. Identify and revoke any keys without a clear owner or purpose

Step 2: Establish Key Hygiene

  1. Name each admin key descriptively (e.g., “CI/CD Org Audit — TeamName”)
  2. Store keys in a secrets manager — never in source code, env files, or chat
  3. Rotate admin keys every 90 days

Step 3: Limit Admin Key Provisioning

  1. Restrict admin role to 2-3 trusted operators (see Control 1.2)
  2. Require documented approval before provisioning new admin keys
  3. Log all admin key creation events

Time to Complete: ~10 minutes

Code Implementation

Code Pack: API Script
hth-anthropic-claude-1.03-protect-admin-api-keys.sh View source on GitHub ↗ 
# Admin API keys (sk-ant-admin...) can only be created in the Console.
# This script cannot list admin keys — it validates that the current
# admin key works, and audits all standard API keys for hygiene.
info "Validating admin key by retrieving organization info..."
ORG_INFO=$(anthropic_get "/v1/organizations/me") || {
  fail "1.3 Admin key is invalid or expired"
  summary; exit 0
}

ORG_NAME=$(echo "${ORG_INFO}" | jq -r '.name')
ORG_TYPE=$(echo "${ORG_INFO}" | jq -r '.type')
info "Organization: ${ORG_NAME} (type: ${ORG_TYPE})"
pass "1.3 Admin API key is valid and active"

Validation & Testing

  1. Validate admin key works via /v1/organizations/me endpoint
  2. Verify admin key is stored in secrets manager (not plaintext)
  3. Confirm admin key naming convention is followed

Expected result: All admin keys are named, stored securely, and have documented owners

Compliance Mappings

Framework Control ID Control Description
SOC 2 CC6.1, CC6.6 Logical access; security of system boundaries
NIST 800-53 IA-5, SC-12 Authenticator management; cryptographic key management
ISO 27001 A.9.4.3 Password management system

1.4 Enforce Tenant Restrictions at the Network Edge

Profile Level: L2 (Walk)

Framework Control
CIS Controls 12.3, 3.3
NIST 800-53 SC-7, AC-4

Description

Configure your egress proxy to inject the anthropic-allowed-org-ids header on traffic to Anthropic, so only your organization’s Claude tenants are reachable from corporate networks — blocking personal Claude accounts across web, desktop, API keys, and OAuth (Enterprise and Console).

Rationale

Why This Matters:

  • Product-level controls govern YOUR org; they do nothing about an employee pasting corporate data into a personal Claude account from the corporate network
  • Tenant pinning at the network edge is the platform-wide backstop that the per-product controls (connector verified-domain protection, Claude Code org pinning) each cover only partially
  • Enforcement spans surfaces: claude.ai web, desktop apps, API key usage, and OAuth flows

Attack Prevented: Corporate-data exfiltration through personal Claude tenants on managed networks

ClickOps Implementation

  1. Collect your organization IDs (claude.ai org and Console org)
  2. Configure the egress proxy/SWG to inject anthropic-allowed-org-ids: <org-id>[,<org-id>] on requests to Anthropic domains
  3. Roll out in monitor mode first, then enforce
  4. Pair with Claude Code login pinning (forceLoginOrgUUID) for the client-side half

Time to Complete: ~2 hours with proxy change control

Validation & Testing

  1. From a corporate network, sign-in to a personal Claude account is refused
  2. Org-tenant access works unchanged across web, desktop, and API

Expected result: Only sanctioned tenants reachable from managed networks. (Tenant Restrictions)

Compliance Mappings

Framework Control ID Control Description
SOC 2 CC6.7 Restrict transmission of information
NIST 800-53 SC-7 Boundary protection

2. Third-Party Integration Security

2.1 Audit and Clean Up Pending Invites

Profile Level: L1 (Crawl)

Framework Control
NIST 800-53 AC-2(3)
SOC 2 CC6.2

Description

Regularly audit pending organization invites. Invites in Anthropic expire after 21 days (not configurable). Stale or unauthorized invites should be revoked promptly. The invite system supports role assignment at invite time, so a malicious invite could grant elevated access.

Rationale

Why This Matters:

  • Pending invites represent pre-authorized access that hasn’t been claimed
  • An attacker who gains access to an invited email account could join the organization
  • Invites specify the role upfront — verify that invited roles follow least privilege

Attack Prevented: Unauthorized organization access via intercepted/forwarded invites

Prerequisites

  • Organization Admin access

ClickOps Implementation

Step 1: Review Pending Invites

  1. Navigate to: console.anthropic.com → Settings → Members → Invites
  2. Review each pending invite: email, role, creation date
  3. Revoke any invite where the recipient is unknown or no longer needed

Step 2: Establish Invite Policy

  1. Require approval before sending invites
  2. Review pending invites weekly
  3. Use the lowest necessary role for each invite (invites cannot use admin role via API)

Time to Complete: ~5 minutes

Code Implementation

Code Pack: API Script
hth-anthropic-claude-6.01-audit-pending-invites.sh View source on GitHub ↗ 
# List all pending invites and identify stale ones
info "Listing all organization invites..."
INVITES=$(anthropic_list_all "/v1/organizations/invites") || {
  fail "6.1 Failed to list invites"
  summary; exit 0
}

TOTAL=$(echo "${INVITES}" | jq 'length')
PENDING=$(echo "${INVITES}" | jq '[.[] | select(.status == "pending")] | length')
EXPIRED=$(echo "${INVITES}" | jq '[.[] | select(.status == "expired")] | length')
ACCEPTED=$(echo "${INVITES}" | jq '[.[] | select(.status == "accepted")] | length')

info "Invites: total=${TOTAL}, pending=${PENDING}, expired=${EXPIRED}, accepted=${ACCEPTED}"

if [[ "${PENDING}" -gt 0 ]]; then
  warn "6.1 ${PENDING} pending invites found — review for stale or unauthorized invitations:"
  echo "${INVITES}" | jq -r '.[] | select(.status == "pending") |
    "  \(.email) | Role: \(.role) | Created: \(.created_at) | Expires: \(.expires_at)"'
else
  pass "6.1 No pending invites"
fi
# Revoke a specific pending invite
# Usage: Set INVITE_ID before running
if [[ -n "${INVITE_ID:-}" ]]; then
  info "Revoking invite ${INVITE_ID}..."
  anthropic_delete "/v1/organizations/invites/${INVITE_ID}" || {
    fail "6.1 Failed to revoke invite"
    summary; exit 0
  }
  pass "6.1 Invite ${INVITE_ID} revoked"
fi

Validation & Testing

  1. Run invite audit script — verify no stale pending invites
  2. Attempt to create invite with admin role via API — should fail (by design)
  3. Confirm expired invites cannot be accepted

Expected result: All pending invites are reviewed, authorized, and time-bound

Compliance Mappings

Framework Control ID Control Description
SOC 2 CC6.2 Prior to issuing system credentials and granting system access
NIST 800-53 AC-2(3) Account management — disable accounts
ISO 27001 A.9.2.1 User registration and de-registration

2.2 Integration Risk Assessment

Profile Level: L2 (Walk)

Framework Control
NIST 800-53 RA-3, SA-9
SOC 2 CC3.2, CC9.2

Description

Assess the security posture of applications and services that consume your Claude API keys. API keys are bearer tokens — any application with the key can make requests on your behalf within the workspace scope.

Rationale

Why This Matters:

  • Any application holding your API key can generate costs and access model capabilities
  • Third-party tools (LangChain, LlamaIndex, custom applications) embed API keys
  • A compromised third-party application with your key = a compromised key

Attack Prevented: Key compromise via insecure third-party applications, unauthorized API usage through embedded bearer tokens

Integration Risk Assessment Matrix

Risk Factor Low Medium High
Data Sensitivity Non-sensitive prompts Internal business data PII, financial, health data
Key Scope Dedicated low-limit workspace Shared development workspace Production workspace
Application Trust First-party, audited code Vendor with SOC 2 Unaudited open-source tool
Key Storage Secrets manager Environment variable Hardcoded or config file
Rate Limit Strict per-workspace limits Moderate limits Organization-level defaults

Decision Matrix:

  • 0-5 points: Standard controls (workspace scoping, naming)
  • 6-10 points: Enhanced controls (dedicated workspace, low spend limits, key rotation)
  • 11-15 points: Reject or isolate (dedicated workspace with minimum limits, frequent rotation, monitoring)

Validation & Testing

  1. Maintain inventory of all applications using Claude API keys
  2. Verify each application’s key is in an appropriately scoped workspace
  3. Confirm keys are stored in secrets managers, not in source code

Expected result: All API key consumers are inventoried with risk ratings and appropriate controls

Compliance Mappings

Framework Control ID Control Description
SOC 2 CC3.2, CC9.2 Risk assessment; vendor and third-party risk management
NIST 800-53 RA-3, SA-9 Risk assessment; external system services
ISO 27001 A.15.1.2 Addressing security within supplier agreements

3. Compliance Quick Reference

SOC 2 Trust Services Criteria Mapping

Control ID Anthropic Claude Control Guide Section
CC6.1 Enforce SSO, Least-Privilege Roles, API Key Scoping, Managed Settings, Sandbox, Hooks/Plugins, Prompt Injection Defense, Cowork Governance 1.1, 1.2, 1.3, 2.1, 2.2, 7.1, 7.2, 7.5, 7.6, 7.7, 7.10
CC6.2 Invite Management, Workspace Membership 3.2, 6.1
CC6.3 Role-Based Access, Workspace Scoping 1.2, 2.1, 3.2
CC6.6 Workspace Segmentation, Data Residency 1.3, 3.1, 4.1
CC6.8 Spend Limits, Sandbox Boundaries, External Sandbox 5.2, 7.5, 7.9
CC7.1 CI/CD Pipeline Security 7.8
CC7.2 Usage Monitoring, Cost Monitoring, Prompt Injection Detection, Cowork Audit 5.1, 5.2, 7.7, 7.10
CC8.1 Managed Settings, Change Management, Hook/Plugin Governance, CI/CD Hardening 7.1, 7.6, 7.8
CC7.3 Incident Detection and Response 7.11
CC7.4 Incident Recovery 7.11
CC9.2 Integration Risk Assessment, MCP Server Control 6.2, 7.3

NIST 800-53 Rev 5 Mapping

Control Anthropic Claude Control Guide Section
AC-2 Account Management, Workspace Membership 3.2, 6.1
AC-3 API Key Scoping, Workspace Isolation 2.1
AC-4 Workspace Segmentation 3.1
AC-6 Least-Privilege Roles 1.2, 2.1, 3.2
AU-6 Usage Monitoring 5.1
IA-2 SSO Enforcement 1.1
IA-5 Admin Key Protection, Key Rotation 1.3, 2.2
IA-8 Non-Organization User Authentication 1.1
RA-3 Integration Risk Assessment 6.2
SA-9 External Service Controls, Spend Limits 5.2, 6.2
SC-7 Workspace Boundaries, Data Residency 3.1, 4.1
SI-4 System Monitoring 5.1, 5.2
CM-6 Managed Configuration Settings 7.1
CM-7 Least Functionality, Tool Restrictions, MCP Control, Sandbox, Hooks/Plugins 7.1, 7.2, 7.3, 7.5, 7.6
SA-11 Developer Security Testing, CI/CD Hardening 7.8
SA-15 Development Process Security 7.8
SC-7 Boundary Protection, External Sandbox 3.1, 4.1, 7.9
SC-39 Process Isolation, Sandbox Enforcement 7.5, 7.9
SI-7 Software Integrity, Hook/Plugin Validation 7.6, 7.7
IR-4 Incident Handling 7.11
IR-5 Incident Monitoring 7.11
IR-8 Incident Response Plan 7.11
SI-10 Information Input Validation, Prompt Injection Defense 7.7
SI-12 Data Retention 4.2

ISO 27001:2022 Mapping

Control Anthropic Claude Control Guide Section
A.8.10 Data Retention and Deletion 4.2
A.9.2.1 User Registration 1.1, 6.1
A.9.2.3 Privileged Access Management 1.2
A.9.2.5 User Access Review 3.2
A.9.3.1 Secret Authentication Information 2.2
A.9.4.1 Information Access Restriction 2.1
A.9.4.3 Password/Key Management 1.3
A.12.1.3 Capacity Management 5.2
A.12.4.1 Event Logging 5.1
A.12.2.1 Controls Against Malware 7.7
A.12.5.1 Software Installation Controls 7.6
A.12.6.1 Technical Vulnerability Management 7.6
A.13.1.1 Network Controls 7.9
A.13.1.3 Network Segregation 3.1, 7.5, 7.9
A.14.2.1 Secure Development Policy 7.8
A.14.2.8 System Security Testing 7.7, 7.8
A.15.1.2 Supplier Security 6.2
A.16.1.1 Information Security Incident Management 7.11
A.16.1.5 Response to Information Security Incidents 7.11
A.18.1.4 Privacy Protection 4.1

NIST Cybersecurity Framework (CSF) 2.0 Mapping

Function.Category Anthropic Claude Control Guide Section
GV.PO (Govern: Policy) Acceptable use policy, scheduled task governance, regulated workload restrictions 7.10, 7.11
GV.SC (Govern: Supply Chain) Vendor risk register, plugin/MCP supply chain review, audit gap tracking 7.3, 7.6, 7.7, 7.10
ID.AM (Identify: Asset Management) Plugin inventory, connector registry, MCP server registry, scheduled task inventory 7.3, 7.6, 7.10
ID.RA (Identify: Risk Assessment) Plugin risk tiers, MCP blast radius analysis, CVE tracking 7.6, 7.7
PR.AC (Protect: Access Control) SSO/SCIM, tenant restrictions, RBAC, Chrome allowlists, connector controls, folder scoping 1.1, 7.2, 7.10
PR.AT (Protect: Training) Prompt injection awareness, safety guide distribution, AUP training, folder hygiene 7.7, 7.10
PR.DS (Protect: Data Security) File access controls, cross-app data flow, local history handling, ZDR, disk encryption 4.1, 4.2, 7.5, 7.10
PR.PS (Protect: Platform Security) Managed settings, global instructions, plugin install preferences, network egress, sandbox 7.1, 7.5, 7.6, 7.10
DE.CM (Detect: Monitoring) OpenTelemetry, SIEM integration, scheduled task review, anomaly alerting, cost monitoring 5.1, 7.4, 7.10
DE.AE (Detect: Analysis) Prompt injection detection, scope creep monitoring, exfiltration pattern detection 7.7, 7.10
RS.RP (Respond: Planning) IR playbook with AI agent scenarios, kill-switch authority, tabletop exercises 7.11
RS.CO (Respond: Communications) Anthropic reporting (HackerOne), in-app feedback, security team escalation 7.11
RS.AN (Respond: Analysis) Local forensic collection, OTel log correlation, Compliance API (non-Cowork) 7.11

NIST AI Risk Management Framework (AI RMF) Mapping

Function Anthropic Claude Control Guide Section
GOVERN 1 (Policies & Legal) Acceptable use policy, regulated workload restrictions, AI usage policy 7.10, 7.11
GOVERN 2 (Accountability) SSO/SCIM, tenant restrictions, RBAC, defined admin roles 1.1, 1.2, 7.10
GOVERN 4 (Culture & Training) Prompt injection awareness, safety guides, folder hygiene training 7.7, 7.10
GOVERN 6 (Supply Chain) Vendor risk register, plugin/MCP review, audit gap tracking 7.3, 7.6, 7.7
MAP 1 (Context & Scope) Deployment posture selection, plan-tier analysis, plugin/connector inventories 7.1, 7.10
MAP 3 (Risk Identification) Prompt injection threat model, MCP blast radius, CVE tracking 7.7, 7.10
MEASURE 1 (Monitoring) OpenTelemetry, SIEM, alerting, cost monitoring, task review 5.1, 7.4, 7.10
MANAGE 1 (Risk Treatment) ZDR, disk encryption, managed settings, Chrome controls, connector controls 4.2, 7.1, 7.5, 7.10
MANAGE 2 (Response) IR playbook with AI agent scenarios, kill-switch, tabletop exercises 7.11
MANAGE 4 (Residual Risk) Audit log gap documented, regulated workload prohibition, OTel as compensating control 7.10, 7.11

Appendix A: Edition/Tier Compatibility

Control API (All Tiers) Team Enterprise
1.1 Enforce SSO N/A (API-only) ✅ ✅
1.2 Least-Privilege Roles ✅ ✅ ✅
1.3 Admin Key Protection ✅ ✅ ✅
2.1 API Key Scoping ✅ ✅ ✅
2.2 API Key Rotation ✅ ✅ ✅
3.1 Workspace Segmentation ✅ ✅ ✅
3.2 Workspace Membership ✅ ✅ ✅
4.1 Data Residency ✅ ✅ ✅
4.2 Custom Data Retention ❌ ❌ ✅
4.2 Zero Data Retention ❌ ❌ ✅ (by arrangement)
5.1 Usage Monitoring ✅ ✅ ✅
5.2 Spend Limits ✅ ✅ ✅
6.1 Invite Auditing ✅ ✅ ✅
6.2 Integration Risk ✅ ✅ ✅
7.1 Managed Settings (MDM) ✅ (MDM only) ✅ ✅
7.1 Server-Managed Settings ❌ ✅ (v2.1.38+) ✅ (v2.1.30+)
7.2 Permission Restrictions ✅ (MDM only) ✅ ✅
7.3 MCP Server Control ✅ (MDM only) ✅ ✅
7.4 Claude Code Analytics ✅ ✅ ✅
7.5 Bash Sandbox Isolation ✅ (MDM only) ✅ ✅
7.6 Hooks & Plugin Lockdown ✅ (MDM only) ✅ ✅
7.7 Prompt Injection Defense ✅ (open-source tools) ✅ ✅
7.8 CI/CD Pipeline Hardening ✅ (GitHub Actions) ✅ ✅
7.9 External Sandbox (nono/OpenShell) ✅ (open-source tools) ✅ ✅
7.10 Cowork Governance ❌ ✅ ✅
7.11 Incident Response ✅ (procedural) ✅ ✅
SCIM Provisioning ❌ ❌ ✅
Audit Logs ❌ ❌ ✅

Appendix B: References

Official Anthropic Documentation:

Identity Provider Integration:

Claude Code Security:

Open-Source Security Tools:

Security Research:

Claude Cowork:

Security and Compliance:

Changelog

Date Version Maturity Changes Author
2026-02-21 0.1.0 draft Initial guide: 12 controls across 6 categories, API pack scripts for Admin API Claude Code (Opus 4.6)
2026-02-21 0.2.0 draft Added Section 7: Claude Code Enterprise Controls — MDM managed settings, permission restrictions, MCP server control, developer analytics Claude Code (Opus 4.6)
2026-02-21 0.3.0 draft Added MDM config templates (L1/L2/L3 profiles), permission deny rule examples, sandbox config, managed-mcp.json template, MCP allowlist/denylist config Claude Code (Opus 4.6)
2026-02-21 0.4.0 draft Added Config-as-Code pack type with standalone .jsonc config files; added code pack buttons, doc links; moved JSON configs from API scripts to config/ directory Claude Code (Opus 4.6)
2026-03-27 0.5.0 draft Major expansion: Added 6 new controls (7.5-7.10) — Bash sandbox isolation, hook/plugin lockdown, prompt injection defense, CI/CD pipeline hardening, external sandbox tooling (nono, OpenShell), Cowork governance. Updated 7.1 with drop-in directory, plist/registry delivery, new managed settings. Added comprehensive references for security research (ToxicSkills, Rules File Backdoor, InversePrompt CVEs) and open-source tools. Updated all compliance mappings. Claude Code (Opus 4.6)
2026-04-06 0.6.0 draft Added 7.11 Incident Response (kill-switch, forensic collection, AI agent IR scenarios, tabletop exercises). Major expansion of 7.10 Cowork: Chrome hardening (allowlist/blocklist, default gap warnings), global defensive instructions, dedicated workspace scoping, scheduled task governance, plugin install preferences, tenant restriction details (exact header format, proxy platforms, error codes), data training opt-out by tier, web search egress bypass warning, OTel prompt content toggle. Added NIST CSF 2.0 and NIST AI RMF compliance mappings. Added web search bypass warning to 7.5 sandbox. Claude Code (Opus 4.6)
2026-05-06 0.7.0 draft Added 2.3 Eliminate Static API Keys via Workload Identity Federation: covers Anthropic’s new WIF capability (RFC 7523 jwt-bearer flow against POST /v1/oauth/token), Console setup walkthrough for federation issuers / service accounts / federation rules, IdP coverage (AWS / GCP / Azure-Entra / GitHub Actions / Kubernetes / SPIFFE / Okta), credential precedence pitfalls (ANTHROPIC_API_KEY shadowing WIF), token lifetime/refresh semantics, JWKS rotation gotchas, and migration runbook. Code Packs: token-exchange script with static-key guardrail (api/), reference hardened GitHub Actions workflow (config/), config-as-code WIF profile (config/), Python SDK pattern (sdk/). Verified against platform.claude.com/docs/en/manage-claude/workload-identity-federation and wif-reference. Claude Opus 4.7 (1M)
2026-08-08 1.0.1 draft Added “Products in This Platform” navigation section (product guide table mirroring the Google Workspace hub) so the Anthropic hub lists Claude Enterprise, Claude Code, and Claude API & Console with their coverage. No control changes. Claude Opus 5 (1M)
2026-08-08 1.0.2 draft Cheat-sheet cell repair: added missing Attack Prevented line(s) to §2.2 (no content-facts changed) Claude Code (Fable 5)

Contributing

Found an issue or want to improve this guide?