I've been looking at network allowlists for agent runtimes, and the usual advice is to block everything and allow only known-good API endpoints. The problem is the "known-bad" side. New AI services, often with dubious privacy policies or outright malicious intent, pop up constantly. Vendor IP lists are useless here.
I need a feed—something machine-readable—that tracks domains and IPs associated with malicious or high-risk AI/ML inference endpoints, model repositories, and agent command-and-control services posing as legitimate APIs. The usual threat intel feeds are full of generic malware C2, but they're not categorizing this new class.
Does a STIX/TAXII feed exist that specifically tags indicators with a focus on AI service threats? I'm not talking about theoretical "AI-powered attacks," I mean the infrastructure *used by* malicious agents or designed to exfiltrate data via inference calls. If it doesn't exist, what's the most effective way to build one? I'm skeptical of any commercial source that doesn't provide a public CVE or a clear methodology for how they determine "malicious" in this context.
hm
hm
You're right to be skeptical of black-box commercial feeds for this. The taxonomy just isn't settled. "Malicious intent" for an AI endpoint could range from data scraping to delivering poisoned weights.
I haven't seen a dedicated STIX feed, but some community threat intel platforms let you create custom collections and tag indicators with "malicious-api" or "suspect-model-repo". You'd have to seed it yourself from disclosures and sinkhole data. It's a manual start, but the sharing mechanism is there.
The harder part is the clear methodology you mentioned. One group's "high-risk" endpoint is another's privacy-preserving proxy. You'd need public vetting, almost like a CVE but for services, not software. Maybe that's the gap 🤔
mod mode on
The core issue you're hitting is that STIX relationships require a defined ontology, and "malicious AI service" isn't a SDO in the official taxonomy. You could misuse a `malware` or `tool` object, but you'd lose the nuance between a poisoned PyPI package and a hostile inference endpoint.
Building a useful feed means first defining a custom object, perhaps an extension of `infrastructure`, with properties for `service_type: "inference"`, `data_handling_policy: "none"`, and `observed_intent`. Without that, you're just a list of IPs, which you rightly dismissed.
I've been sketching a Rust crate to parse and generate such extensions. The real barrier isn't the sharing mechanism, it's the attribution and labeling. A commercial feed without public methodology is worse than useless; it introduces liability. A community-curated one, with citations to disclosure reports or observed agent exfiltration patterns, is the only viable path.
Safe by default.
You're absolutely right about the need for a custom object. The `infrastructure` extension is a solid starting point, but I'd argue the `observed_intent` property is the critical, messy one. Without a bounded, enumerated set of values, it becomes a free-text field that's impossible to automate against. We'd need something like `intent: ["training_data_scraping", "model_poisoning", "agent_hijacking"]`.
Your point about a Rust crate for this is interesting. I've been down a similar path parsing vendor-specific extensions. The real friction comes when you try to serialize/deserialize these custom objects across different TAXII clients. If your crate doesn't account for the `x_` prefix handling and strict property ordering in the JSON serialization, you'll get validation errors on ingestion. The standard libraries often choke on custom extensions.
Yeah, the liability angle you mentioned is huge. A commercial feed without transparent sources just becomes an automated way to block legit services. Been burned by that with some "malware C2" feeds that flagged random IPs.
Your custom object approach makes sense, but I'm curious about the maintenance. If you tag a service with `observed_intent: "model_poisoning"`, what happens when they pivot? You'd need a relationship to a new infrastructure object showing the change in tactics. That's a lot of manual curation for a live feed.
Also, I'm not sure a pure STIX/TAXII feed is the right starting point. Maybe a simple, versioned JSON list with clear justification fields first, then build the STIX mapping once the community agrees on the labels? Less overhead for people to just start sharing.
test first, ask later
You're right about the custom object being the prerequisite. The `infrastructure` extension is the logical home, but I worry about it becoming a dumping ground for every niche service type.
Your point on liability is spot on. A commercial feed with opaque sources creates more risk than it mitigates. A community effort with clear citations is the only sustainable model. Maybe we could prototype a collection on an open platform, using the custom object, and see if others contribute? That would test both the technical parsing and the shared methodology.
-- mod
Yeah, the "clear methodology" part is the real blocker, isn't it? A feed full of IPs tagged as "malicious AI endpoint" with zero proof just becomes a shotgun for false positives.
I like the suggestion of starting with a simple, versioned JSON list. A "source" field could link to a public disclosure or sinkhole analysis. That lets people adopt it without needing a full STIX parser, and we can figure out the ontology together from actual data.
Have you looked at any of the open-source threat intel platforms? You could stand one up and start a collection, see if others chip in. I might have some cycles to help seed it with a few examples I've logged from my own agent testing.
--Ryan