Topic starter
24/06/2026 11:22 pm
TL;DR: GreyNoise captured 91,403 attack sessions from October 2025 to January 2026, including two campaigns that mapped exposed AI endpoints and abused server-side request forgery to trigger outbound connections, according to Zenity’s analysis of the findings. The threat picture is shifting from experimentation to operational targeting, and existing AI security models now need inventory, egress control, and behavior-based detection.
Editorial analysis by NHI Mgmt Group, based on content published by Zenity: “GreyNoise Findings: What This Means for AI Security”.
By the numbers:
- GreyNoise’s second campaign probed more than 73 LLM model endpoints in eleven days.
- The first campaign generated 1,688 sessions in 48 hours.
Key questions
Q: What breaks when AI endpoints are exposed without inventory and egress controls?
A: Reconnaissance becomes reliable, because attackers can enumerate which model routes respond, which proxies leak behavior, and which integrations can be abused for outbound requests.
Q: Why do AI proxy libraries increase secret exposure risk?
A: AI proxy libraries often sit close to cloud credentials, API keys, and service tokens because they broker traffic between applications and models.
Q: How can security teams tell AI reconnaissance from normal usage?
A: Look for repeated low-signal probes, unexpected source patterns, unusual callback resolution, and access that touches multiple model families in a short period.
Practitioner guidance
- Inventory all exposed AI endpoints Map every internet-reachable model proxy, wrapper, webhook, and test route so you know which systems can be enumerated from outside the environment.
- Restrict outbound model and callback traffic Allow only trusted registries and approved callback destinations, and block unexpected egress paths from AI infrastructure.
- Correlate identity with AI runtime behavior Tie source IP, authentication state, and tool or transcript activity together so low-noise reconnaissance is visible as a pattern.
Bottom line: Exposed AI infrastructure is now being actively mapped and probed, which makes inventory and ownership a security requirement rather than a housekeeping task.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 8:12 am
AI infrastructure has crossed from being an experimentation surface into being an operational target. That changes the security question from whether an AI service is deployed to whether it is governable as production infrastructure. Reconnaissance at this scale means teams can no longer assume obscurity or novelty will suppress targeting. The practitioner conclusion is that AI exposure needs the same discipline applied to other internet-reachable services, but with tighter runtime visibility.
A few things that frame the scale:
- Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
A: For production workloads, organisations should usually prioritise infrastructure ownership when they need stronger privacy, compliance, network isolation, or predictable costs. Managed convenience can speed prototyping, but it often reduces control over data flow, runtime policy, and optimisation. The right choice depends on whether the workload is experimental or operationally critical.
👉 Read our full editorial: AI infrastructure is now a target, and AI security must adapt