What changed
Censys says it detected more than 294,000 IP addresses associated with AI services in early 2026, up from 183,000 in late 2025.
That is not a rounding error. It suggests internet-exposed AI tooling is moving from “a few risky deployments” to “someone should probably check the whole estate.”
At the same time, internet-exposed industrial control systems are also growing. Censys observed that exposed ICS devices rose from 129,000 in 2024 to 138,000 in early 2026.
Put simply: more AI systems are reachable, and so are more systems tied to real-world operations.
Why this is a bigger deal than a raw exposure count
An exposed service is not automatically a breach. But exposure plus known exploitable weaknesses is where the mood shifts from “messy” to “bad day.”
That’s the core tension in the Censys findings. Some of the most commonly exposed AI tools also appear to be among the most vulnerable.
Langflow: popular, exposed, and risky
Censys detected a sharp rise in exposed instances of Langflow over a nine-month period. The concern is not just growth. It’s growth alongside a stack of vulnerabilities, including multiple high-severity issues and reported exploitation activity.
For defenders, the ugly part is straightforward: unauthenticated remote code execution on an internet-facing service is about as subtle as a brick through a window.
If a tool is exposed and attackers do not need credentials to execute code, the cleanup conversation tends to happen after the incident, not before it.
LiteLLM: one hub, many keys, plenty of risk
LiteLLM brings a different kind of headache. As a unified layer for connecting to multiple commercial LLMs, it can centralize a lot of useful access—and a lot of sensitive tokens.
Censys observed nearly double the number of exposed instances during its measurement window, while attackers have continued exploiting a pre-authentication SQL injection flaw.
That combination matters because a compromise is not just about one app. It can become a pivot point into the model providers and services connected through it. One exposed broker can turn into a key ring.
The critical infrastructure angle is the part nobody should shrug off
The AI tooling story is concerning on its own. It gets more serious when placed next to the exposure picture for industrial control systems.
Censys says North America accounts for the largest share of internet-exposed ICS, at roughly 38% in early 2026. Asia’s share has grown over the past two years, while Europe’s share has slipped somewhat.
These are not just abstract devices in a spreadsheet. ICS can sit close to the machinery behind energy, water, healthcare, and other essential services.
So when public AI services and exposed operational technology both rise at the same time, security teams inherit a problem with a wider blast radius. It is no longer just about protecting an internal pilot or sandbox assistant. In some environments, weak segmentation and exposed services can turn experimentation into operational risk.
One especially weird detail: where ICS exposure lives
Censys notes that roughly 70% of hosts running ICS devices and services globally have consistently appeared on consumer and mobile networks over a long period.
That is the kind of sentence that makes security people stare at the wall for a minute.
Consumer and mobile networks are not where most organizations want sensitive operational systems lingering. Even without dramatic conclusions, this suggests a persistent mismatch between how critical systems should be isolated and how they are sometimes actually reachable.
What this means for enterprises using AI tools now
The lesson is not “stop using AI tools.” It is “stop assuming AI tooling is just another harmless plugin.”
A lot of AI infrastructure now sits in the same category as any other internet-facing enterprise software:
- It may expose admin interfaces or orchestration layers
- It may hold high-value secrets like API keys
- It may have fast-moving vulnerability histories
- It may be deployed by teams optimizing for speed, not hardening
That last point is the real operator error built into the market. AI stacks are often assembled quickly, by multiple teams, with changing ownership and fuzzy visibility. Security debt arrives almost immediately.
Practical questions to ask before choosing or deploying these tools
If you’re evaluating AI infrastructure tools, this news changes the buying checklist.
Ask:
- Does this tool need to be public at all?
- What secrets does it store or route?
- How quickly are vulnerabilities disclosed and patched?
- Is there a history of unauthenticated access issues?
- Can it be isolated behind VPN, SSO, IP allowlists, or private networking?
- Do we know who owns patching and monitoring?
The boring controls are doing a lot of heroic work here.
What smart teams should do next
This is a good week to inventory internet-facing AI services, especially the ones introduced during “just test it quickly” phases.
Priority order is simple:
- Find exposed AI tools.
- Remove public access where it is unnecessary.
- Patch known flaws fast.
- Rotate any exposed or centrally managed API keys.
- Review segmentation between AI tooling and sensitive internal systems.
If a tool brokers access to multiple models or services, treat it like a privileged asset, not a convenience layer.
The market takeaway
The AI tools ecosystem is getting easier to adopt and easier to attack at the same time.
That does not make these platforms unusable. It does make exposure a product signal. When a tool shows up frequently on the public internet and carries serious known weaknesses, buyers should read that as more than a security footnote.
Fast setup is nice. Not becoming an incident report is nicer.
Comments (0) No comments yet
Want to join this discussion? Login or Register.
No comments yet. Be the first to share your thoughts!