Skip to main content
Connect your existing LimaCharlie sensors to Forge using either method below. Each method is sufficient on its own. You do not need to set up both. The API-key connection is the default for endpoint operations. Output is an optional alternative for observation only.

​
Choose a connection method

Both connection methods support Windows, macOS and Linux. The API-key connector uses the native helper for the sensor’s platform and architecture; choosing Output does not add endpoint task permissions.

​
API-key endpoint operations

Windows helpers are available for x86-64 and ARM64; 32-bit x86 sensors are not supported for helper execution. Windows payloads use native .exe staging, with typed instructions encoded as data rather than interpolated into a shell. Process termination requires the observed process start time and executable hash. Windows does not provide graceful termination through this helper; a graceful request returns an unproven outcome and does not escalate to force. The connector provides typed process/file remediation; specialized application/browser workflows require their own supported executor. Files and directories remain subject to operation bounds, endpoint privileges and provider response limits. A missing or oversized response is not reported as successful execution.

​
Connection fields

Sensor import is separate from connection setup. An Output connection does not require a second list of approved sensor IDs. Forge scopes incoming observations to the saved organization and event-time sensor tag, and identifies each device by its organization and sensor ID. Matching hostnames alone do not merge devices.

​
Before you start

Have an existing LimaCharlie organization, an online pilot sensor, and its exact sensor ID and platform. For API-key setup, an administrator creates a REST API key under Access Management in that organization, with the permission bundle below. Copy the organization ID and key separately into Forge. Use a dedicated integration key so it can be rotated or revoked without interrupting other clients. For Output, the credential is the Forge-generated signing secret; no LimaCharlie task key is required. LimaCharlie documents the distinction between Output streams and destinations. See LimaCharlie’s permission reference for the provider privilege names.

​
API-key setup

  1. Create an organization-scoped LimaCharlie API key with the permissions below.
  2. Open Settings → Integrations → LimaCharlie in Forge.
  3. Enter the organization ID and REST API key, then select Connect with API key.
  4. Select Test connection to check effective permissions.
  5. Open Sensor import, select the sensors to import, and explicitly assign their owners. Connection setup does not automatically import every sensor.
Import enables scheduled inventory. Local inventory can publish and run the Forge helper through LimaCharlie tasks. Approve that execution on the pilot sensors before importing them. For observation without endpoint tasks, use the Output connection instead. API-key connections do not use Output sensor tag. That field belongs to the Output connection and does not restrict the API key’s permissions. Use a REST API key, not a sensor installation key. An installation key is for deploying LimaCharlie sensors and does not authenticate Forge API requests. See Endpoint operations for import, inventory, and cleanup steps shared across endpoint providers.

​
Permissions

Use a dedicated key scoped to the organization and features you enable. The operational task connection checks this permission bundle: These response streams belong to task execution. They are separate from the customer-managed Event Output used by the alternative method. Forge does not provide a free-form shell input through this integration.

​
Output setup

  1. In Forge, enter the organization ID and the Output sensor tag below the OR divider. Select Connect with Output. Leave the REST API key blank.
  2. Copy the generated webhook URL and signing secret before leaving the page.
  3. In LimaCharlie, open Outputs and create an Output with the Event stream and Webhook Bulk destination. Give it a recognizable name, such as forge-observe.
  4. Set the destination host to the Forge URL, the secret key to the generated secret, and the tag to the exact tag saved in Forge. Enable compression and set batching to 1 second. Preserve the default routing/event structure; do not transform it into another format.
  5. Add the event types below, one per line. Apply the tag to the sensors you want to observe, and ensure those sensors’ collection settings include the events.
  6. Generate process or network activity and confirm Last observed in Forge.
LimaCharlie documents the destination and signature fields in Webhook Bulk and the single-tag and newline-separated filters in Stream structures. The batching interval controls when a batch is cut; it is not a delivery SLA. Choose an interval that keeps each delivery within the receiver limits below. Large events can reach the byte limit before the event limit. Measure the tagged fleet’s busiest batch before expanding the rollout.

​
Delivery limits and recovery

A 204 means Forge accepted the delivery. In the synchronous receiver mode, eligible observations have committed before the response. In the queued receiver mode, the response follows durable admission; workers commit Inventory and policy results afterward. Last observed can advance before Inventory updates in either mode. A queued raw payload is kept only for processing and recovery, then deleted after its projection commits. Routine observations with no catalog, policy, candidate or existing-state effect are discarded after evaluation. Passive, unchanged sightings of the same catalog product on a device under the same review decision can share one Review with a sighting count and first/last seen times. A retained event key and digest provide first-sighting provenance without retaining the raw event or creating a process row. The count does not mean that many distinct processes were examined. A policy that targets a particular process, or requests an active action, keeps its individual process evidence and decision path. Previously unseen observations older than the replay boundary do not recreate expired Inventory evidence. Forge keeps an aggregate gap summary containing a count, time range and identity digest, and processes eligible fresh siblings. This summary contains no raw event payload. A 503 means reception is busy or admission or synchronous processing could not finish. Retry the complete delivery. In synchronous mode, some earlier observations may already be saved. A byte-identical queued delivery retry is idempotent while its delivery checkpoint is retained (seven days after completion). If the provider repackages the same passive events into a different bulk delivery, their sighting count can increase again. Treat it as an observed activity indicator, not a count of unique processes, connections, conversations or usage. Individually retained exact-path evidence keeps its existing replay checks. A 429 means the delivery rate limit was reached. Invalid framing or an exceeded body limit returns 400; exceeding the processing event or row bound returns 413. A wrong signature or organization/tag scope returns 401. A 409 means changed evidence conflicts with an observation Forge retained on an exact path, or with another event identity in the same delivery. Preserve provider event identifiers and the sensor’s device binding on retry. Do not rewrite event identifiers to work around a rejected delivery. Forge evaluates process observations against its catalog and active policies. If those change during processing, Forge can return 503 so a retry uses the updated configuration. LimaCharlie network evidence retains its provider attribution. It does not establish Device Agent process verification. Committed observations survive Forge restarts. Queued deliveries also survive worker restarts and resume projection from their retained checkpoint. If synchronous processing is interrupted, LimaCharlie must retry the complete delivery. A queue admission failure also requires a complete-delivery retry. Forwarding and retries still depend on the customer-managed LimaCharlie Output. Inspect its error logs after failed deliveries; an observed retry is not a promise of unlimited vendor buffering or lossless forwarding during a prolonged outage. An Output filters events already collected by sensors. Adding a type to its allowlist does not enable that sensor notification. In LimaCharlie event collection settings, check the tagged sensors’ effective collection profile; TCP notifications may need a tag-scoped Event collection rule. Preserve other rules and apply changes only to the intended sensors. Consult the LimaCharlie event reference for each event’s meaning and platform availability. Forge needs no LimaCharlie REST API key for Output reception. The person creating the Output needs the corresponding LimaCharlie administrative access; those permissions are not credentials to enter in Forge. Operator diagnostics that read saved Exfil settings require ext.conf.get, not every ext.conf permission. They are not a customer connection prerequisite.

​
What Output observations can prove

Output coverage is partial and depends on sensor collection, event fields and delivery. An observation is positive evidence at the event’s timestamp, not a complete or continuously current inventory. Explicit executable names and domain evidence can match Forge’s AI product catalog. An IP address alone is not treated as proof of ownership by an AI service. Missing process correlation remains unresolved rather than being joined solely by PID. Output observations do not collect prompts, responses, conversation content, tool calls, tokens or spend. They do not assert a complete installed-app, browser-extension, MCP-server or skill inventory, and they do not grant remediation authority. Existing richer inventory and explicitly assigned ownership remain intact when sparse observations arrive.

​
Status, rotation and stopping

  • Waiting for observations means the connection is saved but has not received a valid delivery. It does not confirm end-to-end forwarding.
  • Last observed tracks authenticated provider activity received by Forge. It can advance before the delivery’s Inventory projection commits. Device timestamps are coalesced after 10 seconds of provider-time advancement; busy rows refresh on a later delivery. An old timestamp or No recent observations can indicate a collection or delivery gap.
  • Rotate signing secret generates a replacement shown once. Update the LimaCharlie Output immediately. The previous key stops authenticating new admissions; expect a gap while the Output is updated.
  • Pause reception rejects new deliveries. Save changes resumes the connection. Previously admitted evidence remains available.
  • Disconnect disables the connection. Remove the customer-managed Output in LimaCharlie to stop forwarding; no sensor uninstall is needed.
Removing a sensor tag stops future tagged events. Already captured events carry their earlier tag and may still arrive. Disable the Forge connection when you need to stop all new admissions immediately. If delivery stops, inspect LimaCharlie → Platform Logs → Errors for the named Output. Failures can suspend forwarding temporarily. Verify the URL, current secret, organization, tag, stream type and effective sensor collection before retrying. Plan rollout traffic against the receiver’s supported limits; enabling process/network telemetry across a fleet can increase Output volume and costs.

​
Validate coverage and troubleshoot

On an imported API-key pilot, check the provider’s fresh last-seen time, then run one supported inventory collection. Confirm its terminal result, device ID, collection timestamp, and resulting records in Forge. An offline sensor cannot prove helper execution. A queued task, an empty response, and a partial collection are distinct outcomes. MCP servers and skills require readable local configuration and an identified user profile supported by the collector. Installed-app inventory and Output process/network events do not establish complete MCP, skill, hook, or backfill coverage. Review missing-profile and platform limitations in the run result. If task execution fails, inspect the missing permission or sensor status before rotating the key. If Output delivery fails, check its organization, event-time tag, signature, and enabled event types. Stop only the affected connection method while correcting it; the methods have independent credentials.