AI infrastructure honeypots reveal real attacker behavior at scale

At a glance

What this is: Zenity’s honeypot research shows how attackers are probing, exploiting, and hijacking exposed AI infrastructure in the wild.

Why it matters: It matters because AI gateways, inference endpoints, and agentic systems now face the same identity and exposure discipline expected of other high-trust assets, but with faster attacker adaptation.

By the numbers:

• The LiteLLM campaign ran with almost 3,000 exploitation attempts from more than 20 source IPs.

👉 Read Zenity's analysis of real attacker behaviour against AI infrastructure

Context

AI infrastructure is becoming a target-rich identity surface because exposed inference servers, gateways, and agent endpoints combine authentication, routing, and credential handling in one place. When those control points are visible on the internet, attackers can probe them like any other high-value access layer, then pivot into provider keys, master tokens, or downstream execution paths.

The governance gap is that many teams still treat AI systems as application services rather than privileged identity brokers. That framing breaks down when a single endpoint can authenticate to multiple providers, expose administrative functions, and be repurposed for offensive activity. For AI infrastructure, the question is no longer whether the stack can be reached. It is whether access, egress, and execution are actually contained.

Key questions

Q: How should security teams protect exposed AI infrastructure from real attacker probing?

A: Treat exposed AI gateways, inference servers, and agent endpoints as privileged control points. Require authentication, restrict outbound destinations, segment administrative functions, and patch internet-facing components quickly. The key is to reduce both discoverability and blast radius, because attackers are using these systems as entry points, credential targets, and execution platforms.

Q: Why do AI gateways create more risk than ordinary application proxies?

A: AI gateways often hold master keys, provider credentials, and routing authority for multiple downstream services. If one gateway is compromised, the attacker may inherit access to every connected provider and use the proxy itself to exfiltrate secrets or run malicious requests. That concentration of trust makes the gateway a high-value identity broker.

Q: What do security teams get wrong about AI endpoint exposure?

A: They often assume the main risk is model misuse, when the bigger issue is infrastructure abuse. Exposed endpoints can be scanned, exploited, used for credential theft, or repurposed as anonymous compute for offensive operations. The right lens is not just prompt safety, but identity, egress, and execution containment.

Q: Who is accountable when compromised AI infrastructure is used to attack others?

A: Accountability sits with the organisation operating the exposed infrastructure, even if the attacker is the one initiating the offensive activity. If the environment can be used to target third parties, the owner needs controls for access, logging, egress, and session governance. This is a shared operational and security responsibility, not a purely vendor problem.

Technical breakdown

AI gateway exploitation and credential exfiltration

AI gateways such as LiteLLM sit in a high-trust position because they broker traffic between clients and multiple model providers. That makes them more than a proxy. They often hold master keys, provider API credentials, and routing logic that attackers can abuse through remote code execution or server-side request forgery. In the Zenity findings, exploitation progressed from probing to sandbox escape attempts and then to OS command execution, which indicates structured chaining rather than random scanning. The security consequence is straightforward: compromise of the gateway can expose every provider connected behind it, multiplying blast radius across the AI estate.

Practical implication: treat AI gateways as privileged control planes and protect them with strong authentication, egress restriction, and rapid patch enforcement.

SSRF against AI endpoints and connection-test abuse

Server-side request forgery in AI infrastructure is dangerous because the proxy or gateway can be tricked into making outbound requests on behalf of the attacker. Zenity’s research shows connection-test functionality being used to redirect the proxy’s own traffic to attacker-controlled servers, turning the AI system into a credential-exfiltration channel. This is a classic trust inversion: the system believes it is validating connectivity, while the attacker is using that validation path to harvest secrets. In AI environments, SSRF is especially damaging because the outbound request path may already be pre-authorised to model providers and other internal services.

Practical implication: isolate connection-test features, restrict outbound destinations, and monitor for AI proxy traffic that leaves approved provider boundaries.

Hijacked AI infrastructure as offensive compute

The most consequential pattern in the report is not just compromise, but repurposing. Once attackers gain access to exposed AI infrastructure, they can run autonomous offensive agents, route their own multi-agent workflows, or use the endpoint as anonymous compute after exhausting paid credits elsewhere. That changes the risk model from theft of capacity to misuse of delegated runtime. The owner may see only outbound traffic, cost spikes, or odd execution traces, while the attacker uses the infrastructure to attack third parties. This mirrors cryptomining in structure, but the downstream impact is broader because the environment can now participate in live intrusion activity.

Practical implication: monitor for long-running sessions, unexpected agent orchestration, and outbound attack traffic originating from AI runtime environments.

Threat narrative

Attacker objective: Attackers want either credentials and privileged access to AI services or free runtime they can redirect into offensive operations against third parties.

1. Entry begins with exposure of AI gateways, inference servers, or agent endpoints to internet scanning and targeted probing.
2. Escalation occurs when attackers exploit SSRF or remote code execution paths to reach provider credentials, master keys, or administrative functions.
3. Impact follows when compromised infrastructure is used to run autonomous offensive agents, route attacker workflows, or exfiltrate credentials and reconnaissance data.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI infrastructure is now a privileged identity layer, not just an application layer. The report shows gateways and endpoints being attacked for credentials, routing control, and execution authority, which means the security boundary is the identity path, not the model prompt. That changes how teams should think about exposure, access, and containment. Practitioners should classify AI infrastructure as high-trust identity infrastructure.

AI gateway compromise creates identity blast radius rather than isolated service failure. When a proxy holds master keys and provider credentials, one exploited endpoint can expose multiple downstream AI providers at once. This is the same structural problem that appears in other NHI control-plane failures, but with faster scale because the gateway is an aggregation point. The practical conclusion is that one compromised broker can become many compromised services.

Runtime abuse of exposed AI systems is a new form of delegated access misuse. The attacker does not need to own the original workload if they can repurpose its runtime to carry out their own operations. That means governance must account for who can use the environment, not just who provisioned it. Practitioners should treat AI execution paths as controlled assets with explicit ownership and outbound accountability.

Connection-test and SSRF abuse show that AI trust boundaries are being inverted at the protocol layer. A function meant to verify connectivity can become a channel for credential theft when outbound requests are not tightly constrained. This is a control-plane failure, not a model failure. Teams should re-evaluate any AI feature that can trigger external requests on the system’s behalf.

Observed attacker behaviour should be driving AI detection engineering now. Zenity’s value here is not the existence of a theoretical attack path, but the proof of what adversaries actually do once they find exposed AI infrastructure. That makes behavioral telemetry from honeypots a better seed for detections than abstract threat models alone. Practitioners should align monitoring to observed exploit sequences, not assumed ones.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, showing that scope control materially changes outcomes.
• For a broader governance lens, see OWASP NHI Top 10 for the risks that emerge when AI systems can act, connect, and persist with too much trust.

What this signals

AI infrastructure governance will increasingly converge with machine identity and privilege control. The operational lesson from this research is that exposed AI systems cannot be treated as ordinary app endpoints, because they broker credentials, delegate execution, and can be repurposed by attackers. Teams that already manage service accounts and workload identity should extend those controls to AI gateways and agent runtimes, including monitored egress and explicit ownership. With only 44% of organisations reporting any AI agent policies, the gap is still wide enough for attackers to keep moving faster than governance.

Identity blast radius is the concept practitioners should now track. When one AI control plane can expose multiple model providers, the harm is not limited to a single server or tenant. The practical task is to map where secrets, routing, and execution authority concentrate, then reduce the number of places where one compromise can fan out into many. That framing is useful across NHI, workload identity, and emerging agentic systems.

Teams running self-hosted AI stacks should expect internet-facing discovery, rapid vulnerability exploitation, and repurposed runtime abuse to remain common. The strongest near-term signal is not perfect prevention, but whether monitoring can detect unusual outbound use, agent orchestration, or credential movement before the environment becomes a launch point for attacks on others.

For practitioners

• Harden AI gateways as privileged control planes Place authentication, strict network segmentation, and outbound allowlisting around gateways that broker model traffic or store provider credentials. Review whether any administrative endpoint is reachable from the public internet. Apply the same containment standards used for other high-trust identity brokers.
• Reduce the value of exposed connection paths Separate health checks and connection-test functions from secret-bearing traffic flows. Ensure those checks cannot be redirected to arbitrary hosts or attacker-controlled servers. Monitor for unexpected destination changes, especially where proxy traffic should only reach approved AI provider domains.
• Detect offensive use of AI runtime environments Alert on long-running sessions, repeated retry loops, sudden bursts of outbound scanning, and multi-agent orchestration that does not match normal workload behaviour. Correlate those signals with cost anomalies and internet-facing egress from AI endpoints. Review exposed systems for evidence of task chaining or external target enumeration.
• Treat exposed AI endpoints as incident-prone assets Maintain inventory of self-hosted inference servers, gateways, and agentic endpoints across cloud regions. Prioritise patching for reachable AI components as soon as a CVE is published, because exploitation can begin within days. Use the 52 NHI Breaches Report to map how exposed credentials and service access have repeatedly amplified breach impact.

Key takeaways

• AI infrastructure is being attacked as an identity and execution surface, not just as a model stack.
• Fast exploitation, credential theft, and hijacked runtime abuse show that exposed AI components create real operational blast radius.
• Teams should govern AI gateways and agent endpoints like privileged infrastructure, with authentication, egress controls, and behavioural detection.

Key terms

• AI Gateway: An AI gateway is the control point that brokers requests between applications and one or more model providers. In practice it often holds routing logic, authentication context, and sensitive credentials, which makes it a privileged identity layer rather than a simple network proxy.
• Server-side Request Forgery: Server-side request forgery is a flaw where an attacker makes a server send requests on their behalf. In AI infrastructure, that can turn connectivity checks or outbound validation into a path for secret theft, internal probing, or redirection to attacker-controlled systems.
• Identity Blast Radius: Identity blast radius is the amount of downstream access, systems, or data exposed when one privileged identity or control plane is compromised. In AI environments, a single gateway or endpoint can multiply that radius by holding keys, routing authority, and execution privileges for several providers.
• Agent Hijacking: Agent hijacking is the repurposing of an AI agent or agent runtime by an attacker for their own activity. The original owner may lose visibility into the session while the system continues executing tasks, scanning targets, or chaining actions on behalf of the adversary.

What's in the full report

Zenity's full research covers the operational detail this post intentionally leaves for the source:

• CVE-by-CVE timelines showing how quickly AI gateway exploitation followed public disclosure
• Observed attacker payload structures, including probe-to-exploit progressions and credential exfiltration attempts
• Session-level evidence from hijacked AI endpoints used for offensive operations and autonomous agent runs
• Detection rule examples built from real attacker behaviour, not just theoretical attack paths

👉 Zenity's full research includes the CVE timelines, attacker TTPs, and defender recommendations behind these findings.

Deepen your knowledge

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