> ## 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.

# Endpoint operations

> Connect existing endpoint agents, import verified devices, and check inventory and approved actions.

Use an endpoint integration to collect inventory and run supported Forge
operations through an agent you already deploy. Choose
[CrowdStrike Falcon](/integrations/crowdstrike),
[Microsoft Defender for Endpoint](/integrations/microsoft-defender-for-endpoint),
[SentinelOne](/integrations/sentinelone), or [LimaCharlie](/integrations/limacharlie).
For devices without one of these agents, see [Device Agent](/integrations/device-agent).

## Prepare a pilot

1. Choose a small set of devices approved for inventory and remote execution.
2. Record each device's provider ID, hostname, operating system, and owner.
3. Create a dedicated credential with the permissions in the provider guide.
4. Confirm that the provider agent is online and that remote execution is
   enabled for the operations you intend to use.

Reading provider inventory and collecting local AI configuration are different
operations. Local inventory can upload and run a Forge helper through RTR,
Live Response, RemoteOps, or LimaCharlie tasks, even when it changes no user
files. Review that execution permission before importing pilot devices.

For passive process and network observations without endpoint commands, use
the [LimaCharlie Output connection](/integrations/limacharlie#output-setup).
An API-key connection with task permissions is an operational connection.

## Connect and test

1. Open **Settings → Integrations** and select the provider.
2. Save the connection using the provider guide's fields.
3. Select **Test connection** and review the reported capabilities.
4. Resolve failed capabilities before using operations that depend on them.

A saved credential or successful authentication does not prove that remote
execution works. Check an approved pilot operation and its result separately.
Available actions depend on the provider, device platform, permissions, and
the Forge release deployed to your organization.

## Import verified devices

Import can start scheduled inventory, which can run provider-backed helpers.
Complete the pilot's execution approval before selecting **Import**. SentinelOne
keeps endpoint actions disabled until **SentinelOne RemoteOps** is explicitly
enabled; passive provider sync and host selection alone do not enable it.

1. Open **Device import**, **Host import** for CrowdStrike, or **Sensor import**
   for LimaCharlie.
2. Use the available filters and pagination to locate the pilot devices.
3. Compare the provider ID, hostname, and platform with your pilot record.
4. Select the intended devices and assign their owners where requested.
5. Import the selection and check the resulting records in **Devices**.

Forge reads each exact target from the provider again during import. Provider
identifiers and hostname determine the saved device identity. A changed target
or conflicting identity stops the import. A matching hostname alone does not
authorize attaching a target to an existing device.

Do not assign a shared server to an arbitrary employee to clear an unresolved
owner. Use the approved identity for that device and review unresolved matches.

## Check inventory and actions

1. Review the imported device's inventory schedule and requested collection.
2. Wait for a scheduled run or start an approved collection.
3. Open the run and inspect each device's result.
4. Check the resulting AI products, MCP servers, skills, hooks, and
   configuration in **Inventory**, where supported by the collection.
5. On one pilot device, test any repair or remediation action you plan to use.

A provider's installed-software list does not establish complete MCP or skill
inventory. Those records require a supported local collection. An empty,
partial, or failed collection does not prove that the device has no AI tools.

Forge records execution and verification separately. A command accepted by the
provider can still fail, time out, or return no valid result. Review the result
and any required verification before repeating a change.

## Rotate or remove a connection

To rotate credentials, update the connection and run **Test connection**.
For a configuration-only edit, leave the existing credential fields empty to
retain the saved credential. For CrowdStrike and Defender, leave both the
client ID and secret empty; credential rotation requires both values.

Before disconnecting, stop the collection schedules and complete any required
Forge-managed endpoint cleanup. Disconnecting a provider credential does not
uninstall its agent or prove that earlier endpoint configuration was removed.
Confirm cleanup results before revoking credentials needed to complete them.

## Compare collection with enforcement

| Check | What it establishes |
| - | - |
| Provider connection test | The specific API capabilities reported by that test. |
| Imported device | Stable provider-to-Forge identity and any confirmed owner mapping. |
| Completed inventory run | Returned records for the requested collection and supported profile/platform. |
| Hook validation and callback | The selected application's hook is installed and actually emits evidence. |
| Backfill result | The selected historical session data was accepted; read-model publication can follow later. |
| Routing allow/block/recovery test | Actual traffic behavior for that device and selected destination. |

Inventory, remote execution, and inline routing have separate prerequisites.
Do not infer prompt inspection from a process or DNS event. If collection
succeeds but records are not yet visible, compare the source timestamp with
projection freshness and report the delay; reinstalling the endpoint does not
repair a server-side projection backlog.


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