> ## Documentation Index
> Fetch the complete documentation index at: https://conductorone-jorge-mcp-resources-documentation.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Set up a CrowdStrike connector
> C1 provides identity governance for CrowdStrike. Integrate your CrowdStrike instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access.
## Capabilities
| Resource | Sync | Provision |
| :-------------------------- | :------------------------------------------------------------ | :------------------------------------------------------------ |
| Accounts | | |
| Roles | | |
| Insights | | |
| Shadow MCP servers (opt-in) | | |
| Endpoint users (opt-in) | | |
| AI coding tools (opt-in) | | |
### Connector actions
| Action | Description |
| :---------- | :--------------------------------------------------- |
| Update User | Updates a CrowdStrike user's first and/or last name. |
**Additional functionality:**
The CrowdStrike connector supports [external insights](/product/admin/external-insights) when your organization has a Falcon Identity Protection license. See [Enable risk score ingestion](#enable-risk-score-ingestion) and [Surface identity password risk](#surface-identity-password-risk) for setup instructions.
## Gather CrowdStrike credentials
Configuring the connector requires you to pass in credentials generated in CrowdStrike. Gather these credentials before you move on.
A user with the **Falcon Administrator** role in CrowdStrike must perform this task.
### Create a CrowdStrike API client
Sign into the Falcon console and navigate to **Support** > **API Clients and Keys**.
Click **+ Add new API client**.
Give the new API client a name, such as "C1 integration" and add a description.
In the **API SCOPES** section of the page, select the appropriate **User management** scopes:
* **Read** and **Write** to sync access data and provision CrowdStrike roles
* **Read** to sync access data
Click **ADD**.
The new API client is created, and its client ID and client secret are shown. Carefully copy and save these credentials.
**Done.** Next, move on to the connector configuration instructions.
## Configure the CrowdStrike connector
To complete this task, you'll need:
* The **Connector Administrator** or **Super Administrator** role in C1
* Access to the set of CrowdStrike credentials generated by following the instructions above
**Follow these instructions to use a built-in, no-code connector hosted by C1.**
In C1, navigate to **Integrations** > **Connectors** and click **Add connector**.
Search for **CrowdStrike** and click **Add**.
Choose how to set up the new CrowdStrike connector:
* Add the connector to a currently unmanaged app (select from the list of apps that were discovered in your identity, SSO, or federation provider that aren't yet managed with C1)
* Add the connector to a managed app (select from the list of existing managed apps)
* Create a new managed app
Set the owner for this connector. You can manage the connector yourself, or choose someone else from the list of C1 users. Setting multiple owners is allowed.
If you choose someone else, C1 will notify the new connector owner by email that their help is needed to complete the setup process.
Click **Next**.
Find the **Settings** area of the page and click **Edit**.
In the **Client ID** and **Client secret** fields, enter the CrowdStrike credentials.
**Optional.** Enter your CrowdStrike region in the **Region** field. The default region is **US-1**.
Click **Save**.
The connector's label changes to **Syncing**, followed by **Connected**. You can view the logs to ensure that information is syncing.
**Done.** Your CrowdStrike connector is now pulling access data into C1.
**Follow these instructions to use the CrowdStrike connector, hosted and run in your own environment.**
When running in service mode on Kubernetes, a self-hosted connector maintains an ongoing connection with C1, automatically syncing and uploading data at regular intervals. This data is immediately available in the C1 UI for access reviews and access requests.
### Resources
* [Official download center](https://dist.conductorone.com/ConductorOne/baton-crowdstrike): For stable binaries (Windows/Linux/macOS) and container images.
* [GitHub repository](https://github.com/conductorone/baton-crowdstrike): Access the source code, report issues, or contribute to the project.
### Step 1: Set up a new CrowdStrike connector
In C1, navigate to **Integrations** > **Connectors** > **Add connector**.
Search for **Baton** and click **Add**.
Choose how to set up the new CrowdStrike connector:
* Add the connector to a currently unmanaged app (select from the list of apps that were discovered in your identity, SSO, or federation provider that aren't yet managed with C1)
* Add the connector to a managed app (select from the list of existing managed apps)
* Create a new managed app
Set the owner for this connector. You can manage the connector yourself, or choose someone else from the list of C1 users. Setting multiple owners is allowed.
If you choose someone else, C1 will notify the new connector owner by email that their help is needed to complete the setup process.
Click **Next**.
In the **Settings** area of the page, click **Edit**.
Click **Rotate** to generate a new Client ID and Secret.
Carefully copy and save these credentials. We'll use them in Step 2.
### Step 2: Create Kubernetes configuration files
Create two Kubernetes manifest files for your CrowdStrike connector deployment:
#### Secrets configuration
```yaml expandable theme={null}
# baton-crowdstrike-secrets.yaml
apiVersion: v1
kind: Secret
metadata:
name: baton-crowdstrike-secrets
type: Opaque
stringData:
# C1 credentials
BATON_CLIENT_ID:
BATON_CLIENT_SECRET:
# CrowdStrike credentials
BATON_CROWDSTRIKE_CLIENT_ID:
BATON_CROWDSTRIKE_CLIENT_SECRET:
BATON_REGION:
# Optional: include if you want C1 to provision access using this connector
BATON_PROVISIONING: "true"
```
See the connector's README or run `--help` to see all available configuration flags and environment variables.
#### Deployment configuration
```yaml expandable theme={null}
# baton-crowdstrike.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: baton-crowdstrike
labels:
app: baton-crowdstrike
spec:
selector:
matchLabels:
app: baton-crowdstrike
template:
metadata:
labels:
app: baton-crowdstrike
baton: "true"
baton-app: crowdstrike
spec:
containers:
- name: baton-crowdstrike
image: public.ecr.aws/conductorone/baton-crowdstrike:latest
imagePullPolicy: IfNotPresent
env:
- name: BATON_HOST_ID
value: baton-crowdstrike
envFrom:
- secretRef:
name: baton-crowdstrike-secrets
```
### Step 3: Deploy the connector
Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
Check that the connector data uploaded correctly. In C1, click **Apps**. On the **Managed apps** tab, locate and click the name of the application you added the CrowdStrike connector to. CrowdStrike data should be found on the **Entitlements** and **Accounts** tabs.
**Done.** Your CrowdStrike connector is now pulling access data into C1.
## Enable risk score ingestion
The CrowdStrike connector can ingest Falcon identity risk scores and surface them in C1 during access reviews and access request approvals. See [External insights](/product/admin/external-insights) for an overview of where risk data appears.
### Before you begin
Confirm that:
* Your organization has a **CrowdStrike Falcon Identity Protection** license
* You have the **Falcon Administrator** role in CrowdStrike
* Your CrowdStrike connector is already set up and syncing in C1
### Add required API scopes
The CrowdStrike API client you created during connector setup needs additional scopes to access risk score data.
Sign into the Falcon console and navigate to **Support** > **API Clients and Keys**.
Find the API client you created for the C1 integration and click to edit it.
In the **API SCOPES** section, enable the following scopes:
* **Identity Protection Entities: Read**
* **Identity Protection GraphQL: Write** (This is required by CrowdStrike to fetch the data)
Click **Save**.
### Risk score ingestion setting
Identity risk scores use the **Identity Risk Score** (`security_insight`) capability, which is opt-in in C1. Once the scopes above are in place and the capability is enabled, the connector syncs risk scores automatically. There is no connector config flag that empties this resource type.
**Done.** Your CrowdStrike connector will now sync risk score data into C1. See [External insights](/product/admin/external-insights) for details on where to see this data in the UI.
## Surface identity password risk
**Early access.** This feature is in early access, which means it's undergoing ongoing testing and development while we gather feedback, validate functionality, and improve outputs. Contact the C1 Support team if you'd like to try it out or share feedback.
Once risk score ingestion is enabled, you can flag identities with a compromised or weak password from Falcon Identity Protection as risk factors:
* **`EXPOSED_PASSWORD`** (High) — the identity's password appears in a known breach or exposed-credential set (a compromised password).
* **`WEAK_PASSWORD`** (Medium) — the identity's password is weak.
These are not a separate resource or screen — they appear as **risk factors** on the identity's existing risk insight, in the same places as risk scores (see [Where external insights appear](/product/admin/external-insights#where-external-insights-appear)). A factor is added only when an account has that condition — identities with strong, unexposed passwords carry no password factor.
### Before you begin
Confirm that:
* Risk score ingestion is set up — see [Enable risk score ingestion](#enable-risk-score-ingestion).
* The **Identity Risk Score** resource capability is turned on for your connector (see [Enable or disable external insights](/product/admin/external-insights#enable-or-disable-external-insights)). Password risk attaches to that insight, so it won't appear if the capability is off.
* Your CrowdStrike connector is already set up and syncing in C1.
### Turn on password risk
Password risk uses the same Identity Protection scopes as risk score ingestion, so no additional CrowdStrike API scopes are required. Enable it in the connector's settings:
In C1, go to **Integrations** > **Connectors** and select your CrowdStrike connector.
On the connector's **Settings**, click **Edit**.
Enable **Ingest identity password risk** (off by default), then click **Save**.
**Done.** On the next sync, identities with a compromised or weak password carry the corresponding risk factor, visible wherever external insights appear.
## Detect shadow MCP servers
**Early access.** This feature is in early access, which means it's undergoing ongoing testing and development while we gather feedback, validate functionality, and improve outputs. Contact the C1 Support team if you'd like to try it out or share feedback.
The CrowdStrike connector can surface unsanctioned ("shadow") [Model Context Protocol](https://modelcontextprotocol.io) servers running on your endpoints — ungoverned AI-agent tooling that never passed through a sanctioned gateway — and correlate each to the identity that ran it. It reads CrowdStrike endpoint detections and models each shadow server as:
* an **`mcp_server`** resource describing the server (package, launcher, transport, host, sample command line, and the identity it resolved to), and
* an **`endpoint_user`** account for the OS user that ran it, holding a **runner** grant on that server.
Assign the endpoint-user account to a C1 identity (or it auto-matches by email when the endpoint user resolves in Identity Protection) so the shadow MCP shows up against a real person in access reviews.
### Before you begin
Confirm that:
* Your CrowdStrike environment generates endpoint detections (the connector reads them via the Alerts API)
* You have the **Falcon Administrator** role in CrowdStrike
* Your CrowdStrike connector is already set up and syncing in C1
### Add the required API scope
Sign into the Falcon console and navigate to **Support** > **API Clients and Keys**.
Find the API client you created for the C1 integration and click to edit it.
In the **API SCOPES** section, enable **Alerts: Read**. Keep the **Identity Protection Entities: Read** scope enabled (from risk score ingestion) so endpoint users can be matched to identities.
Click **Save**.
### Create a detection rule for MCP servers
CrowdStrike doesn't flag MCP servers by default, so you author a Custom IOA rule that raises a detection the connector can read. An MCP server is an ordinary `npx`, `uvx`, `node`, or `python` process whose command line contains a recognizable package name (`@modelcontextprotocol/server-*`, `mcp-server-*`, or `mcp_server_*`).
In the Falcon console, create or open a **Custom IOA rule group** for each platform you want to cover (Windows, macOS, Linux).
Add a **Process Creation** rule with the **Detect** disposition.
Set the rule's **Command Line** field to match the MCP signature:
```
(?i).*(@modelcontextprotocol/server-|mcp-server-|mcp_server_).*
```
Enable the rule and the rule group, then assign the group to the prevention policy that applies to those hosts.
### Turn on shadow MCP detection
In C1, enable **both** the **Shadow MCP Server** and **Endpoint User** capabilities on the connector (these resource types are opt-in via C1 capability mediation, not a connector config flag), then save and re-sync.
**Enable them together.** Shadow MCP `runner` grants use `endpoint_user` principals. If only Shadow MCP Server is enabled and Endpoint User is off, C1 will not list those principals and the runner grant graph will not fully resolve.
### Detection inventory window (page caps)
Shadow MCP inventory is a **recent endpoint-protection (epp) alert scan window**, not full historical state:
* Alerts are scanned newest-first, bounded by `mcpAlertMaxPages` (10 pages × 1000 alerts per page).
* Identity correlation indexes Identity Protection entities up to `mcpIdentityIndexMaxPages` pages.
If epp volume is high, the effective lookback shortens. Detections (and thus `mcp_server` / `endpoint_user` resources) that fall outside the scanned window can drop from a later sync **without a hard sync failure** — the connector logs a warning when a page cap is hit and continues with partial results. Re-enablement or lower epp noise restores visibility when those detections reappear in the window.
**Done.** As endpoints run MCP servers, CrowdStrike raises detections and the connector syncs them into C1 as `mcp_server` resources and `endpoint_user` accounts. Assign each endpoint-user account to a C1 identity to attribute the finding.
## Detect AI coding tools
**Early access.** This feature is in early access, which means it's undergoing ongoing testing and development while we gather feedback, validate functionality, and improve outputs. Contact the C1 Support team if you'd like to try it out or share feedback.
The CrowdStrike connector can inventory **AI coding tools** ("harnesses" — Claude Code, Claude Desktop, Cursor, Windsurf, OpenAI Codex, Gemini CLI, GitHub Copilot CLI, opencode, Aider, and similar) observed running on your endpoints, and correlate each to the identity that ran it. This gives you governance visibility into which people are using which AI tools on which hosts. It reads CrowdStrike endpoint detections and models each tool as an **`ai_tool`** resource describing the tool (name, vendor, category, host, sample command line, and the identity it resolved to), with a low-severity insight linking it to that identity.
This shares the same detection pipeline as shadow MCP detection — it reads the Alerts API and resolves endpoint users to identities the same way — but is enabled independently via the **AI Coding Tool** C1 capability.
### Before you begin
Confirm that:
* Your CrowdStrike environment generates endpoint detections (the connector reads them via the Alerts API)
* You have the **Falcon Administrator** role in CrowdStrike
* Your CrowdStrike connector is already set up and syncing in C1
### Add the required API scope
The **Alerts: Read** scope is required (the same scope shadow MCP detection uses). Keep **Identity Protection Entities: Read** enabled so AI-tool usage can be matched to identities. If you already enabled these for shadow MCP detection, no change is needed.
### Create a detection rule for AI coding tools
CrowdStrike doesn't flag AI coding tools by default, so you author a Custom IOA rule that raises a detection the connector can read.
In the Falcon console, create or open a **Custom IOA rule group** for each platform you want to cover (Windows, macOS, Linux).
Add a **Process Creation** rule with the **Detect** disposition.
Set the rule's **Command Line** field to match common AI coding tools:
```
(?i).*(claude-code|[\\/]claude\.(exe|app)|[\\/]cursor\.(exe|app)|cursor-agent|[\\/]windsurf|@openai[\\/]codex|codex-cli|@github[\\/]copilot|copilot-cli|gemini-cli|[\\/]opencode|[\\/]aider).*
```
Adjust the list to the tools you want to track. The pattern anchors tool names to executables and package paths (rather than matching the bare words "codex" or "copilot" anywhere) to avoid raising detections on unrelated software. Because AI coding tools are ordinary developer software rather than threats, expect a detection each time one launches.
Enable the rule and the rule group, then assign the group to the prevention policy that applies to those hosts.
### Turn on AI coding tool detection
In C1, enable the **AI Coding Tool** capability on the connector (opt-in via C1 capability mediation, not a connector config flag), then save and re-sync.
### Detection inventory window (page caps)
AI coding tool inventory shares the same Alerts scan as shadow MCP detection. Inventory is a **recent epp alert scan window** bounded by `mcpAlertMaxPages` (and identity correlation by `mcpIdentityIndexMaxPages`), not full historical state. High epp volume shortens effective lookback; tools that fall outside the window can disappear from a later sync without a hard failure (a warning is logged when the page cap is hit). See [Detect shadow MCP servers](#detect-shadow-mcp-servers) for the same semantics.
**Done.** As endpoints run AI coding tools, CrowdStrike raises detections and the connector syncs them into C1 as `ai_tool` resources correlated to the identities that ran them.