Falcon MCP

The server authenticates to the CrowdStrike Falcon API with a single operator-supplied API client (client ID and secret from environment variables) and uses that one client for every tool, read or write. The server does not request, narrow or check scopes itself; what the credential can do is whatever the operator granted the API client, and Falcon enforces that on its side. There is no per-request or per-user authorization, and the optional HTTP API key is one shared secret for all callers. If the credential is hijacked the damage is bounded by the API client's scopes, which can include host, policy, IOC and RTR write access across the tenant (and child tenants when a member CID is set).

The server does not run an approval gate; the host decides. What it offers the host is accurate risk annotations: mutating tools are separate from read tools and carry readOnlyHint=false, with destructiveHint=true on deletes. Unannotated tools default to a read-only label, which fails open for any future tool whose author forgets an annotation. Only the quarantine module has a preview tool for destructive actions. A server-enforced read-only mode exists, withholds anything not explicitly read-only, and wins over the allow-list, but it is off by default. In the default configuration every write, delete and workflow-execute tool is registered and no rate limit or quantity bound applies to bulk deletes.

Tools are typed with Pydantic schemas, with numeric bounds on limits and required-ID checks on delete tools, and some inputs are sanitised (NGSIEM repository names reject path separators, identity-investigation values are JSON-encoded). Filters are passed through to the Falcon API as free-form FQL, CQL queries pass through unvalidated, and the RTR tools accept a free-form base command and command string, with the read-only restriction left to the API endpoint rather than checked in this server. By default all modules and all write and delete tools are enabled, though modules, individual tools and a read-only flag can be selected by the operator.

The server never executes model-supplied text as code on its own host: no subprocess, shell, eval, exec or deserialisation calls exist in the package. Model-influenced strings (FQL filters, CQL queries, RTR command strings, workflow parameters) are forwarded to the Falcon API, which runs them in CrowdStrike's cloud or on endpoints under the API client's scopes; those controls are scored under C3 and C5. This is absence of a local execution surface, not a sandbox.

Tool results are plain JSON records from the Falcon API with no provenance or untrusted-content marking, so analyst-controlled or attacker-influenced text (host names, detection command lines, case notes, dark-web content, AI-session prompts, files read through RTR) enters the model with the same standing as anything else. The server's instructions and tool descriptions contain operational guidance only, and the only outbound destination is the Falcon API, so there is no arbitrary-URL egress channel from the server itself. In the default configuration the same session can read sensitive endpoint data and call destructive tools, with nothing in the server stopping a hijacked model; the opt-in read-only mode removes the state-change leg but nothing marks content as untrusted.

The server keeps no memory or retrieval store and loads no instruction files, but it calls load_dotenv() at startup, so a .env file found by python-dotenv can silently set the Falcon credentials, API base URL and the server's own safety switches (read-only mode, enabled modules, tool lists) read afterwards from the environment. python-dotenv's default search starts from the package location, so exposure depends on where the package is installed or run from. That search behaviour is inferred from the library, not read here. The README also tells users to use a .env file.

The server loads no third-party code at runtime: its module registry imports only packages under falcon_mcp.modules, and there is no plugin loader, MCP client, package installer or downloaded model. Build dependencies are out of scope here.

Credentials come from environment variables (or constructor arguments) and are held in plain strings with no masking, secret store or redaction layer. The server has no telemetry, and default logging is limited to start-up and policy messages on stderr. With --debug, request parameters and bodies are logged unredacted. The optional HTTP API key can be given on the command line, which exposes it in the process list. RTR file reads can place file contents, including secrets on endpoints, into model context. The API client secret is long-lived but scoped to the operator's grants and rotatable in Falcon.

The server keeps no record of tool calls. Normal logging covers start-up, policy and authentication messages; the only per-call logging of the operation and its parameters is at debug level in a handful of shared helpers, written to stderr with no caller or approver attribution. HTTP access logs from the web server record requests but not tool names or arguments. Falcon's own tenant audit trail will show the API client and the falcon-mcp user agent, but that is the vendor's record, not the server's.

The server bounds some of its own work: list and search limits have schema ceilings, RTR waits are capped at 600 seconds, and the polling tools for NGSIEM and AgentWorks have deadlines (300 and 45 seconds by default, operator-configurable by environment variable). Concurrent tool calls share a default pool of 40 worker threads, which is incidental backpressure rather than a stated rate limit. There is no rate limit on write tools, no cap on delete batch size, no kill switch, and a cancelled or timed-out request keeps its worker thread until the blocking Falcon call returns, so in-flight actions are not interrupted.