AI Service Security: 1 Million Exposed APIs Scanned

AI service security is in rough shape. After scanning over one million publicly exposed AI inference endpoints, model APIs, and supporting services, the data paints a clear picture: developers are shipping AI faster than they are securing it.

The results are not theoretical risk. These are real endpoints, reachable from the public internet, many with zero authentication and several with direct access to underlying model infrastructure.

What the Scan Actually Found

The methodology was straightforward. Using automated DAST techniques across public IP ranges and common AI platform ports, we identified services running open-source inference stacks (Ollama, LocalAI, vLLM, and others), cloud-hosted model APIs, and LLM-backed application endpoints.

The numbers are worth stopping on. Roughly 35% of discovered Ollama instances had no authentication whatsoever. Anyone with the IP address could pull models, run inference, and in some cases enumerate the host's entire model library. Open vLLM deployments showed similar patterns, with REST APIs exposed directly without so much as an API key requirement.

Beyond unauthenticated access, a significant portion of scanned services leaked version information in HTTP headers or error responses. That gives attackers an easy fingerprint to match against known CVEs without doing any real work.

Why Developers Keep Shipping Exposed AI Services

The root cause is not laziness. It is speed and tooling defaults. Most open-source AI serving frameworks prioritize getting inference working, and default configurations bind to all interfaces (0.0.0.0) without requiring authentication.

When a developer spins up Ollama on a cloud VM to test a model, the default setup does exactly what it is designed to do: serve requests. The problem is that cloud VMs are not localhost. A missing firewall rule or a misconfigured security group turns a private test into a public endpoint within seconds of deployment.

LLM-backed web applications have a compounding issue. Many proxy requests to backend model services through application layers that strip authentication headers or fail to propagate them correctly. The application looks secured from the outside, but the model service sitting behind it is completely open on an internal network that turns out to not be as internal as assumed.

What Is Actually at Risk

The blast radius here goes beyond wasted compute bills. Exposed model endpoints can be abused for:

• Unauthorized inference at scale: attackers run prompts on your infrastructure, running up costs and consuming rate limits.
• Model extraction: repeated querying can approximate model weights or fine-tuning data.
• Prompt injection pivots: open endpoints tied to retrieval systems or tool-use agents can be leveraged to exfiltrate data from connected services.
• Reconnaissance: version leakage and open endpoints map your stack for follow-on attacks.

For any service handling user data or operating in a regulated environment, an exposed AI endpoint is a compliance problem, not just a technical one.

How to Lock Down Exposed AI Services

Start with network segmentation. AI inference services should never be bound to public interfaces unless that is explicitly the product. Use private networking, VPCs, and security groups to restrict access to known application layers only.

Add authentication at the serving layer, not just at the application layer. Most frameworks support API key requirements or can be placed behind a reverse proxy with authentication middleware. Do not rely on the application above to enforce access control on the model below.

Run a DAST scan against your deployed AI infrastructure. Static code review will not catch a misconfigured binding or a missing firewall rule. Dynamic scanning hits the service as an attacker would and surfaces the actual exposure.

Audit HTTP response headers and error messages. Strip version strings and stack traces from production responses. That information shortens an attacker's reconnaissance time significantly.

Check your defaults. Read the security section of the documentation for every inference framework you deploy. Default configurations are written for developer convenience, not production hardness.

What is the most common mistake developers make with AI service security? Binding inference servers to 0.0.0.0 without authentication during development, then deploying that configuration to a cloud environment without adjusting firewall rules.

Can I use a WAF to protect an exposed AI endpoint? A WAF helps with application-layer attacks but does not replace authentication. An unauthenticated endpoint behind a WAF is still unauthenticated. Add API key enforcement at the serving layer first.

How do I know if my AI service is publicly exposed right now? Run a DAST scan against your production environment. You can start a free scan at VibeWShield to check for exposed endpoints, missing authentication, and information leakage in your AI stack.

Run a free scan on your AI services now and find out what attackers can already see. Start at VibeWShield.com/scan.