# Enable File Inventory

### Overview

Keeper Endpoint Privilege Manager (EPM) can collect a detailed inventory of executable files installed across the endpoints in a machine collection. This inventory gives administrators the data they need to write precise, targeted policies — for example, blocking a specific outdated version of PowerShell while allowing a newer, approved version.

{% hint style="info" icon="comment-question" %}
**Why collect file inventory?** Policies in EPM are most powerful when they target specific file paths, versions, and hashes rather than broad wildcards. File inventory is the mechanism that surfaces those specifics. Without it, you are writing policies against what you *assume* is installed; with it, you are writing policies against what is *actually* installed.
{% endhint %}

### **Uninstall on macOS**

To uninstall the Keeper agent from macOS, run the uninstall script that is included with the install script that is downloaded with the deployment package.

### How File Inventory Works

When file inventory is enabled on an endpoint, the agent scans the file system and catalogs executable files — capturing paths, metadata, and version information. That data is then uploaded to Keeper and populates the **Applications collection**, which is available in the policy builder.

The Applications collection comes pre-populated with wildcards and common path variables (e.g., {system32}, {programFiles}). File inventory enriches this collection with the real, resolved data from your actual endpoints.

{% hint style="info" icon="lightbulb-exclamation-on" %}
**Important:** If you need to create a policy targeting a specific version of an application, that version must be installed on at least one machine included in your file inventory scope before it will appear in the Applications collection.
{% endhint %}

### Why File Inventory Is Disabled by Default

File inventory is **disabled by default** for two reasons:

1. **Path variance.** File paths differ from machine to machine. EPM's policy engine is designed to use path variables and wildcards rather than hardcoded paths, so that policies work across a fleet. Enabling full file inventory before your baseline build images and variable mappings are defined can flood the system with paths that are not policy-ready.
2. **Resource cost.** A full file system scan is a resource-intensive operation. Running it on every endpoint by default — especially in large environments — would create unnecessary load. Administrators should enable it selectively and intentionally.

### Enabling File Inventory

File inventory is controlled by the keeperInventoryFull plugin setting. To enable it, you must apply a SettingsUpdate policy that sets enabled to true in that plugin's configuration.

#### Step 1 — Create a SettingsUpdate Policy

Use the following JSON as your starting point. Copy it into a new SettingsUpdate policy in the Keeper dashboard, then change "enabled": false to "enabled": true.

```json
{
  "id": "KeeperFullInventory",
  "name": "Full File Inventory Job",
  "description": "Collects full file system inventory with incremental storage and diff generation.",
  "version": "1.1.0",
  "pluginType": "Executable",
  "supportedPlatforms": ["Windows", "Linux", "macOS"],
  "dependencies": [],
  "requiredPermissions": ["MQTTSubscribe", "MQTTPublish"],
  "debugExecutablePath": "../../../../../Jobs/InventoryFull/bin/Debug/net8.0/KeeperInventoryFull.exe",
  "executablePath": "../Jobs/bin/InventoryFull/KeeperInventoryFull.exe",
  "Subscription": {
    "Topic": "KeeperFullInventory",
    "Qos": 2,
    "CleanSession": true
  },
  "metadata": {
    "category": "Inventory",
    "mqttRole": ["subscriber", "publisher"],
    "mqttTopics": {
      "publish": ["KeeperApi", "KeeperLogger"],
      "subscribe": ["KeeperFullInventory"]
    }
  },
  "enabled": true,
  "startupPriority": 0,
  "autoStart": false,
  "executionContext": "Service",
  "requiresMonitoring": false,
  "modifiedAt": "2026-01-29T23:22:04Z"
}
```

{% hint style="info" icon="pencil-line" %}
**Note:** The modifiedAt timestamp does not need to be updated — it is used internally for version tracking and does not affect policy evaluation.
{% endhint %}

#### Step 2 — Assign the Policy to a Collection

Assign the policy to the machine collection(s) where you want inventory collected. Once the policy syncs to those endpoints, the agent will begin collecting file inventory data according to the schedule defined in file-inventory.json (see below).

### The File Inventory Job (file-inventory.json)

The inventory schedule is controlled by the FileInventory job. By default, this job is configured to:

* Run once at **agent startup**
* Run again every **5 days** (7,200 minutes) on a recurring schedule

You can modify this job to suit your environment — for example, increasing the interval to reduce resource impact, or disabling the startup trigger if you prefer scheduled-only execution.

```json
{
  "id": "68112CE4-A2A8-4243-83C9-90BF8D2188A0",
  "name": "FileInventory",
  "description": "Run file inventory",
  "enabled": false,
  "asUser": false,
  "priority": 0,
  "schedule": {
    "intervalMinutes": 7200
  },
  "events": [
    {
      "eventType": "Startup"
    }
  ],
  "tasks": [
    {
      "id": "run-file-inventory",
      "name": "Run File Inventory",
      "command": "KeeperInventoryFull",
      "debugExecutablePath": "../../../../Jobs/InventoryFull/bin/Debug/net8.0/KeeperInventoryFull",
      "executablePath": "Jobs/bin/InventoryFull/KeeperInventoryFull.exe",
      "arguments": "",
      "expectedExitCode": 0,
      "scriptType": "Auto"
    }
  ],
  "mqttTopics": {
    "allowedPublications": ["KeeperLogger", "KeeperApi"],
    "allowedSubscriptions": []
  },
  "osFilter": {
    "windows": true,
    "linux": true,
    "macOS": true
  }
}
```

{% hint style="info" icon="comment-question" %}
**Tip:** The enabled field in the job JSON controls whether the job is active. This is separate from the keeperInventoryFull plugin setting. Both must be set to true for inventory collection to run.
{% endhint %}

### Platform Support

File inventory collection is supported on all three platforms:

| Platform | Supported |
| -------- | --------- |
| Windows  | ✅ Yes     |
| macOS    | ✅ Yes     |
| Linux    | ✅ Yes     |

### Resource Considerations

File inventory is a **resource-intensive** operation. A full scan reads every file path on the system and uploads the results to Keeper. During a scan, you can expect elevated CPU and memory usage compared to the agent's normal steady-state footprint.

**Recommendations:**

* **Enable inventory selectively.** Limit file inventory to reference computers, golden image machines, or dedicated test endpoints. Running it on every workstation in a large fleet is rarely necessary and generates significant overhead.
* **Use reference machines.** Choose machines that represent your standard build — one per OS, per department, or per role. Inventory from those machines will cover the applications your users actually run.
* **Only expand scope when necessary.** If a specific application version is missing from the Applications collection, add the machine it's installed on to a targeted inventory collection, collect inventory, then remove it from scope.
* **Adjust the schedule.** The default 5-day interval is a reasonable baseline. In stable environments, you may be able to extend this to weekly or monthly.

{% hint style="info" icon="down-to-dotted-line" %}
**Bottom line:** Treat file inventory like a network scan — precise, scheduled, and scoped to what you actually need. Don't run it everywhere all the time.
{% endhint %}

### What Happens After Inventory Runs

Once file inventory completes on an endpoint:

1. Collected file data is stored locally in the agent's unified storage.
2. A notification is published via MQTT to the KeeperApi topic.
3. KeeperAPI uploads the inventory data to the Keeper cloud backend.
4. The **Applications collection** in the Keeper dashboard is updated with the discovered executables.
5. Policies that reference specific file paths, hashes, or versions can now target those exact entries.

### Using Inventory Data in Policies

The Applications collection populated by file inventory is the foundation for granular policy targeting. Examples of what becomes possible:

* **Deny a specific version of an application** — e.g., block powershell.exe version 5.1.17763.x while allowing 7.x.
* **Allow elevation for a known-good installer** — target by exact file hash rather than just filename.
* **Detect and control "living off the land" binaries** — inventory reveals which native OS tools (e.g., wmic, certutil, mshta) are present on an endpoint, enabling precise command-line or file-access policies.

{% hint style="info" %}
**See Also Policy:** [Types](/keeperpam/endpoint-privilege-manager/policies/policy-types.md) · [Examples](/keeperpam/endpoint-privilege-manager/policies/policy-examples.md) · [Path Variables](/keeperpam/endpoint-privilege-manager/policies/path-variables.md) · [Wildcards](/keeperpam/endpoint-privilege-manager/policies/wildcards.md)
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keeper.io/keeperpam/endpoint-privilege-manager/user-guides/enable-file-inventory.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.