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

# Connecting ThreatLocker to Neo

> Save your ThreatLocker Portal API URL and key in Neo, and decide what each agent can do

You connect ThreatLocker once at the MSP level, then turn it on per agent. Setup takes a few minutes.

<Info>
  ThreatLocker uses a single API URL and key per MSP. Save them once and every agent that has ThreatLocker permissions can use them.
</Info>

## 1. Find your API URL and key in ThreatLocker

<Steps>
  <Step title="Find your Portal API URL">
    In the ThreatLocker Portal, open the **Help** menu and look for **ThreatLocker Access**. Copy the API URL shown there exactly — it's specific to your ThreatLocker instance, so don't guess or reuse another MSP's URL.
  </Step>

  <Step title="Create an API Auth Key">
    Go to the **Administrators** page and create an API User, then generate its Auth Key.

    <Tip>
      Copy the key somewhere safe once it's generated — you won't be able to view it again in ThreatLocker.
    </Tip>
  </Step>
</Steps>

## 2. Add the credentials in Neo

<Steps>
  <Step title="Open Integrations">
    In the Neo Dashboard, open **Integrations** and find the ThreatLocker card, under Security.
  </Step>

  <Step title="Save the API URL and key">
    Paste both values and click **Save**.
  </Step>
</Steps>

## 3. Turn ThreatLocker on per agent

Each agent decides whether it uses ThreatLocker and which areas it can touch. Open the agent, go to the Integrations section, and configure the ThreatLocker block.

### Pick an access profile

<CardGroup cols={2}>
  <Card title="Read Only" icon="magnifying-glass">
    Every area set to read only. The agent can look up computers, applications, policies, and approval requests, but never makes changes.
  </Card>

  <Card title="Helpdesk" icon="headset">
    Approval Requests set to read and write — still requires technician approval on every one. Everything else read only. Fits a helpdesk agent resolving the "app is blocked" workflow.
  </Card>

  <Card title="IT Admin" icon="user-shield">
    Computers, Applications, Policies, and Approval Requests all read and write, but every write waits on a technician. A cautious rollout tier.
  </Card>

  <Card title="Full Automation" icon="bolt">
    Computers and Applications writes go through on their own. Policies and Approval Requests still always require technician approval — that never turns off.
  </Card>
</CardGroup>

### Or set each area by hand

| Area                  | Access levels you can pick          | Notes                                                                                                       |
| --------------------- | ----------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| **Computers**         | Disabled, Read Only, Read and Write | Computers, computer groups, online status, maintenance mode.                                                |
| **Applications**      | Disabled, Read Only, Read and Write | Applications and application files seen across the fleet.                                                   |
| **Policies**          | Disabled, Read Only, Read and Write | Application Control / Config Manager policies, network access policies. Writes always wait on a technician. |
| **Approval Requests** | Disabled, Read Only, Read and Write | Pending Application/Elevation/Storage Control approval requests. Writes always wait on a technician.        |
| **Organizations**     | Disabled, Read Only                 | Organization hierarchy and scoping. Neo keeps this read only.                                               |

## Safety controls

* **Approving/denying software and editing policies always wait on a technician.** This holds regardless of the agent's automation level or the access profile you picked — it's not a setting you can turn off.
* **Organizations is always read only.** Neo uses it only to see and scope to your organization hierarchy — it never changes it.
* **Path safety.** Suspicious URL paths (anything containing `..`, for example) are rejected before they reach ThreatLocker.

## Security

* The API key lives in Azure Key Vault. It is never stored in plaintext.
* All traffic to ThreatLocker goes over HTTPS, to the Portal API URL you saved for your instance.
* Write access to ThreatLocker is opt in per area, per agent.

Once your credentials are saved and an agent has permissions, the ThreatLocker tool is added to that agent automatically.
