> ## 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.
# Huntress API
> Investigate and resolve Huntress incidents, read agents and detections, and manage access rules — host isolation, incident resolution, and portal access changes always require technician approval
The Huntress API tool gives Neo agents direct access to the Huntress Platform API — read the incident behind a Huntress-generated ticket, gather the evidence, approve the remediation, isolate a compromised host, and file the travel exception that stops an escalation recurring.
Automatically enabled when you configure Huntress permissions in your agent workflow. No manual toggle needed.
Agents load the Huntress API skill first, which carries the endpoint table, request-body shapes, and the ordering rule that matters most: **every remediation must be approved before an incident can be resolved.**
## What It Does
* Pull the incident report behind a Huntress ticket — findings, indicators, severity, affected host
* Approve or reject the report's remediations, then resolve the incident or escalation
* Look up any deployed host, edit its tags and tamper protection, isolate it or release it
* Investigate signals, managed identities and their MFA/risk state, exposed ports, and SIEM logs
* Create time-boxed travel/geolocation exceptions that expire on their own, plus VPN and IP rules
* Enumerate, create, rename, or remove customer organizations
* Read who has portal access, invite users, change permission levels, revoke access
* Read summary reports for QBRs and invoices for billing reconciliation
## Permission Groups
| Permission Group | What It Covers |
| ------------------------- | ------------------------------------------------------------------------------------------------------------- |
| **Incidents** | Incident reports, their remediations, and escalations — including resolution |
| **Agents** | Deployed hosts: details, tags, tamper protection, isolation, removal |
| **Detections** | Signals, identities, external ports, platform actions, known VPNs, SIEM queries — **read-only by API design** |
| **Unwanted Access Rules** | Travel/geolocation, VPN, and IP access rules |
| **Organizations** | Customer organizations and accounts — the scope every other call uses |
| **Users** | Portal memberships and permission levels |
| **Reporting & Billing** | Summary reports and invoices — **read-only** |
Each group has an access level: **Disabled**, **Read Only**, or **Read/Write**. Detections and Reporting & Billing only ever offer Read Only — Huntress has no write endpoint for them.
## Access Profiles
All groups Read Only. The agent can investigate any alert, host, identity, or report but never changes anything.
Incidents at Read/Write (still requires technician approval on every write). Everything else Read Only — enough to work an alert to resolution without touching hosts, access rules, organizations, or users.
Every writable group at Read/Write, with technician approval required on all writes — not just the mandatorily-forced ones. The cautious rollout tier.
Unwanted access rules and organization changes run autonomously. Host isolation and removal, remediation approval, incident resolution, and portal access changes still always require technician approval.
## Safety Controls
| Control | Behavior |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Technician-in-the-Loop** | Require human approval for writes — configurable per group |
| **Agents protection** | Isolating, releasing, or removing a host always requires technician approval, regardless of settings |
| **Incidents protection** | Approving or rejecting remediations and resolving an incident or escalation always require technician approval — approval executes assisted remediations on the endpoint immediately |
| **Users protection** | Inviting, changing, or removing portal access always requires technician approval |
| **Read-only areas** | Detections and Reporting & Billing have no write endpoint |
| **Subscriptions excluded** | Huntress's reseller subscription endpoints are deliberately not exposed to agents — Reporting & Billing is for reconciliation, not buying |
Host isolation is asynchronous. A successful call returns the host as "Pending Isolation", not isolated — the agent is instructed not to report a host as contained until Huntress confirms it.
## How to Configure
Save your Huntress API key pair in the Neo Dashboard under the **Security** integrations category. See [Connecting Huntress to Neo](/integrations/huntress/connecting-to-neo).
The default Huntress **account** API key is read-only. Writes need a user-based key whose Huntress user holds the matching portal permission.
In your agent workflow's **Integrations** tab, choose an access profile or customize each permission group.
Agents, Incidents, and Users always require technician approval on writes; decide whether access rules and organizations should too.
Start with **Read Only** or **Helpdesk**. Because containment and remediation approval are permanently gated, most of the value — the alert context arriving with the ticket — is available before you grant any write access at all.