AI deployment reconnaissance is exposing LLM and SSRF gaps

At a glance

What this is: GreyNoise’s honeypot data shows two distinct attack campaigns targeting AI infrastructure, one focused on SSRF exploitation and one on large-scale LLM endpoint enumeration.

Why it matters: This matters because exposed AI services now create both a credential-adjacent attack surface and a discovery problem, which means IAM, API access, and egress controls need to be designed together.

By the numbers:

• The SSRF campaign spiked to 1,688 sessions in 48 hours over Christmas.
• Attackers probed 73+ LLM model endpoints during the enumeration campaign.

Context

AI infrastructure creates a new governance problem when public endpoints, model-pull features and outbound callbacks are left open to unauthenticated traffic. That turns ordinary platform behaviour into a reconnaissance surface that attackers can map before they ever reach a sensitive model or backend system.

The article’s core finding is not that one exploit worked, but that attackers are systematically testing where AI environments trust external input, trust outbound requests, and trust proxy behaviour. That is a control-design issue, not just a detection issue. For identity teams, the lesson is that exposed AI services need governed service identities and restricted egress, not only perimeter filtering.

Key questions

Q: What breaks when AI platforms allow untrusted model pulls and outbound callbacks?

A: The platform stops acting as a controlled service and starts acting as an outbound relay for attacker-chosen destinations. That creates SSRF risk, lets adversaries validate payload success, and can expose internal reachability or proxy behaviour. The practical failure is not only exploitation, but the loss of trust boundaries around network egress and remote content retrieval.

Q: Why does large-scale LLM endpoint probing matter before any compromise is visible?

A: Because reconnaissance tells attackers which endpoints exist, which formats are accepted, and which services are worth deeper attention. That information can feed later credential abuse, proxy misuse, or cost-exhaustion attacks. If teams only look for successful exploitation, they miss the stage where the target map is being built.

Q: How can security teams tell AI probing apart from ordinary user traffic?

A: Look for repeated low-noise requests across many model endpoints, families, or prompt patterns from the same source, especially when the content is deliberately harmless. Normal user traffic is usually narrower and more task-specific. Probing traffic often looks like behaviour testing, not application use, even when the payloads themselves appear benign.

Q: Should organisations prioritise egress control or endpoint rate limiting for exposed LLM services?

A: They should do both, but egress control usually reduces the blast radius first because it blocks SSRF validation and callback confirmation. Rate limiting is still important for discovery and scraping, yet it does not stop a service from phoning home if outbound access remains broad. The right order is to cut trust in external requests, then tune volume controls.

Technical breakdown

How SSRF turns AI platform features into outbound request abuse

Server-side request forgery happens when an application can be tricked into making requests on behalf of the attacker. In this case, model-pull paths and webhook parameters became the trigger points, because they let untrusted input influence outbound connections. The real danger is not the request itself, but the server’s authority to reach internal or attacker-controlled destinations. If those outbound requests are not constrained, the application becomes a relay for validation, probing, and sometimes data access. Practical implication: Treat any feature that fetches remote content as a governed network action, not a convenience function. See the AI Infrastructure Workload Identity Guide. See the AI Infrastructure Workload Identity Guide.

Practical implication: Restrict outbound fetches and model-pull behaviour to trusted destinations only.

Why endpoint enumeration becomes reconnaissance for larger exploitation

Enumeration is the phase where attackers learn which endpoints exist, which formats they accept, and which responses reveal a useful target. Here, the probing covered multiple major model families and used innocuous prompts to avoid alarms while fingerprinting behaviour. That matters because discovery at scale is often the first step in a broader abuse pipeline, including proxy abuse, token theft, or API cost exploitation. The attacker does not need a breach to extract value from the map they build. Practical implication: Detect broad, low-noise request patterns across model endpoints and treat them as pre-compromise activity. See the AI Agent Memory Security Guide. See the AI Agent Memory Security Guide.

Practical implication: Alert on broad, low-noise probing across multiple model endpoints.

Why callback validation and shared fingerprints expose organised tooling

OAST callbacks are a standard way to confirm whether an SSRF payload caused a server to reach out. In this article, the same JA4H signature appeared in 99% of attacks, which points to repeatable automation rather than ad hoc testing. Shared fingerprints and callback domains matter because they let defenders separate random internet noise from coordinated tooling. For identity and access teams, this also shows how attacker infrastructure often clusters around repeatable systems, not single accounts. Practical implication: Correlate callback domains, JA4 fingerprints, and source IP patterns to distinguish research noise from abuse. See the AI Supply Chain Security and AI-BOM Guide. See the AI Supply Chain Security and AI-BOM Guide.

Practical implication: Correlate fingerprints and callback domains to classify abuse quickly.

Threat narrative

Attacker objective: The objective is to map exposed AI infrastructure, identify misconfigured proxy and model endpoints, and prepare a larger exploitation path.

1. Entry occurred through SSRF-enabled model-pull and webhook behaviours that allowed untrusted input to trigger outbound requests.
2. Credential or access discovery followed when attackers enumerated more than 73 LLM endpoints and validated responses with innocuous prompts and callback checks.
3. The impact was reconnaissance at scale, with attackers building a target list for future exploitation of exposed AI infrastructure and proxy paths.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

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 deployment reconnaissance is now a governance problem, not just a detection problem. Attackers are learning which model endpoints exist, which request patterns succeed, and which outbound channels will validate their payloads. That means exposed AI systems are being profiled before they are exploited, and the governance gap sits at the boundary between application behaviour and network trust. Teams need to treat exposed AI services as managed attack surfaces, not passive workloads.

Model-pull trust is a hidden identity boundary. When an AI platform is allowed to fetch models or remote resources from broad sources, it inherits trust from the registry, the network, and the caller in the same transaction. That is an identity decision as much as a platform decision because the service is acting with delegated authority. Workload identity becomes essential when the platform itself is allowed to initiate trusted outbound action.

Discovery at scale is the precursor to credential and API abuse. The 80,469-session enumeration campaign shows that attackers invest heavily in simple probing when the reward may be commercial API access, proxy exposure, or future service compromise. The specific control gap is not just unauthenticated access, but the absence of rate limits, anomaly detection, and response normalisation on AI endpoints. Practitioners should assume that low-and-slow probing is part of the threat model.

Shared automation signatures give defenders a practical way to separate noise from intent. A single JA4H signature appearing in 99% of attacks suggests tooling reuse, which makes fingerprint correlation useful for prioritisation. That does not prove benign intent, but it does show that AI-facing services can often be grouped by tooling family rather than isolated request. The practitioner conclusion is to build detection around repeated infrastructure behaviour, not just payload strings.

AI infrastructure is becoming the new perimeter for identity abuse. Once model endpoints, proxy servers, and outbound callbacks are exposed, the question becomes who is allowed to request, relay, and validate external resources on behalf of the platform. That is exactly where identity governance needs to meet cloud and application security, because the platform’s delegated authority can be abused even when no human account is directly compromised.

From our research library:

• 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
• Read next: LLM Provider API Key Security and LLMjacking Guide

What this signals

Enumeration pressure is now a standing condition for exposed AI services. The question for practitioners is no longer whether a model endpoint will be probed, but whether the probing will reveal a useful path to proxy abuse, credential theft, or cost escalation before detection catches up. That shifts security design toward response normalisation, request shaping, and egress containment rather than relying on payload signatures alone.

Identity governance now extends to the service’s outbound authority. When a model pull or webhook can trigger external requests, the service itself is operating with delegated trust that must be limited, monitored, and revocable. Security teams should treat outbound fetch capability as a privileged action, especially where the service can touch credentials, APIs, or internal network paths.

AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.** That is the context behind this article's reconnaissance pattern: exposed AI systems are already being catalogued for future abuse, and the surrounding platform layer is often the weaker control plane.

For practitioners

• Restrict model pulls to trusted registries Allow AI platforms to fetch models only from approved sources, and block arbitrary registry URLs or unauthorised remote content retrieval.
• Filter outbound traffic for SSRF containment Apply egress rules so that model-pull paths, webhook handlers, and other fetch functions cannot reach attacker-controlled callback infrastructure.
• Detect enumeration across model endpoints Alert when a single source probes multiple AI endpoints, model families, or prompt formats in a short window, even if each request looks harmless.
• Block known callback infrastructure patterns Watch for OAST-style callback domains and repeated fingerprint matches that indicate validation of SSRF payload success.
• Correlate JA4 fingerprints with source IP history Use network fingerprinting and source reputation together so repeated automation can be separated from isolated scans and ranked by likely intent.

Key takeaways

• Attackers are probing AI platforms as a reconnaissance target, not only as a direct compromise target.
• The article combines a high-volume enumeration campaign with an SSRF campaign, which shows that exposed AI infrastructure attracts both discovery and abuse activity.
• Restricting model pulls, tightening egress, and detecting broad endpoint probing are the controls that change the risk profile fastest.

Related NHI Mgmt Group resources: AI Infrastructure Workload Identity Guide · LLM Provider API Key Security and LLMjacking Guide · Agentic AI Security Guide · DeepSeek database exposure 2025

Key terms

• 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.
• API Enumeration: The process of systematically probing application interfaces to discover accessible data, objects, and functions. In identity incidents, it often follows a valid token or account compromise and can reveal far more than a single login screen would expose.
• Out-of-Band Application Security Testing: Out-of-band application security testing validates whether an application can make external callbacks or reach attacker-controlled infrastructure during a test. Security teams use it to confirm exploitability in live or near-live systems when a vulnerability can be triggered through network interaction rather than obvious local behaviour.
• Egress Filtering: A network control that restricts where outbound traffic from a workload can go. For SSRF, it is one of the few controls that can stop a forged request from reaching metadata endpoints, internal services, or other sensitive destinations after validation fails.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the broader security programmes that govern AI services and their delegated trust.