InferD: A Honeypot Framework for AI Inference Infrastructure

1 Introduction

• AI inference infrastructure is exposed at scale, and scanners use service fingerprints such as model inventories and authorization formats to identify targets.Operators expose model servers, notebooks, vector databases, experiment trackers, and agent gateways; scanners index endpoints within hours.Source: §1 · p. 1
• An inference honeypot must reproduce model inventories, completion and streaming behavior, credentials, and tool-call lifecycles without running attacker-submitted computation.A live model would add serving cost and latency variance, make replies nondeterministic, and expose a model to prompting and manipulation.Source: §1 · p. 1
• InferD answers observable requests from static response pools and logs implied computation as intent, supporting non-execution and a kernel-enforced egress boundary across heterogeneous services.The initial deployment captured a purpose-built credential harvester delivered through an MCP stdio code-execution primitive, observed from three sources with zero code executed.Source: §1 · pp. 1–2

2.1 Structural Origins of Exposure

• Documented trusted-network assumptions and operator-dependent isolation can leave AI services network-exposed, a posture reflected in measurement of 320,102 publicly reachable LLM services across 15 frameworks.Ollama's documented multi-user configuration binds to all interfaces, while Ray's dashboard is documented as unauthenticated by design.Source: §2.1 · p. 2

2.2 Emulation Constraints Specific to AI Services

• AI-service emulation must reproduce model behavior, capture stateful tool-call sessions, and observe credential use, each of which pulls toward higher interaction and sharpens the fidelity-safety tension.Source: §2.2 · p. 2

2.3 Threat Model and Design Goals

• InferD models five adversary classes, from indiscriminate scanners to agentic actors, and sets goals for fidelity, non-execution, source attribution, stateful capture, provenance, and fingerprint resistance.The design constraints prohibit executing submitted code, evaluating tool calls, running a model, emitting outbound traffic, or disclosing observed sources' real addresses.Source: §2.3 · pp. 2–3

3 Design

• The deception-without-inference principle answers each observable request statically and logs, but withholds, its implied computation.Source: §3 · p. 3
• A two-surface architecture separates open-port services from credential-gated cloud facades and unifies them under one egress boundary.Source: §3 · p. 3
• Deception planes reproduce observable AI-service layers, with each plane considered against its rejected alternative and accepted detection vector.Source: §3 · p. 3

3.1 The Deception-Without-Inference Principle

• Static response pools provide protocol behavior while implied computation is recorded and withheld, rather than performed on attacker input.Source: §3.1 · p. 3
• Compared with generation, static pools are cheap, constant-latency, deterministic, auditable, and expose no live model, but cannot answer prompts requiring genuine reasoning.Variant expansion mitigates repetition; an adversary who tests for reasoning can detect the lack of inference.Source: §3.1 · p. 3
• Because the facade never computes on attacker input, a kernel-enforced egress guarantee can hold even if an emulator has a bug.Source: §3.1 · p. 3
• A shared middleware and storage path can serve heterogeneous services because each answers from a pool and records implied computation.Source: §3.1 · p. 3

3.2 Architecture and the Two-Surface Model

• All traffic passes through common middleware to a per-service emulator within a kernel-level egress boundary.InferD runs as a single host-networked container; a reverse proxy terminates TLS for cloud API facades, while self-hosted services bind directly on conventional ports.Source: §3.2 · p. 3
• Surface 1 covers self-hosted services discovered through open ports, targeting reconnaissance, inventory enumeration, and vulnerability probing.Its deception target is the default network-exposed deployment.Source: §3.2 · p. 3
• Surface 2 covers credential-gated cloud API facades, targeting credential abuse and submitted prompts and tool definitions.The provenance plane attaches to this surface, where credentials are the entry mechanism.Source: §3.2 · p. 3

3.3 Deception by Layer

• The layered design treats each observable behavior as an emulation problem and weighs its fidelity against alternatives and ways adversaries could detect the deception.Non-execution is detectable by adversaries who test for effect.Source: §3.3 · p. 3

3.3.1 Transport Layer.

• Host-network mode preserves direct-port peer addresses; proxied traffic trusts X-Forwarded-For only from the loopback proxy, while transport fingerprints are logged for mismatch analysis.Standard container port mapping silently replaces source addresses with the gateway IP; a determined adversary may still detect transport-fingerprint discrepancies.Source: §3.3.1 · p. 3, Figure 1 · p. 4

3.3.2 Service Protocol Layer.

• Static response pools with variant expansion reproduce advertised service behavior without computation, but checkable prompts can expose the facade's inability to reason.The finite pool depth is a stated detectability limit.Source: §3.3.2 · p. 4

3.3.3 Vulnerability Surface Layer.

• The vulnerability surface combines CVE-grounded interfaces with structurally motivated attack surfaces, and a structural anomaly scan preserves suspicious requests beyond known signatures.In deployment, the scan identified and preserved a novel credential-harvesting payload delivered through the LiteLLM MCP test-connection feature.Source: §3.3.3 · pp. 4–5

3.3.4 Agentic Session Layer.

• Stateful Assistants and MCP sessions record tool-call arguments without dispatching them, capturing sequences rather than isolated requests.Empirical validation against organic agentic traffic is limited in the current deployment window; the session framing instruments untrusted instructions and exfiltration paths while withholding sensitive data.Source: §3.3.4 · p. 5

3.3.5 Provenance Plane.

• Honeytokens record whether planted credentials are presented, and canary re-presentation provides evidence that captured output passed through a model-mediated pipeline.The plane produces signal only when credentials are found and used; a passive decoy must wait for its keys to enter circulation.Source: §3.3.5 · p. 5

4.1 Process Architecture

• Ten process groups serve the facades, all running as the same unprivileged user bound to the egress rule, so adding a service inherits the same outbound prohibition.Each group is a separate application server managed by supervisord inside one container.Source: §4.1 · p. 5

4.2 Source Attribution Under Container Networking

• Host-network mode preserves raw peer addresses, while proxied TLS traffic trusts X-Forwarded-For only from the loopback proxy to prevent external origin spoofing.Standard port mapping silently rewrites source addresses to the container gateway, undermining attribution.Source: §4.2 · pp. 5–6

4.3 Egress Isolation

• The firewall allows loopback and established outbound traffic but drops every other new connection from the emulator user for IPv4 and IPv6.Because the kernel enforces the boundary, attempted relaying remains blocked even if an emulator has a bug.Source: §4.3 · p. 6

4.4 Response Pools

• Response pools draw pre-authored endpoint objects and vary selected fields; completion pools contain 40–60 variants, inventory pools 15–20, and embeddings use unit-norm vectors at standard dimensionalities.Sufficient samples can reveal repetition and a statistical fingerprint.Source: §4.4 · p. 6

4.5 Non-Execution Guarantees and Ethical Constraints

• InferD never executes submitted code, evaluates code, loads a model, or dispatches tools, and it holds no real model, key, or datastore; kernel egress rules provide a backstop against relaying or exfiltration.The paper grounds its ethical position in accepting only inbound connections, scripted responses, and kernel-blocked outbound traffic.Source: §4.5 · pp. 6–7

5 Deployment and Findings

• The deployment validated the instrument end to end: organic traffic arrived within hours without active advertisement, and the pipeline attributed and recorded it.Observed traffic concentrated on the self-hosted surface and commonly exposed services; many sources sent one request and did not return, while a substantial share were recognized internet-wide scanners.Source: §5 · p. 7, Table 3 · p. 7, Figure 2 · p. 7

5.1 Model Enumeration

• Ollama model requests were dominated by Llama 3.x, Mistral, DeepSeek-R1, and Qwen variants, with the consumer-GPU concentration partly reflecting the facade’s identity.The authors describe this as an illustrative early finding, not a quantified claim about adversaries generally.Source: §5.1 · p. 7, Figure 3 · p. 7

5.2 Captured Credential-Harvesting Payload

• 601 requests from three sources carried a credential-harvesting payload across 14 LiteLLM endpoint-path variants, and InferD’s structural anomaly scan flagged all instances at capture time.The payload was delivered through MCP stdio; InferD returned static responses without spawning the process or running any payload stage.Source: §5.2 · pp. 7–8, Figure 4 · p. 9
• The payload used an ordered cloud-credential extraction pipeline and returned harvested data in-band through a fabricated MCP tools/list response.The pipeline covered environment and configuration secrets, mounted secrets, cloud identities and secret managers; the in-band channel would not be visible to monitoring limited to anomalous outbound connections.Source: §5.2 · p. 8
• Two payload builds had 0.929 sequence similarity; the later build added Azure metadata and Kubernetes API enumeration, but shared tooling did not establish a single operator.The builds appeared three days apart and shared a non-generic User-Agent across sources in two network types.Source: §5.2 · p. 8, Table 4 · p. 8

5.3 Conditional Planes and Their Activation Requirements

• The provenance and agentic planes produced no signals during the window; their activation depends on planted credentials being stolen or agentic traffic reaching the decoy.The authors identify active honeytoken seeding and longer, multi-vantage collection as steps needed for a measurement study; the short, single-vantage deployment cannot support population-level claims.Source: §5 · p. 7, §5.3 · p. 9

6.1 Detectability Limits

• An adversary can detect absent inference by checking verifiable answers, repeated responses by estimating pool size, fast completion timing, transport fingerprints, or whether an expected effect occurs.Variant expansion mitigates repetition; plausible inter-token latency is a proposed refinement.Source: §6.1 · p. 9

6.2 Scope, Extensibility, and Measurement

• The next measurement agenda includes seeding honeytokens, extending collection across time and geographic vantage points, and modeling response latency.Multi-vantage deployment could separate globally uniform scanning from locality-specific campaigns; new surfaces can be added with a router and response pool.Source: §6.2 · pp. 9–10
• InferD observes inbound threat traffic only; it does not address model or package supply-chain compromise or activity confined to a victim’s internal network.Source: §6.2 · p. 10

6.3 Related Work

• InferD targets AI inference infrastructure, unlike classical honeypots designed for conventional services, and distinguishes itself through non-execution by design paired with kernel-enforced egress containment.Its agentic-surface coverage is stated against an external taxonomy.Source: §6.3 · p. 10

• InferD’s initial deployment surfaced a novel credential-harvesting payload delivered through an MCP stdio code-execution primitive.Source: §7 · p. 10
• The framework combines four deception planes with a provenance plane, developed with rejected alternatives and detectability limits in view.Source: §7 · p. 10
• Non-execution by design is backed by a kernel-enforced egress guarantee that holds regardless of emulator correctness.Source: §7 · p. 10

• AI tools assisted with language editing and code review and debugging; the authors produced the research design, system implementation, and analysis artifacts.Source: Generative AI Disclosure · p. 11

• The primary recovery method queried requests flagged at capture for lexical indicators such as code, shell metacharacters, command fields, pickle, or base64 payloads.Source: A Payload Detection Methodology · p. 11
• A second, flag-agnostic scan attempted base64 decoding of substrings of at least 32 bytes, then gzip, bz2, lzma, and zlib decompression, with a second pass for nested base64.Source: A Payload Detection Methodology · p. 11
• Both methods recovered the documented credential-harvesting payloads and found no additional undetected code payloads among 24,192 requests across 14 emulated services at analysis time.Source: A Payload Detection Methodology · p. 11
• The scan also found three base64-decodable PNG blobs submitted as multimodal chat content, which were confirmed benign by PNG structure verification.Source: A Payload Detection Methodology · p. 11
• The scan could miss payloads using encodings beyond base64 and the four tested compression formats; Jupyter kernel endpoint code was flagged but not persisted for analysis.Persisting the Jupyter content was planned for the next deployment iteration.Source: A Payload Detection Methodology · p. 11