Current + Huntress integration

Huntress is managed detection and response: a lightweight agent on each endpoint, and a security operations centre of human analysts who investigate what it surfaces and write up what mattered. Current's Huntress integration is a view-only feed into the SBR/QBR module and the company alert band. It reads what Huntress already knows and never writes back.

What the integration does

Current authenticates to Huntress with an account-level API key pair, walks your organizations, endpoints and incident reports every six hours, and stages the result as evidence for AI-assisted Strategic Business Reviews. Instead of screenshotting the Huntress dashboard the week of the review, the security numbers are already sitting on the company record when you open it.

What data flows

• Organizations — the Huntress partner roster, matched to your Current companies so every signal below lands on the right record, with the per-product counts Huntress keeps on each one.
• Protected endpoints — hostname, platform, operating system, agent version, and when the endpoint last called home, for every machine the agent runs on.
• Coverage — whether managed EDR is installed, whether the firewall is enabled, and whether tamper protection is actually switched on rather than merely configured to be.
• Incident reports — the SOC's own findings, with severity, status, the platform they came from, the kind of indicators involved, and when each was sent and closed.
• Product signals — identity seats, security-awareness learners, and log sources, which together answer what a partner actually has turned on.

The feed is one-way. Current does not isolate hosts, release isolations, uninstall agents, close or dismiss incidents, approve remediations, or create and delete organizations. Those endpoints are not in the connector's code, so they cannot be reached by a bug either. Huntress stays the place where security actions happen; Current uses the evidence.

The forensic detail stays in Huntress

Every incident report carries a body and an analyst write-up describing what happened in detail: file paths, user names, host names, attacker behaviour. Current does not mirror either. It stores the count, the severity and the generated subject line, which is what a business review is built from, and leaves the narrative where it belongs. A business review needs to say that four critical incidents were caught and closed last quarter; it does not need to reproduce the analyst's notes on each one in a document that circulates.

Unknown reads as unknown

Huntress has no online-or-offline flag on an endpoint at all — it reports when the agent last called home, and nothing more. Current works out an online state from that, and an endpoint that has never reported a callback shows as neither online nor offline rather than being guessed into one. The same rule runs through the rest of the feed: an endpoint whose firewall state Huntress does not report is unknown, not compliant, and if a whole leg of a sync fails, the counts it would have produced read blank rather than zero. A security number built by treating silence as a pass is a number that falls apart the moment a partner asks which machines it covered.

Configured is not the same as actual

Tamper protection is the clearest example. Huntress reports two values for it: what the policy asks for, and what the endpoint says is really in force — and the second can lag the first. Current judges on what the endpoint reports, never on the policy. An estate where tamper protection is configured everywhere and actually running on most of it is a real finding worth a conversation, and reading the policy value would hide it behind a clean hundred percent.

Alerts that do not double up

An open critical Huntress incident joins the same critical-security entry the company alert band already raises from your other endpoint-security feeds, rather than adding a parallel line saying the same thing. Only critical severity qualifies. Huntress reports are triaged by human analysts before they are sent, so the severity is already a considered judgement rather than a raw signal — and pulling high severity in as well would roughly triple the alerting for every workspace running Huntress, which is how a band stops being read at all.

Matching organizations to companies

Each Huntress organization is one end-customer. Current links organizations to companies by normalized name — punctuation and Inc/LLC/Ltd-style suffixes stripped — and only when exactly one company matches. Where two companies could both be the answer, the organization stays on an unmapped list for a person to decide rather than being paired on a guess. A mapping set by hand is never overwritten by a later automatic match, and mapping an organization attaches its endpoints and incidents immediately instead of waiting for the next scheduled sync.

Where the data appears

• In Strategic Business Reviews, in the security posture chapter alongside your other endpoint-security feeds such as SentinelOne and ThreatLocker.
• On the company record, where the security card shows protected endpoints, coverage gaps line by line, and the open incidents worst first.
• In dashboard security metrics, including endpoint coverage and open critical counts.
• In the company alert band, folded into the critical-security entry rather than duplicating it.

Why it matters

The security section is where most business reviews go quiet, because the strongest evidence sits in a console the account manager does not open. An MSP running Huntress for a partner like Northwind Traders can open the account and see how many endpoints are protected, which ones have no EDR installed or a firewall switched off, how many incidents the SOC raised last quarter and how many are still open — without anyone assembling a screenshot pack first. It turns the part of the review that used to be reassurance into the part that is evidence.