Security researchers are warning about a new and important risk for organizations running self-hosted AI infrastructure: exposed model endpoints are being abused as backend compute for offensive AI agents.
According to Zenity Labs, researchers observed three separate operators between March and May 2026 attempting to use exposed Ollama and LiteLLM endpoints as model backends for offensive activity. The cases involved autonomous penetration-testing frameworks, including Strix and HexStrike AI, as well as an OpenAI Codex agent configured with a persona designed to reduce safety refusals and assist with web reverse-engineering work.
The most concerning part is that these attacks do not necessarily require a traditional software exploit.
In many cases, the attacker only needs to find an exposed endpoint.
The New Risk: Bring Your Own Agent
The attack pattern is simple but dangerous.
An organization deploys self-hosted AI infrastructure. That infrastructure exposes inference endpoints so applications can call the model. If those endpoints are reachable from the Internet and lack proper authentication, an attacker can configure their own AI agent or client to use the organization’s model backend.
In effect, the attacker brings the agent, while the victim provides the compute.
Zenity described this as attackers hijacking exposed AI backends to power offensive operations. The exposed endpoints included Ollama’s /api/generate and /api/chat endpoints on port 11434, and LiteLLM’s /v1/responses endpoint on port 4000.
That turns misconfigured AI infrastructure into something similar to stolen cloud compute, but with a more dangerous twist: it can become the reasoning engine behind offensive cyber workflows.
How the Abuse Works
The attacker does not need to fully compromise the server.
Instead, they point an AI client or agent framework at the exposed endpoint and send a request containing the agent’s full operating context.
That request can include:
- the system prompt
- the agent persona
- tool definitions
- operating instructions
- target details
- task objectives
Zenity noted that operators often sent a small “hello” probe first to confirm that the endpoint responded, then submitted the full agent payload.
This is important for defenders because the malicious logic is not always stored on the server. It may arrive inside the request body.
That means traditional server compromise indicators may be missing. The infrastructure may simply be doing what it was configured to do: answering model requests.
Three Campaigns Observed
Zenity observed three different examples of exposed AI infrastructure being abused.
The first involved Strix, an autonomous AI penetration-testing agent. A single IP source sent a very large prompt containing Strix instructions and attempted to direct the agent against a live third-party target. Zenity says the attempt was detected and blocked before completion.
The second involved HexStrike AI, an offensive security orchestration framework with more than 150 tools. In that case, the attacker pointed a desktop LLM client at an Ollama instance and loaded a broad offensive toolset. No live target was assigned, which suggests the operator may have been staging or testing the setup.
The third involved an OpenAI Codex agent routed through a LiteLLM proxy. The agent was configured with a security-auditor-style persona and instructions associated with web reverse-engineering work. Zenity said the captured request structure matched Codex-style activity, although request headers can always be spoofed.
Together, these cases show a clear shift: attackers are learning how to use exposed AI infrastructure as part of their operational workflow.
Why Ollama and LiteLLM Are Attractive Targets
Part of the issue comes from how these tools are often deployed.
Ollama is commonly used for self-hosted local models. By default, it is intended for local use, but it can be misconfigured to bind to all interfaces and become reachable from outside the host.
LiteLLM is widely used as a proxy or gateway for routing model requests across different providers and internal systems. According to Zenity, LiteLLM authentication depends on whether the operator sets a master key, and placeholder keys such as sk-1234 have been seen in real-world targeting.
The problem is not that these tools are inherently malicious.
The problem is exposure plus weak or missing authentication.
A model backend that was meant to serve internal applications can become a public resource for anyone who finds it.
Why This Matters for Security Teams
This is not just free compute theft.
Attackers are not only using exposed AI endpoints to run harmless prompts or save money on inference costs. They are attempting to connect those endpoints to agentic workflows that can support reconnaissance, penetration testing, reverse engineering, and other offensive operations.
That changes the risk model.
A public AI backend can become:
- a free model backend for attackers
- a hidden compute layer for offensive agents
- a way to route activity through legitimate infrastructure
- a source of cost abuse
- a potential compliance and legal risk
- a visibility challenge for security teams
If the attacker’s agent uses the organization’s AI infrastructure to support activity against a third party, the victim organization may be pulled into an incident it did not initiate.
The Detection Opportunity
There is also a defensive advantage.
Zenity points out that these agent requests often carry the full operating context in the request body. That can include the persona, tool list, instructions, and sometimes even the target.
For defenders, that means request-body inspection can be valuable.
Security teams should look for signs that inbound model requests are not normal user prompts. Suspicious indicators may include unusually large request bodies, full tool arrays, offensive security vocabulary, unsafe personas, unknown model names, or clients attempting to use models the organization does not actually host.
The key is to treat AI inference traffic as security-relevant traffic.
Model requests are no longer just application calls. They may contain the full logic of an attacker-controlled agent.
Recommended Defensive Actions
Organizations running self-hosted AI infrastructure should review exposure immediately.
The most important step is simple: do not expose model backends directly to the Internet unless there is a clear business need and proper security controls are in place.
Security teams should:
- bind Ollama and similar tools to localhost or private interfaces
- place AI backends behind authenticated reverse proxies
- require real authentication for LiteLLM and reject placeholder keys
- monitor access to Ollama and LiteLLM endpoints
- inspect inbound request bodies from external sources
- block suspicious agent payloads and offensive tool definitions
- alert on oversized prompts or full tool arrays
- restrict access to known internal applications and users
- log model usage, source IPs, and abnormal request patterns
- monitor for unexpected cost spikes or unusual model activity
Zenity also recommends watching for commonly abused endpoints and blocking request patterns associated with offensive agents, unsafe personas, and tools that should not appear in normal business AI use.
A New Attack Surface for CISOs
For CISOs, the lesson is clear: AI infrastructure is now part of the enterprise attack surface.
The risk is not limited to prompts, data leakage, or shadow AI usage. Exposed model endpoints can be actively hijacked by outsiders and turned into infrastructure for offensive operations.
This creates a new class of questions for security leaders:
Who can reach our model endpoints?
Which AI gateways are Internet-facing?
Are default keys or placeholder tokens still accepted?
Do we inspect model request bodies?
Can we detect agentic payloads?
Do we know which tools our AI agents are allowed to invoke?
These questions should become part of cloud security, application security, and AI governance programs.
Final Thoughts
The Zenity findings show that attackers are becoming more AI-literate.
They understand how agent frameworks work. They know how to point clients at exposed model backends. They are experimenting with autonomous pentesting frameworks, offensive toolsets, and AI-assisted reverse-engineering workflows.
This is a warning for every organization deploying AI infrastructure.
An exposed LLM endpoint is not just another open port. It can become the brain behind someone else’s attack.
The key lesson is simple: treat AI backends like production infrastructure. Lock them down, authenticate access, inspect traffic, monitor usage, and assume that any public AI system will be discovered quickly by attackers.
