> ## Documentation Index
> Fetch the complete documentation index at: https://docs.forge.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# LimaCharlie

> Choose an API-key connection for endpoint inventory and actions, or an Output connection for process and network observations.

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

| Capability | API key | Output |
| - | - | - |
| Discover and import sensors | Yes, through the separate Sensor import flow | Devices appear from authenticated sensor events |
| Bind imported devices to people | Explicit owner selection during import | No user identity is inferred from telemetry |
| Collect supported endpoint inventory | Through typed endpoint tasks | Process and destination observations only |
| Endpoint actions and helper execution | Supported registered operations, subject to device platform and permissions | No endpoint commands or actions |
| New sensor or Forge agent installation | Uses existing LimaCharlie sensors | Uses existing LimaCharlie sensors |
| Credential supplied to Forge | LimaCharlie REST API key | Forge-generated Output signing secret |
| Persistent customer Event Output | Not required for the task connection | Required |

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

| Operation | Windows | macOS | Linux |
| - | - | - | - |
| Host, user, process and application inventory | Yes | Yes | Yes |
| Directory list/walk and file search/stat/hash/read | Yes | Yes | Yes |
| Inventory collection | Yes | Yes | Yes |
| Guarded process termination | Force termination | Yes | Yes |
| Typed process/file remediation | Yes | Yes | Yes |

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

| Field | Method | Purpose |
| - | - | - |
| LimaCharlie organization ID | Either | The organization UUID containing your sensors. Find it in LimaCharlie organization settings. |
| REST API key | API key | The credential used to discover sensors and perform enabled endpoint operations. Forge stores it as an encrypted managed secret. |
| Output sensor tag | Output | One sensor tag used to select forwarded events. Use the same value in Forge, the LimaCharlie Output and the sensors. |
| Output webhook URL | Output | Generated after saving. Copy it into the Output destination host. |
| Signing secret | Output | Generated by Forge and shown once. Copy it into the Output secret key. Normal connection reads show only whether it is configured. |

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](https://docs.limacharlie.io/5-integrations/outputs/).

See LimaCharlie's [permission reference](https://docs.limacharlie.io/8-reference/permissions/)
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](/integrations/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:

| Permission | Purpose |
| - | - |
| `sensor.list` | Discover sensors |
| `sensor.get` | Resolve and verify an exact sensor |
| `sensor.task` | Submit supported typed endpoint tasks |
| `payload.ctrl` | Publish the versioned Forge endpoint helper |
| `payload.use` | Run the helper |
| `output.list` | Inspect task-response streams |
| `output.set` | Create the temporary task-response stream |
| `output.del` | Remove that temporary stream |

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 Output field | Value |
| - | - |
| Module | `webhook_bulk` |
| Stream/type | `event` |
| Destination host (`dest_host`) | Generated Forge webhook URL |
| Secret key (`secret_key`) | Generated signing secret |
| Tag (`tag`) | Exact Output sensor tag saved in Forge |
| Batching (`sec_per_file`) | `1` |
| Compression (`is_compression`) | Enabled |
| Event allowlist (`event_white_list`) | Newline-separated types below |

```text theme={"system"}
NEW_PROCESS
CODE_IDENTITY
DNS_REQUEST
NETWORK_CONNECTIONS
NEW_TCP4_CONNECTION
NEW_TCP6_CONNECTION
```

LimaCharlie documents the destination and signature fields in
[Webhook Bulk](https://docs.limacharlie.io/5-integrations/outputs/destinations/webhook-bulk/)
and the single-tag and newline-separated filters in
[Stream structures](https://docs.limacharlie.io/5-integrations/outputs/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

| Limit | Value |
| - | - |
| HTTP body, including compression | 8 MiB |
| Decompressed body | 32 MiB |
| Individual event | 256 KiB |
| Events per delivery | 8,192 |
| Normalized process and network rows per delivery | 8,192 |
| Authenticated deliveries per connection | 1,200 per minute |

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](https://docs.limacharlie.io/8-reference/edr-events/)
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.

| Event | Forge evidence and limit |
| - | - |
| `NEW_PROCESS` | Observed executable name and scoped process identity, with hashes where supplied. Does not prove the process is still running. |
| `CODE_IDENTITY` | File identity alone does not prove a process join. Missing joins remain unresolved; Forge does not invent a process. |
| `DNS_REQUEST` | Observed domain resolution. Does not prove a connection, conversation or browser extension. |
| `NETWORK_CONNECTIONS` | Supported outbound destinations from the snapshot. Overlapping rows are not treated as usage counts. |
| `NEW_TCP4_CONNECTION`, `NEW_TCP6_CONNECTION` | Outbound destination evidence when the event supplies a valid remote address and port. |
| Native UDP socket notifications | Local socket address and port do not prove a remote destination. They are not included in the recommended Output allowlist. |

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.