DARKARRAY

An earlier version of this page reported that everything reaching these AI ports was taking inventory and none of it was using the model. That held for the first day of collection and no longer does. Over eleven days the emulated endpoints received 311 chat or generation requests from 11 addresses, out of 108 that spoke a model API at all. The network sensor saw the same shift on a smaller scale: two of 39 AI-aware addresses moved on from listing models to requesting chat, generation or a model pull. Listing is still the common case, and most callers never go further, but the population now contains callers that spend inference capacity rather than count it. The operational distinction stands: a listing request is reconnaissance, and a generation request against an unauthenticated endpoint is someone using your hardware. The difference is that both are now observed here.

Evidence

First-party capture of POST requests to chat, generate and chat-completions paths, own monitoring traffic excluded. Network-sensor figure from the vendor field model_use_paths_requested. No model is ever run; every response is a fixed inert string.

Assumptions

That the own-traffic filter is complete. It combines known operator addresses with the monitoring user agents and cannot see an unlisted operator address, though none of the eleven callers matches either.

Independence

Two collectors on one host, one first-party and one vendor-processed. Not independent of each other in vantage point.

265 of the 311 generation requests, about 85 percent, came from a client identifying itself as AutoGenX-Engine. Its advertised version moved from 5.0 to 6.0, 6.2, 7.5, 8.0 and 8.5 across eight days, so it is being revised while in use. Each run asked for the model list and then sent chat requests, hitting both emulated products within milliseconds of each other. Version 5.0 tried both the Ollama-native and the OpenAI-compatible chat path; every later version used only the Ollama-native one, which suggests the developer learned which dialect the targets it cares about actually answer. A separate client from the same address, OpenAI-Exposure-Scanner/6.4-Go, requested the OpenAI model list and one completion, which reads as the discovery half of the same workflow. The same tool name appeared from a second address on the same hosting provider. An independently published AI-honeypot feed had already classified the busier address as a relay customer, with about nine thousand hits in the week before it reached this sensor, and has since reclassified it as an identity prober; both labels fit a client that finds open endpoints and routes work through them. A commercial IP-context service describes the address as datacenter hosting offering anonymous remote-desktop access, the kind of rented Windows machine sold for exactly this sort of use.

Evidence

User-Agent strings and request paths from first-party capture; version sequence from first-seen times per agent string; prior and current classification from the AI Honeypot Observatory feed (CC0); network and hosting context from RDAP and a commercial IP-context service.

Assumptions

That the user agent is honest. It is attacker-controlled and could be copied by an unrelated client, which is why the second address is described as sharing the tool name and not as the same operator. Request bodies were not analysed.

Independence

First-party capture corroborated by one independent publisher's classification made a week earlier from a different vantage point.

An earlier version of this page said each prober spoke only one product's dialect and never tried the other. On five addresses that was true. On a hundred it needs qualifying. Most callers still ask for one product only: 82 used only Ollama-native paths and 17 only OpenAI-compatible ones. But 9 tried both, and they are heavily over-represented among the callers that went on to request generation: 3 of those 9 did, against 8 of the 99 single-dialect callers, and the three include the most active tool in this data. The single-dialect majority looks like scanners written against one product; the dual-dialect minority looks like clients that want any working endpoint and will speak whichever answers. For defenders, a request for the other product's path is still a useful signal on a quiet endpoint, but it no longer separates the cautious prober from the one that will spend your capacity.

Evidence

Per-address classification of first-party requests into Ollama-native (/api/) and OpenAI-compatible (/v1/) paths, excluding MCP paths and own monitoring traffic.

Assumptions

That path prefix identifies the intended product. Some Ollama builds also answer OpenAI-compatible paths, so a dual-dialect caller may be probing one product in two ways.

Independence

Single vantage point.

The emulated server lists three models, one of which is an embedding model: it turns text into vectors and cannot hold a conversation, and its name says as much. 91 of the 311 generation requests named that embedding model anyway, from 6 of the 11 addresses that requested generation. Most came from the tool described above, which sent exactly as many requests to the embedding model as to the coding model, the signature of a loop over the model list that never reads what each entry is. But three other client families on four more addresses did the same, including one that sent a tiny prompt to two of the listed models, one of them the embedding model, within a second of listing them, from a browser user agent with none of the other headers a browser sends. Nobody asks an embedding model to chat by mistake. For defenders this is a cheap and precise signal: a chat or generation request naming an embedding-only model on an exposed endpoint is automated enumeration of what the endpoint will run, not a person using it.

Evidence

Requested model name on first-party chat and generation requests, grouped by user-agent family and by address, own monitoring traffic excluded. Model capabilities from the listing the emulated server returns. Counts cover requests up to 29 September, all of which were answered rather than refused.

Assumptions

That the requested model name is what the caller intended; it is caller-controlled. User-agent families are self-reported and group clients, not operators. None of these callers was ever refused: until 29 September the emulated server answered a chat request to the embedding model with text, where the real product rejects it with an error saying the model does not support chat. From 29 September it rejects them the same way. Whether callers then stop, drop that model from their loop or keep retrying it is therefore observable from that date; no caller had reached the refusal when this entry was written.

Independence

Single vantage point.

Two of the probing addresses geolocate to different countries yet sit on the same hosting provider, ran the same number of sessions, requested the same path, and completed the same number of handshakes. They are best read as one operator on two rented addresses rather than two independent parties. This is why the country breakdown on this page is labelled claimed origin and not attribution: with commodity hosting, the country a probe appears to come from is a purchasing decision. Counting distinct countries as distinct actors would have overstated this small population by a quarter. Later data points the same way from a different direction: the callers that went on to use a model arrived from a rented remote-desktop machine and from a residential proxy exit, and neither location says anything about who was operating them.

Evidence

Identical provider, session count, requested path and handshake count across two addresses geolocated to different countries. Later context for model-use callers from RDAP and a commercial IP-context service.

Assumptions

That identical behaviour on one provider implies one operator. Coincidence is possible at this sample size.

Independence

Single vantage point.

Most traffic the network sensor records is vendor-marked spoofable, meaning no handshake completed and the source address is only the sender's claim: across all of it, about one session in a thousand completed a handshake. The AI-aware probes remain the exception. Across 37 addresses doing model-API reconnaissance, 335 of 520 sessions completed a handshake, about two in three; for the two addresses that went on to request generation or a model pull, 31 of 41. On the first day this was reported as 23 of 31 on five addresses, with a caution that a percentage from so small a population moved with every judgement about who counted as one operator. The larger sample confirms the direction and settles the size: AI-aware traffic is mostly real, while the background it sits in mostly is not.

Evidence

Vendor field handshake_validated_sessions summed across the AI-reconnaissance and model-use categories, against total sessions, own monitoring traffic excluded.

Assumptions

That the vendor's handshake validation is accurate. It is not independently verifiable from this vantage point.

Independence

Single vantage point.

An earlier version of this page reported that the separate address running the emulated model APIs had not been found, with five generic requests in its first hours. That was a statement about the first hours only. The first unsolicited model-API request arrived within about a day of the address going live, and it now draws between forty and fifty distinct addresses a day, 386 in total over eleven days. The port that answers like a generic OpenAI-compatible server draws far more callers than the Ollama port, 319 addresses against 76, mostly because it also sits where generic web scanners look. The caution in the earlier entry still applies in reverse: a quiet honeypot was not evidence that nothing was looking, and it took about a day for that to show.

Evidence

First-party capture, own monitoring traffic excluded. The workspace reports the number of excluded own requests alongside the totals.

Assumptions

That the operator-traffic filter is complete. It is a hand-maintained address list plus the monitoring user agent and cannot catch an unlisted operator address.

Independence

First-party, no corroboration sought.