A field guide from the team building Reput.io. The goal here is a taxonomy any analyst can use, whatever tooling you run. AI infrastructure is not one thing to allow or block, it's four different things, and the research from the last two years is what makes the distinction load-bearing rather than academic.

The problem with "AI traffic"

When a connection to something AI-shaped shows up in the logs, the instinct is to file it under one mental bucket: "oh, that's the AI stuff, probably fine." Two years ago that instinct was mostly harmless, because AI traffic really was a handful of first-party API endpoints. It isn't anymore.

"AI traffic" now spans first-party vendor APIs, marketplaces that run strangers' models, GPU boxes rented by the hour, and automated crawlers. Those share a word and almost nothing else. Collapsing them into one allow rule is how a SOC ends up either drowning legitimate LLM usage in noise or, worse, waving through customer-controlled infrastructure that happens to sit under a trusted-sounding brand.

This post lays out the four classes, the reputation posture each one earns, and the single principle that decides where the line falls.

Why this needs saying now

The distinction is not theoretical. Three independent lines of research over the last two years turned "AI infrastructure" from a monolith into something you have to classify:

Public model hubs carry real malware. In February 2024, JFrog documented roughly 100 genuinely malicious models on Hugging Face, including one that abused Python's pickle deserialization to open a reverse shell to a hardcoded IP the moment the model loaded. A year later, ReversingLabs found "nullifAI" models using deliberately broken pickle files to slip past automated scanning. A model repo being real and popular tells you nothing about the specific model behind a given pull.

AI compute gets scanned and abused like any other exposed service. Oligo Security's "ShadowRay" research showed thousands of internet-exposed Ray clusters being exploited in the wild for credential theft and cryptomining, leaking cloud keys and API tokens along the way. (The underlying CVE-2023-48022 is formally disputed, since the vendor treats the missing auth as a documented default, which honestly makes the exposure worse, not better.) AI serving infrastructure is attack surface.

The vendors themselves drew a line for you. OpenAI and Anthropic now publish official JSON feeds of their crawler IP ranges, GPTBot at openai.com/gptbot.json and ClaudeBot at claude.com/crawling/bots.json, mirroring the long-standing practice of Google and Bing. That means "is this really an AI crawler" has an authoritative answer that no longer depends on a trivially-spoofed user-agent string.

Put together, these say the same thing from three directions: the trust you can extend to an AI endpoint depends entirely on which kind of AI endpoint it is.

The taxonomy: four classes

1. First-party vendor APIs

api.openai.com, api.anthropic.com, claude.ai. The AI company operates these itself and does not resell general hosting on them. Traffic is near-certainly legitimate LLM usage: enterprise teams integrating APIs, coding assistants, chat.

Posture: low noise, allow with logging. The real question here is a policy one, not a security one. Is this vendor approved for your organization's data, token spend, and compliance posture? Blocking disrupts production AI workloads, so the cost of a false positive is high and the residual risk is low.

2. Model hosting and inference marketplaces

Hugging Face, Replicate, Together, Groq. These run customer-uploaded models, datasets, Spaces, and code. That is customer-controlled workload hosting, the same risk shape as a cloud provider, which is exactly why the pickle-RCE research above matters.

Posture: investigate. The platform being legitimate says nothing about the specific artifact behind the request. The thing to identify is not "is Hugging Face safe" but "what model, Space, or repo is being pulled, and by whom." Treat it like rentable infrastructure, not a vetted API.

3. GPU clouds

CoreWeave, Lambda, and GPU instances on the hyperscalers. You rent a box with a GPU by the hour and run whatever you want on it.

Posture: investigate, same as any AWS or Azure IP. There is no meaningful difference between "someone rented a GPU box" and "someone rented a VM" from a reputation standpoint. The hosting brand is context, not a verdict.

4. AI crawlers

GPTBot, ClaudeBot, PerplexityBot. Automated fetchers that mostly live inside hyperscaler ranges and generate anomaly-tripping scan patterns.

Posture: verify against the vendor's published IP feed, not the user-agent. This is the one class where the vendors handed you ground truth. An IP that claims to be GPTBot but isn't in gptbot.json is worth a second look. And note that even a confirmed crawler IP living in a cloud ASN deserves care, because an attacker's box in the same range looks identical at the network layer.

The principle underneath: asymmetric trust

Notice that three of the four classes land on "investigate" even though all four are unambiguously real, well-known AI services. That is not caution for its own sake. It follows from one rule that we apply across every provider, AI or not:

A strong signal may correct a misleading label, but it must never upgrade customer-controlled infrastructure to "safe". Knowing who runs the box is not the same as knowing the workload is benign.

"First-party vendor API" earns benign because the vendor is the only party who can run anything there. "Model hosting", "GPU cloud", and "crawler in a cloud ASN" cannot earn it, because the party in control of the actual workload is a customer, or an attacker renting like a customer. The brand on the infrastructure is real; it just isn't evidence about the specific request in front of you.

This is the same asymmetry that keeps a Microsoft Teams IP labeled "Azure" but still at investigate, and it's why popularity, ASN ownership, and a "verified company" tag can all be true at once without adding up to "allow".

How we apply it in Reput.io

We built the same four-way split into our provider detection, so a lookup reflects the class rather than the brand. First-party APIs resolve to a benign profile; model-hosting and inference markers push the same category into a separate profile that stays investigate; GPU clouds map by ASN into the customer-controlled bucket alongside AWS and OVH.

Concretely, api.openai.com comes back trusted (live from production as of this post, trimmed):

{
  "indicator": "api.openai.com",
  "verdict": "likely_benign",
  "provider": { "name": "AI/ML Service", "type": "ai_service" },
  "risk_description": "First-party AI/ML API endpoint operated by the AI company itself (OpenAI, Anthropic, Google AI, etc.). These vendors don't resell general hosting on these domains, so traffic is near-certainly legitimate LLM/API usage.",
  "recommendation": {
    "action": "allow_with_logging",
    "false_positive_likelihood": "high",
    "investigation_hint": "Verify the AI service is approved for organizational use (data policy, token spending, compliance)."
  }
}

While huggingface.co, same "AI/ML Service" category, same popularity, does not:

{
  "indicator": "huggingface.co",
  "verdict": "investigate",
  "provider": { "name": "AI Model Hosting / Inference", "type": "ai_hosting" },
  "categories": ["AI/ML Service", "Model Hosting", "SaaS Platform", "Popular Domain", ...],
  "risk_description": "AI model-hosting or inference marketplace (Hugging Face, Replicate, Together, Groq, etc.). These platforms run customer-uploaded models, datasets, Spaces, and code, customer-controlled workloads, exactly like a cloud provider. The platform being real says nothing about the specific model or app: public model repos have carried malware (pickle deserialization payloads), and exposed inference services are actively scanned for abuse.",
  "recommendation": {
    "action": "investigate",
    "false_positive_likelihood": "medium",
    "investigation_hint": "Identify the specific model/Space/repo behind the request, not just the platform. Check what's being pulled and by whom before trusting it."
  }
}

The line between them is drawn by the class of infrastructure, not by the brand. And in both cases the raw evidence stays in the response: the popularity rankings, the "verified technology company" reason, all of it. We tell the analyst it's a real, popular platform and that the platform being real says nothing about the specific model behind this request. They draw the final line, with everything visible.

For crawler IPs we follow the vendors' own feeds rather than maintaining our own guesses, which is a habit worth its own note: whenever a vendor or research team publishes authoritative ground truth, ingesting their maintained list beats hand-curating one that goes stale the day you write it.

A field guide you can use anywhere

You don't need our API to apply the taxonomy. When something AI-shaped shows up, ask which of the four it is:

First-party vendor API (api.openai.com, api.anthropic.com): allow with logging; the open question is policy approval, not maliciousness.
Model hosting / inference (Hugging Face, Replicate, Together, Groq): treat like a cloud provider; identify the specific model or repo, not just the platform.
GPU cloud (CoreWeave, Lambda, GPU instances on the big three): rentable infrastructure; same posture as any hyperscaler IP.
AI crawler (GPTBot, ClaudeBot, PerplexityBot): verify against the vendor's published IP feed, never the user-agent alone.

Try it yourself

Every lookup in this post is reproducible against the live API right now:

curl -X POST https://api.reput.io/lookup \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"indicators": ["api.openai.com", "huggingface.co", "replicate.com", "api.groq.com"]}'

The free tier gives you 500 queries/day, enough to run your own AI-related alerts through it and see the four-way split. Grab a key here.

If you think the risk posture is wrong on any class, especially the model-hosting call, we want to hear the argument. hello@reput.io.

Written by the Reput.io team. Background in backend engineering and SOC tooling.

AI Traffic Is Not a Category: A Reputation Taxonomy for AI Infrastructure