Each firewall change triggers a framework check in GTT's new Defense Halo service

A network engineer opens a firewall port so a vendor can reach a server, then closes the ticket. Defense Halo is built for that edit. Its first vulnerability module tests the new configuration against security frameworks at the moment it changes ^[4].

Fletcher Keister, GTT's chief product and technology officer, said every security leader he speaks with is "fighting the same battle against the clock" ^[12]. A vulnerability gets riskier the longer it goes undetected, according to Keister ^[13]. The product is aimed at shrinking the time vulnerabilities and threats go unnoticed on corporate networks ^[2].

Under the AI framing, the vulnerability side does jobs a buyer can test directly. A second module maps known vulnerabilities to the specific assets a customer runs and ranks them by priority ^[5]. A live model of the network shows every host-to-host connection. When a new vulnerability surfaces, that model feeds the platform's exposure assessments ^[9].

Here's what teams tell themselves happens next: an AI-generated remediation plan comes back in real time ^[6] and the gap closes. Here's what the description supports. Automated action is described for confirmed threats, which GTT says can be contained through runbooks on compatible devices ^[8]. For a loose firewall rule or an unpatched server, what arrives is a plan. The exposure lasts until someone on the customer's team approves the plan and ships it.

The architectural case comes from Amy DeCarlo, principal analyst for security and data center services at GlobalData. She said most security products analyze traffic only after it has been collected and normalized, a step she said adds latency, cost and blind spots ^[14]. She called GTT's choice to run AI inference inside its own network "architecturally different" ^[15]. Endpoint-centric and log-centric platforms, she said, "are not positioned to match" ^[17].

I think the clearest buyer is a company whose security team is small next to the network it defends, since GTT runs the stack and each customer gets its own isolated instance ^[11]. GTT did not disclose pricing or say who the early customers are ^[16].

Two figures from a team's own change log sort the decision: how often firewall and device configs change, and how long a flagged fix takes to clear change control. Frequent changes with fast fixes is the strongest case, because on-change checks and a ranked list match how the team already works. Frequent changes with slow fixes means findings arrive faster than the team closes them, so a trial mostly measures the change process. Rare changes with fast fixes puts the value on detection and containment, and that depends on how much of the fleet counts as compatible ^[8]. Rare changes with slow fixes is the hardest case to justify. In every quadrant, the trial metric is median time from a flag to a shipped fix.