AI infrastructure is now a target, and AI security must adapt

At a glance

What this is: This is Zenity’s analysis of GreyNoise data showing that exposed AI infrastructure is being actively mapped and probed at scale.

Why it matters: IAM and security teams need to treat AI endpoints, proxies, and agent-connected services as governed production assets because reconnaissance against them now looks operational, not experimental.

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.

Context

AI endpoint reconnaissance is the practice of probing exposed model routes, proxies, and adjacent services to see what responds, what leaks, and what can be abused later. In this case, the security gap is not the model itself but the infrastructure around it, especially internet-facing wrappers, callback paths, and egress that can be turned into an oracle.

Zenity’s analysis of GreyNoise findings shows a shift from curiosity-driven scanning to operational targeting of AI deployments. That matters for AI security programmes because these assets often sit outside the discipline used for traditional production systems, even though they can expose credentials, workflows, and downstream business actions.

The article’s central claim is that reconnaissance against AI infrastructure now needs to be handled as an identity and runtime governance problem, not just a network visibility problem. If AI systems are reachable from the internet, attackers will inventory them the same way they inventory other high-value services.

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. Without inventory, teams cannot separate expected traffic from probing. Without egress control, a trusted server can be turned into the attacker’s relay for SSRF, callback abuse, or later-stage targeting.

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. That proximity makes them high-value targets. A malicious or tampered dependency can collect multiple secret types from one runtime, turning a software issue into a broader identity exposure problem.

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. The best signal comes from combining identity context with runtime behavior, because a single innocuous prompt may mean nothing on its own. Patterns across sources, destinations, and timing are what expose reconnaissance.

Q: Should organisations prioritise infrastructure ownership over managed AI convenience for production workloads?

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.

Technical breakdown

How AI endpoint enumeration works

Attackers are using low-noise requests to discover which model endpoints, proxies, and wrappers are exposed and responsive. The goal is not immediate compromise but reliable fingerprinting, so the traffic stays bland enough to avoid common alerting while still revealing model family, routing behavior, and whether a proxy leaks access to upstream services. When a deployment sits between applications and a commercial model provider, the security boundary becomes the proxy and its controls, not the model brand. That makes discovery of exposed endpoints the first stage of a broader exploitation pipeline.

Practical implication: inventory every internet-reachable AI endpoint and proxy so reconnaissance can be detected before exploitation begins.

Why server-side request forgery matters in AI infrastructure

Server-side request forgery, or SSRF, happens when an attacker convinces a server to make requests on their behalf. In AI environments this becomes especially risky when model pulls, webhooks, or tool integrations can be steered toward attacker-controlled destinations, because the server’s trust, network location, and authentication context do the work for the attacker. The issue is not just outbound traffic. It is that AI infrastructure often has legitimate reasons to fetch models, call tools, or validate callbacks, which gives adversaries a path to turn normal behavior into a recon channel or an egress abuse channel.

Practical implication: constrain outbound destinations and treat any callback-capable AI workflow as a potential SSRF pathway.

Behavior-based detection for AI systems

Behavior-based detection looks at what an AI system does, not just the string content of a request. That matters because reconnaissance often uses innocuous prompts that are unlikely to match signature rules, yet still reveal whether a proxy, endpoint, or agent responds in a way that confirms exposure. Full identity context helps here because the same request can mean very different things depending on source, authentication state, and the surrounding workflow. In practice, the most useful signal is not a single malicious payload but a pattern of unusual access, unexpected callback resolution, and model enumeration across multiple providers.

Practical implication: correlate identity, source, and tool activity so low-signal probing is visible as a pattern rather than isolated noise.

Threat narrative

Attacker objective: The attacker wants a reliable inventory of exposed AI infrastructure and a path to abuse outbound trust relationships for later exploitation.

1. Entry occurs through exposed AI endpoints, model proxies, and webhook-capable services that are reachable from the internet.
2. Attackers then enumerate which model routes, callback paths, and upstream integrations respond, using low-noise probes to avoid alerting.
3. In the SSRF campaign, malicious parameters force servers to initiate outbound requests, turning trusted infrastructure into an attacker-controlled relay.
4. The likely objective is to build a target map for later credential abuse, workflow manipulation, or data exfiltration against AI-enabled systems.

Breaches seen in the wild

• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Exposed AI endpoints create an identity and trust problem, not just a scanning problem. When proxies, wrappers, and callback services sit between applications and model providers, the real control point becomes the trust boundary around those components. That aligns with OWASP-NHI thinking because the exposed surface often includes credentials, tokens, and delegated access paths that are invisible if teams only look at the model layer. The practitioner conclusion is that AI inventory must include the identities and egress paths attached to each deployment.

Model enumeration is a named concept practitioners should track as a control gap. GreyNoise’s findings show attackers building target lists by testing which endpoints respond and which configurations leak useful behavior. That means the failure is not merely exposure but the absence of a governed inventory of AI-facing routes and services. The practitioner conclusion is that teams should treat enumeration as a precursor condition for later compromise, not as harmless background noise.

Access review processes were designed for resources that remain stable long enough to be reviewed. That assumption breaks down when AI systems, proxies, and agent workflows can be discovered and probed continuously, with their exposure changing faster than governance cycles can catch up. The implication is that identity and runtime controls around AI infrastructure have to move closer to issuance, routing, and callback enforcement rather than depend on periodic review alone.

Threat actors are applying the same lifecycle logic to AI infrastructure that they previously used against VPNs, CI systems, and other high-value services. The pattern is familiar: inventory first, then probe for leaks, then use the discovered surface for follow-on access. For identity and security leaders, that means AI adoption now creates a new class of externally discoverable attack surface that must be owned from day one. The practitioner conclusion is to govern AI systems as production assets with explicit ownership, not as experimental exceptions.

From our research library:

• 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.
• Read next: AI Security Platform Buyer's Guide

What this signals

Model enumeration is now part of the AI threat lifecycle. The first operational mistake many teams make is treating exposed endpoints as a deployment detail instead of an attack surface. Once an attacker can inventory model routes and callback paths, the next phase usually shifts toward credential misuse, SSRF abuse, and workflow targeting.

AI endpoint reconnaissance is a governance problem as much as a detection problem. Security teams need ownership, logging, and egress constraints at the same time, because each one closes a different part of the attack path. The programme implication is straightforward: if the AI system can be discovered externally, it must already have a named owner and an enforced boundary.

For practitioners

• 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.
• Block known validation domains and probe patterns Flag or deny resolution of out-of-band testing domains and repeated benign-looking prompts that match the published reconnaissance patterns.
• Treat AI deployment as production infrastructure Assign named ownership, logging expectations, and rate limits to each AI-facing service before it is exposed to users or internal applications.

Key takeaways

• Exposed AI infrastructure is now being actively mapped and probed, which makes inventory and ownership a security requirement rather than a housekeeping task.
• The article’s evidence points to both endpoint enumeration and SSRF-style abuse, showing that attackers are already testing multiple ways to interact with AI systems.
• Teams that want to stay ahead need egress control, identity-aware monitoring, and explicit governance for every internet-reachable AI service.

Key terms

• AI Endpoint: An AI endpoint is an external service or API that receives data from an application for model inference, classification, or generation. From a governance perspective, it behaves like a controlled integration that can expand privacy exposure if inputs, outputs, and retention are not explicitly managed.
• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• AI proxy: An AI proxy is an intermediary service that routes application requests to a model provider or local model endpoint. In practice, it often becomes a hidden control point for authentication, logging, egress, and policy enforcement, which means it must be governed like privileged infrastructure.
• Behavioral Detection: A monitoring approach that looks for unusual activity rather than relying only on static inventories. For SaaS integrations, it detects drift in token use, data movement, timing, and endpoint behavior so teams can spot compromise, misuse, or automation that no longer matches its expected pattern.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.