Connect ThreatLocker to Conduit

This walkthrough connects ThreatLocker (zero-trust endpoint protection) to Conduit. ThreatLocker needs three values, and one of them — the portal instance letter — is easy to miss because most vendors don’t have an equivalent.

Menu labels can change

The ThreatLocker steps below reflect current portal flows; labels can shift between releases. If a label differs, see ThreatLocker’s API users guide.

Before you start

You need:

• A Conduit role that can manage connections — owner or admin.
• A ThreatLocker administrator login.
• To know your portal instance letter — look at the address bar when you’re signed in to ThreatLocker: portal.<letter>.threatlocker.com. That letter (for example g or e) identifies the instance your tenant lives on. API keys only work on the instance they were created on.

Step 1 — Create an API key in ThreatLocker

1. Sign in to your ThreatLocker portal (https://portal.<letter>.threatlocker.com).
2. Create an API user / API key following ThreatLocker’s guide. Expected: an API key value, shown at creation.
3. Copy the key.

Caution

Copy the value(s) now and store them safely. Don’t paste them into chat, email, or a shared document — the connect step moves them directly into Conduit, which encrypts them at rest. If a value is ever exposed, regenerate it in the vendor portal first; the exposed one becomes useless immediately.

Step 2 — Find your Organization ID

In the ThreatLocker portal, open your Organizations page and copy the Organization ID for the organization you want the AI to operate in. This value is required — tool calls are scoped to it.

Step 3 — Connect in Conduit

1. In Conduit, go to Connections (/org/catalog), find ThreatLocker (under Security), click Connect.
2. Fill the fields:
   • API Key — from Step 1.
   • Organization ID — from Step 2 (required).
   • Portal Instance — the letter from your portal URL. Leave blank only if your portal is portal.g.threatlocker.com (the default).
3. Click Connect. Expected: Conduit validates the key against your portal instance and shows Connected. A key from a different instance, or a wrong instance letter, is rejected here with a message telling you which value to check.

Verify it worked

Ask a connected MCP client (see Connecting an AI client) to run a read-only ThreatLocker tool. Real data should come back, and the call appears in your audit log with vendor threatlocker.

Troubleshooting

Symptom	Likely cause
“ThreatLocker rejected the API key (HTTP 440)…”	The key is invalid, revoked, or expired (ThreatLocker keys expire after their inactivity window) — or it belongs to a different portal instance than the one entered. Generate a fresh key if needed, and double-check the letter in your portal URL (portal.<x>.threatlocker.com).
“ThreatLocker refused the request (HTTP 401/403) without evaluating the key…”	Conduit tries a second module before giving up — if your API user’s role can read Organizations but not Approval Requests (or vice versa), the connection still succeeds. This message only appears when neither module is readable. Check on the ThreatLocker API user: (1) its role must permit at least one of those two modules, and (2) no authorized-IP restriction should be blocking Conduit’s servers.
“ThreatLocker portal instance “…” does not exist…”	The instance letter is well-formed but that subdomain doesn’t resolve. Double-check the letter in your portal URL (portal.<x>.threatlocker.com) — usually g.
“Invalid ThreatLocker portal instance”	The instance field must be just the letter(s) from your portal URL — e.g. g — not a full URL.
Tool calls return “No ThreatLocker API credentials configured”	The connection predates the Organization ID requirement or was stored without one. Disconnect and reconnect — the form now requires it.
Need to rotate the key	Create a new API key in ThreatLocker, then update the credential at /org/catalog.

Related

• Vendor connections — credential scopes and rotation.
• Security — how Conduit encrypts and resolves stored credentials.