AI infrastructure honeypots reveal real attacker behavior at scale

At a glance

What this is: Zenity’s honeypot research shows real attackers probing, exploiting, and hijacking exposed AI infrastructure at scale, with nearly 10,000 attack attempts and rapid exploitation of LiteLLM weaknesses.

Why it matters: For IAM, NHI, and AI platform teams, the lesson is that AI infrastructure now needs identity, authentication, and egress controls before production telemetry can be trusted to surface abuse.

Context

AI infrastructure honeypots are decoy systems that mimic real gateways, inference servers, and agent endpoints so defenders can observe attacker behaviour directly. This article is about what happens when those systems are exposed to the internet: scanning, exploitation, credential theft, and hijacked runtime use across self-hosted AI environments.

The identity governance problem is not just that AI endpoints can be attacked. It is that exposed AI infrastructure often sits in trusted positions, so one compromised endpoint can expose provider API credentials, redirect outbound traffic, or be repurposed as infrastructure for someone else’s offensive workflow. That makes AI infrastructure governance a machine identity and access control problem, not only a detection problem.

Key questions

Q: What breaks when AI gateways are treated as the source of trust for agents?

A: Trust collapses because gateways can inspect traffic, but they cannot prove who the agent is, who authorized it, or whether the action is permitted at that moment. That leaves organisations with good logs and weak governance. The missing control is a verifiable identity and an action-level policy decision outside the gateway.

Q: Why do SSRF flaws in AI infrastructure create credential risk?

A: SSRF lets an attacker use the proxy’s own trusted network position to make outbound requests on their behalf. In AI gateways, that can expose master keys, provider API credentials, and other secrets tied to the gateway’s egress path, turning request forwarding into credential access.

Q: What are the signs that an exposed AI endpoint is being abused?

A: Repeated retries, scanner-like traffic, unusual outbound destinations, and multi-agent or autonomous workflow patterns are strong abuse signals. If the endpoint still appears operational while generating traffic inconsistent with its normal role, assume it may be serving attacker-controlled activity.

Q: How should teams govern AI endpoints that can reach multiple providers?

A: Teams should govern them as high-trust machine identities with explicit access boundaries, not as generic application servers. The key decision is which provider credentials, outbound paths, and runtime permissions the endpoint truly needs, then removing anything that increases blast radius without business value.

Technical breakdown

How exposed AI gateways become high-value identity targets

AI gateways and self-hosted inference layers sit between users, models, and external providers, which makes them attractive targets for credential theft and traffic redirection. When an attacker reaches the gateway, the practical prize is often not the model itself but the gateway’s own trust relationships: provider API keys, upstream credentials, and outbound network paths. In NHI terms, the gateway behaves like an identity broker for machine-to-machine access. If authentication is weak or administrative endpoints are exposed, the attacker can reuse the gateway’s trust to reach multiple connected services through one compromise.

Practical implication: Treat AI gateways as identity-bearing control points and lock down their authentication, inventory, and outbound trust paths.

Why SSRF against AI infrastructure exposes more than a single endpoint

Server-side request forgery in an AI gateway is dangerous because the proxy’s own network position can be turned into an access primitive. In the article’s example, attackers used SSRF to push the proxy into contacting attacker-controlled servers, which can reveal master keys or provider credentials as the proxy follows outbound requests on the attacker’s behalf. That shifts the problem from web-layer abuse to identity compromise: the attacker is not only reaching an internal service, but leveraging its trusted egress and stored secrets. Once the gateway can be induced to fetch or forward on command, the blast radius extends across every connected AI provider.

Practical implication: Restrict and monitor egress from AI proxies so request forwarding cannot be abused as a credential-exfiltration path.

How hijacked AI endpoints get reused for offensive operations

The article shows a second-stage pattern that looks more like infrastructure theft than classic intrusion. After initial compromise or exposure, attackers can run autonomous tools, multi-agent workflows, or scanners through the hijacked endpoint, effectively renting someone else’s AI capacity and identity context. That creates a dual abuse pattern: the owner loses compute and the endpoint becomes an operational front for attacks against third parties. This is a governance problem because the legitimate owner may have no visibility into the endpoint’s runtime behaviour once the attacker has repurposed it. The issue is not just who logged in, but what the exposed AI system is being made to do.

Practical implication: Instrument AI endpoints for misuse, not just login success, because repurposed runtime activity is part of the attack surface.

Threat narrative

Attacker objective: The attacker wants either reusable AI credentials or a hijacked AI runtime that can be used for reconnaissance, offensive operations, and anonymous compute.

1. Entry begins with internet-facing AI gateways and agentic endpoints that are exposed to scanning, fingerprinting, and direct exploitation.
2. Credential access follows when attackers use LiteLLM flaws and SSRF paths to reach master keys and provider API credentials through the proxy trust boundary.
3. Escalation occurs when those credentials and trusted endpoints are reused to run offensive tools, scanners, or multi-agent workflows from the hijacked infrastructure.
4. Impact lands as stolen AI-provider access, unauthorised outbound activity, and live attacks against third-party targets conducted through the victim’s environment.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.

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 is becoming an identity perimeter, not just a model hosting layer: The article shows that attackers value the trust relationships around AI gateways more than the models themselves. That shifts governance away from model-only controls toward endpoint authentication, credential containment, and egress oversight. Practitioners should treat every exposed AI proxy as a machine identity with downstream authority.

Ephemeral attacker tempo has already reached AI infrastructure: Five days from disclosure to exploitation is not an outlier anymore, it is the operating tempo. That means vulnerability management for AI gateways must be judged by exposure window, not by patch intent. Teams that wait for production telemetry before acting are already behind the attacker timeline.

Identity blast radius is the right concept for AI gateways: A single compromised gateway can expose multiple provider credentials and route traffic into other systems. This is not a narrow endpoint compromise, it is a blast-radius event across the connected AI estate. Security programmes need to map which identities and outbound paths each gateway can touch before they assume control is in place.

AI compute theft is the new shadow workload pattern: Exposed AI endpoints are being used as free infrastructure for third-party offensive workflows and multi-agent execution. That is a governance problem because utilisation, abuse, and compromise are now interwoven. The practical conclusion is that AI infrastructure inventory and runtime monitoring need to account for misuse, not only authorised workload execution.

OWASP-NHI and Zero Trust both apply here, but the core issue is trust leakage: The article’s strongest lesson is that AI infrastructure inherits the classic non-human identity problem of over-trusted service paths. The difference is scale and speed, because AI endpoints can both consume and emit trust across many providers at once. Practitioners should reevaluate where trust is granted to gateways, not just where it is logged.

From our research library:

• 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.
• Read next: LLM Provider API Key Security and LLMjacking Guide

What this signals

Identity blast radius is now measurable in AI infrastructure: When a single exposed gateway can expose provider keys, route autonomous workflows, and act against third parties, the control problem becomes who can make the endpoint act, not just who can log in. That is why AI infrastructure governance needs to start with trust boundaries and credential scope, not after the first alert.

AI infrastructure leakage outpaces model-centric thinking: According to the State of Secrets Sprawl 2026, AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers. The practical signal is that the weakest layer is often the gateway, proxy, or orchestration tier that sits around the model.

Runtime abuse has become part of the attack surface: Exposed AI endpoints are no longer only a route to stolen secrets. They are also a substrate for offensive compute, autonomous tooling, and anonymous third-party activity, which means detection must look for misuse patterns as well as exploitation attempts.

For practitioners

• Harden AI gateway authentication Require strong authentication on self-hosted AI gateways, inference servers, and administrative endpoints before exposing them to the internet or broader internal networks.
• Constrain outbound AI traffic Restrict outbound network destinations for AI proxies so SSRF or request forwarding cannot reach arbitrary attacker-controlled servers or external credential endpoints.
• Inventory provider credentials behind each gateway Map which provider API keys, master keys, and upstream credentials each AI endpoint can access, then remove unnecessary shared trust paths.
• Monitor for repurposed runtime behaviour Alert on scanner-like activity, multi-agent execution, repeated retries, and non-standard outbound use from AI endpoints, because hijacked systems often continue to look “functional” while they are abused.
• Reduce exposure of administrative AI interfaces Segment self-hosted AI services from public access where possible, and place management interfaces behind separate controls from runtime inference traffic.

Key takeaways

• Exposed AI infrastructure now behaves like a high-trust identity layer, so one compromised gateway can turn into multi-provider access and downstream abuse.
• Zenity’s honeypot network captured nearly 10,000 attack attempts and showed exploitation happening within days, which is fast enough to invalidate passive response assumptions.
• The control that matters most is not only patching, but reducing gateway trust, constraining egress, and watching for runtime misuse of AI endpoints.

Key terms

• AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
• SSRF in AI Infrastructure: Server-side request forgery in AI infrastructure is when an attacker causes a proxy or gateway to make outbound requests on their behalf. The risk is not limited to web traffic manipulation, because the gateway may expose stored credentials, trusted egress, or internal network reach.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• AI Compute Theft: AI compute theft is the unauthorised use of exposed AI infrastructure to run the attacker’s own workloads, scans, or agents. It combines cost abuse with security abuse because the victim’s endpoint can be turned into a launch point for offensive activity.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.