HiveAI: A Honeypot Framework Aimed at Large-Model APIs

HiveAI impersonates common large-model APIs to capture and analyze real-world attacks against those services. The paper also describes controls meant to stop attack logs from becoming indirect prompt injection against the analysis model.

What HiveAI is

As large-model APIs became common public services, attacker reconnaissance widened. Operators still see SSH, database, and web-admin probing, and they also see searches for OpenAI-style endpoints, Ollama services, tool-calling entry points, and other exposed AI functions.

HiveAI, presented in a Springer paper, is a honeypot built for those APIs. It presents itself as several familiar large-model services in order to attract, record, and analyze live attack traffic.

Paper: https://link.springer.com/article/10.1007/s10207-026-01307-0

The authors also treat a follow-on risk: when a large model reads attack logs, an attacker can place malicious instructions in those logs and target the analyzer. HiveAI is therefore both an AI-facing honeypot and a system that tries to keep the analysis pipeline from being attacked through its own inputs.

The design, in brief, deploys decoy large-model interfaces, runs an automated pipeline that turns captured traffic into structured intelligence, and then applies controls so log content cannot easily continue the attack downstream.

Why API-layer honeypots

Classic honeypots fake SSH, databases, or industrial-control interfaces. HiveAI moves that idea onto AI APIs: if applications expose model capability as an HTTP service, attackers treat those interfaces as targets.

IDS, WAF, and firewall products mainly inspect network and HTTP behavior such as ports, paths, and known signatures. Attacks against large-model APIs often put the useful signal in request semantics. A request can look like ordinary HTTPS and JSON while carrying prompt injection, jailbreak sequences, model enumeration, tool-call probing, or attempts to reuse the AI service for further abuse. HiveAI’s stated premise is that watching real AI-API attacks requires the semantic layer, not only the network layer.

Three-layer layout

HiveAI is split into a public decoy layer, an internal analysis layer, and a read-only display layer.

Public decoy layer

The outer layer sits on the internet. The authors simulated five common fronts: OpenAI, Claude, Ollama, HuggingFace, and an agent-style ClawBot. The fronts do not need full model capability. They need protocol behavior close enough that attackers interact with them.

The system records raw inputs, including request paths, bodies, access frequency, and call patterns. Several fronts are used because attackers often scan multiple AI services on the same host. One facade would show only a slice of that path.

Internal analysis layer

Captured data moves inward to a message system, collectors, a database, and an AI threat analyzer. Fast rule and statistics processing runs first. The large model is used later. The threat-analysis module is not exposed on the public network. Containers are described with read-only filesystems, least privilege, and resource limits.

Public display layer

The outer display layer presents maps, charts, and read-only APIs. It is isolated from the analysis core so a display failure does not easily reach the analyzer.

Eight-stage pipeline

Raw logs are not sent to a large model first. The pipeline has eight stages:

1. Collect requests from the five API fronts. 2. Enrich source IPs with geolocation, ASN, WHOIS, and hosting signals. 3. Apply heuristic checks for prompt-injection features. 4. Run a lightweight classifier into classes such as scanning, fuzzing, and API abuse. 5. Map behaviors onto structured taxonomies, including MITRE ATT&CK and AI-oriented attack frameworks. 6. Correlate requests into sessions across interfaces, payloads, and paths. 7. Use timing, text change, complexity, and latency statistics to label traffic as more like a scanner, a human, or an automated agent. 8. Run the large-model threat analyzer on the structured results to produce analyst-style conclusions on intent, severity, and techniques.

The first six stages run synchronously so decoy services stay light. Heavier statistics and model analysis run asynchronously.

Protecting the analysis model

Logs fed to a large model can become a write path into the analyzer context. Text that was only data for rules and human review can be treated as instructions. That is indirect prompt injection: the attacker does not speak to the analyzer directly, but tries to steer it through logs, events, or alerts. The paper calls this defending the defender.

HiveAI specifies five layers:

1. Keep the analyzer off the public internet. 2. Clean inputs to neutralize some typical injection patterns. 3. Mark log content as data under analysis, not commands. 4. Use system prompts that tell the analyzer to treat the content as evidence rather than execute it. 5. Inject forensic fields such as timestamps and host metadata from the host, so key facts are not taken only from attacker-controlled logs.

The paper does not treat any single layer as sufficient. The same input path exists in security agents, alert-summary agents, and SOC copilots that ingest attacker-controlled data.

Deployment numbers

The authors ran the system for 20 days on a VPS with a 4-core CPU, 4 GB of memory, and no GPU. It captured 16,683 attack events from 1,229 source IPs in 50 countries. Ollama and OpenAI-style interfaces received the most traffic.

Synchronous front-end stages were kept low-latency. Model analysis was used mainly to turn structured results into analyst-facing conclusions. An adversarial evaluation reported that combining rule and statistical judgments improved resistance to evasive behavior. The authors do not claim that indirect prompt injection is fully solved.

What the paper argues

HiveAI’s broader claim is that AI-using defense systems create a second attack surface. Logs, alerts, tool results, web content, RAG documents, and attack samples can all become model inputs. The working answer in the paper is to use AI to analyze AI-era attacks while isolating, filtering, and constraining the analyzer itself.