Topic starter
24/06/2026 11:22 pm
TL;DR: GreyNoise’s mapping of exposed AI endpoints points to reconnaissance patterns that are already systematic, as Zenity explains from the October 2025 to January 2026 findings. AI services need inventory, ownership, and egress controls so probing and callback abuse can be separated from normal traffic.
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: 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.
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.
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.
Glossary terms: AI Endpoint, Server-Side Request Forgery, AI proxy, Behavioral Detection
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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