[Feature Request]: Add support for Flight Control

[kacperpietrzyk]

Feature Description

Add support for CrowdStrike Falcon Flight Control (MSSP) multi-tenancy, allowing users to target child CIDs from a single falcon-mcp instance using parent tenant credentials and the member_cid parameter.

Use Case

As a security consultant managing multiple client environments through Flight Control, I need to:

Query detections, incidents, and hosts across specific child tenants without switching API credentials
Investigate threats in a specific client's environment by specifying member_cid at query time
Aggregate security posture data across all child CIDs for cross-tenant reporting
Run threat hunting queries scoped to individual tenants from a single MCP server instance

Example:

Search detections in a specific child tenant

falcon_search_detections --member-cid "CHILD_CID_HERE" --filter "status:'new'+severity_name:'Critical'"

List hosts across a specific child CID

falcon_search_hosts --member-cid "CHILD_CID_HERE" --filter "platform_name:'Windows'"

Investigate entity in a child tenant

falcon_idp_investigate_entity --member-cid "CHILD_CID_HERE" --entity-names "Administrator"

Related Module/Area

Not sure

Proposed Solution (Optional)

Option A — Per-request member_cid parameter:
Add an optional member_cid parameter to all tool calls. When provided, falcon-mcp generates a scoped OAuth2 token for that child CID before executing the query.
Option B — Environment variable / CLI flag:
Support FALCON_MEMBER_CID env var or --member-cid CLI flag to set a default child CID for the entire session. This is simpler but less flexible for cross-tenant workflows.
Option C — Both:
Support a default member_cid via env/CLI and allow per-request override. This covers both single-tenant MSSP setups and dynamic cross-tenant analysis.
The underlying Falcon API already supports this via the member_cid body parameter in the OAuth2 token request, and some APIs (e.g., Detections) are natively Flight Control-aware, aggregating child CID data automatically when authenticated with parent credentials.

Alternatives Considered (Optional)

Currently, the only workaround is running a separate falcon-mcp instance per tenant, each with its own .env file containing tenant-specific API credentials. This doesn't scale for MSSP environments with dozens or hundreds of child CIDs and eliminates the ability to do cross-tenant analysis in a single conversation.

Additional Context (Optional)

The Falcon API already supports member_cid in OAuth2 token generation — FalconPy SDK has had MSSP support since v0.2.1+
Some APIs (Detections, Incidents) are natively Flight Control-aware and aggregate child CID data when using parent credentials
Other CrowdStrike tools (Falcon Toolkit, PSFalcon) already support Flight Control as a first-class feature
This would be particularly valuable for agentic SOC workflows where an AI agent triages alerts across an entire MSSP estate

[carlosmmatos]

@kacperpietrzyk this is a great ask. We'll see what we can do and what makes the most sense, but your use cases make sense to us.

[carlosmmatos]

Here's the issue, FalconPy handles member_cid at authentication time, not per-request. When you initialize an APIHarnessV2 client with a member_cid parameter, it gets included in the OAuth2 token request payload. That token is then scoped to that specific child CID for its entire 30-minute lifetime. The Falcon API doesn't support switching between child CIDs with an already-issued token - you'd need to re-authenticate to get a new token for a different child CID.

This means Option A from your proposal (per-request member_cid parameter on individual tools) isn't actually feasible with how the underlying authentication works. You can't query different child CIDs on a per-call basis without maintaining multiple authenticated client instances, which would add significant complexity.

What we're implementing instead is session-scoped member_cid support. You'll be able to start falcon-mcp with either a --member-cid CLI flag or FALCON_MEMBER_CID environment variable using your parent CID credentials, and all tools in that server instance will target the specified child CID. This aligns with how MCP servers typically work - they're stateful, long-running processes where authentication happens once at startup and the token is automatically refreshed as needed.

For workflows that need to query multiple child CIDs, you can run multiple falcon-mcp instances on different ports, each targeting a different child CID. This is actually the standard MCP pattern for multi-tenancy scenarios.

We're starting with this simpler approach because it covers the majority of MSSP use cases (focusing on one child CID at a time), requires minimal code changes (just passing the parameter through the initialization chain), and matches how the underlying Falcon API authentication actually works. If we find that users really need cross-tenant queries in a single session, we could explore a client pooling approach later, but that would be a much heavier lift.

Alternatively we've been toying around with introducing a CLI wrapper - which would allow you to do things per request because each call would create a new auth session.