AML.T0132 Misconfigured or Publicly Exposed AI Services: Finding and Fixing Exposed AI Services Before Attackers Do

Self-hosted model servers, vector databases, agent control panels and low-code agents are routinely reachable from the internet with no authentication, and attackers are scanning for them. MITRE ATLAS added AML.T0132 Misconfigured or Publicly Exposed AI Services in its September 2026 release, under the Initial Access tactic (AML.TA0004), with a maturity of Demonstrated. The technique covers access control gaps that range from missing authentication in LLM runtimes to permissive public settings on SaaS agent builders. This guide explains which AI components are most often exposed and why, the cases ATLAS and researchers have recorded, how to find your own exposed services before someone else does, and the controls that close them. It is written for platform engineers, cloud security teams and AI product owners. For general external exposure management, see the Attack Surface Management Guide.

Key takeaways

• Many AI runtimes trust the network by design. Ray, vLLM's distributed ports and self-hosted Qdrant all document that they expect a trusted network; exposing them to the internet hands out their full capability.
• An API key flag rarely covers every endpoint. vLLM's own security documentation states that --api-key protects only some path prefixes, while other endpoints, including inference ones, stay open.
• The time from exposure to probe is hours. Pillar Security's honeypots saw exploitation attempts within hours of an endpoint appearing in Shodan or Censys results.
• Exposed AI services leak non-human identities. Agent configuration files and runtimes hold provider API keys, bot tokens and OAuth credentials, so one open control panel becomes a credential breach.
• Fix the default, then watch the edge. Bind to private interfaces, require authentication at a gateway, enforce it with policy, and scan your own address space continuously.

What AML.T0132 describes

ATLAS describes AI agents and LLM platforms as deployed across standalone servers, SaaS platforms and low-code builders, all of which often have misconfigured access controls. Its key point is that an AI service's security posture decides how much of the agentic attack surface an adversary can even see: one internet-facing service may be discoverable by any unauthenticated user, while another needs compromised credentials before it can be found. Adversaries find exposed services through search engines (AML.T0000 Search Open Technical Databases), backlinks to embedded agents (AML.T0095 Search Open Websites/Domains) and direct scanning (AML.T0006 Active Scanning). See the MITRE ATLAS Guide for how the tactics fit together.

T0132 has no direct ATT&CK parent. The closest ATT&CK techniques are T1190 Exploit Public-Facing Application, when a flaw is involved, and T1133 External Remote Services, when the exposed interface is itself a remote control channel. The distinction that matters is that T0132 needs no vulnerability: the service does exactly what it was configured to do, for anyone. Where a real flaw is chained in, the T1190 Exploit Public-Facing Application Defensive Guide applies.

Which AI services get exposed, and why

The table lists the component types seen most often, the default or documented behaviour that leads to exposure, and the first fix. Defaults are quoted only where the project's own documentation states them.

The pattern behind every row is the same: a component built for a developer laptop or a private cluster gets a public IP, a tunnel or a permissive setting so that a demo, a teammate or a front end can reach it. For per-product hardening, see the vLLM, Triton and NVIDIA NIM Inference Server Security Guide, the Ray and AI Compute Cluster Security Guide and the Vector Database Security Guide.

Cases: what exposure leads to

• ShadowRay (ATLAS AML.CS0023): Oligo found exposed Ray clusters exploited for at least seven months, with the earliest evidence dated 5 September 2023. Attackers ran crypto miners on GPU nodes and took OpenAI, Hugging Face, Stripe and Slack tokens, database credentials and cloud access keys. The underlying CVE-2023-48022 is disputed because Anyscale treats unauthenticated job submission as a design decision for trusted networks, which is why, as Oligo noted, dependency scanners may not flag it.
• Exposed ClawdBot control interfaces (AML.CS0048): a researcher used Shodan to find exposed instances of the personal AI assistant now called OpenClaw. From the control interface he read configuration files holding Anthropic API keys, Telegram bot tokens, Slack OAuth credentials and Signal device-linking URIs, and prompted the agent to run commands through its bash skill, reaching root in at least one container.
• Operation Bizarre Bazaar: Pillar Security's honeypots captured about 35,000 attack sessions between December 2025 and January 2026 against unauthenticated Ollama servers on port 11434, OpenAI-compatible APIs on port 8000, MCP servers without access controls and public staging AI infrastructure, with stolen inference access resold through a marketplace.
• Moltbook: an open Supabase database behind a social network for AI agents exposed about 1.5 million agent API tokens, with write access that would have let anyone seed content agents later read. See the Moltbook database exposure analysis.
• McKinsey Lilli: a security start-up reported that 22 of more than 200 documented API endpoints behind an internal generative AI platform accepted requests with no authentication, and its autonomous agent chained one of them to SQL injection. McKinsey's forensics review found no evidence that client data was accessed. See the McKinsey AI platform hack analysis.

Finding your own exposed AI services

Look from outside first, because that is the view the adversary has, then reconcile it with what you think you run.

1. Build the AI service inventory. List every model runtime, inference server, vector database, agent framework, MCP server and low-code agent, with owner, network location and authentication method. The Shadow AI Discovery Guide covers finding the ones nobody registered.
2. Scan your own address space for AI ports and paths. Add the well-known ports from the table (for example 11434, 8000, 8265, 6333, 6334) and the standard API paths of the runtimes you use to your external attack surface tool's checks. Treat any answer from the internet as a finding.
3. Query internet search engines for your ranges. Shodan and Censys are what attackers used in the cases above; checking your own ASN and cloud ranges there shows what is already indexed.
4. Review cloud configuration. Look for security groups and firewall rules that allow 0.0.0.0/0 to AI hosts, public load balancers in front of model servers, and Kubernetes services of type LoadBalancer or NodePort for AI workloads.
5. Review SaaS agent settings. Export agent authentication settings from low-code platforms and list every agent set to no authentication or shared publicly.
6. Test as an anonymous user. For every AI front end and backend database, confirm what an unauthenticated request can read and write, as the Moltbook lessons recommend.
7. Check tunnels. Developer tunnels (ngrok, Cloudflare Tunnel and similar), which the Ollama FAQ documents for exposing a local server, bypass perimeter controls; inventory them through egress logs and endpoint telemetry.

Detection: signs an exposed service is being used

ATLAS lists AML.M0039 AI Honeypots against T0132: a decoy model endpoint or agent panel on an unused address turns early scanning into signatures before real assets are touched. The Honeypot deployment guide covers placement and isolation.

Controls that close the exposure

• Bind privately by default: loopback for local development and a private interface or VPC address in production. Qdrant's docs give this advice directly (service.host), and Oligo gives it for the Ray dashboard.
• Put authentication in front, not only inside: route every AI endpoint through an authenticating reverse proxy or AI gateway that allowlists the endpoints you serve and adds rate limiting and logging, as vLLM's documentation recommends. See the AI Gateway and LLM Gateway Guide.
• Turn on the authentication the product offers: Ray token authentication (the current Ray security documentation describes it as on by default from Ray 2.61 and available from 2.52.0), Qdrant API keys and JWT RBAC, vLLM --api-key as one layer only.
• Enforce with policy: a Power Platform data policy that requires authentication removes the "No authentication" choice for Copilot Studio makers; cloud policy can deny public IPs and 0.0.0.0/0 ingress on AI-tagged workloads.
• Segment agent components: ATLAS AML.M0032 Segmentation of AI Agent Components keeps one exposed service from reaching the rest of the agent stack.
• Keep credentials out of exposed hosts: agent runtimes should fetch short-lived credentials from a secrets manager rather than hold provider keys in configuration files. See MITRE ATLAS AML.T0083 Credentials from AI Agent Configuration.
• Keep MCP servers off the internet: Pillar's data showed MCP-focused reconnaissance becoming the majority of late-January traffic. See the MCP Server Security Checklist.

Where identity fits

An exposed AI service is an access control failure for two kinds of identity at once. The caller is anonymous where it should be an authenticated user or workload, and the service itself usually holds non-human credentials (provider API keys, bot tokens, cloud keys, database passwords) that become the real prize. Treat every AI runtime as a workload with its own identity, give it scoped and short-lived credentials, and make "who can call this endpoint" a reviewed entitlement. The Agent Identity and Access Guide covers the agent side.

Rollout and testing

1. Week 1, triage: run the external scan and SaaS settings export; close anything answering from the internet with no authentication, starting with services that can run code (Ray, agent control panels) and those holding credentials.
2. Rotate: for every service that was exposed, rotate the credentials it held, because you cannot prove they were not read.
3. Weeks 2 to 4, front door: move remaining AI endpoints behind the gateway or proxy; test with the old direct URL from an external host, which must fail.
4. Policy: apply data and cloud policies in audit mode first, review hits with owners, then enforce. Roll back by returning the policy to audit, not by reopening the service.
5. Continuous: add AI ports and paths to scheduled external scans, deploy a decoy endpoint, and add T0132 to red team scope using organisation-owned test infrastructure.

Metrics

• Number of AI services reachable from the internet without authentication (target zero), by component type.
• Mean time from an AI service becoming externally reachable to detection by your own scan.
• Percentage of inventoried AI services behind the gateway or authenticating proxy.
• Percentage of low-code agents covered by an authentication-required data policy.
• Number of AI runtimes holding long-lived provider keys in local configuration.

Framework mapping

Common failure patterns

• Trusting the API key flag. Teams set --api-key on vLLM and consider the server protected, while unprotected inference and operational endpoints remain reachable on the same port.
• Demo becomes production. A tunnel or public IP opened for a demo is never closed, and the service is indexed within days.
• Proxy trust misconfiguration. Authentication that trusts requests arriving from localhost breaks when a reverse proxy makes every request look local, the class of issue seen in AML.CS0048.
• Not rotating after closing. Closing the port without rotating the keys the service held leaves attackers with working credentials, as the ShadowRay token theft shows.
• Scanning only for known vulnerabilities. Exposure by design has no CVE to match, or a disputed one. Scan for reachability and authentication, not only versions.

Practitioner checklist

• Maintain an AI service inventory with owner, network exposure and authentication method.
• Add AI runtime ports and API paths to scheduled external attack surface scans.
• Bind model servers, vector databases and compute dashboards to private interfaces.
• Front every AI endpoint with an authenticating gateway or proxy that allowlists endpoints.
• Enable product authentication (Ray token auth, Qdrant API keys, vLLM API key) as an extra layer.
• Require authentication for low-code agents through platform data policy.
• Remove long-lived provider keys from agent and runtime configuration files.
• Rotate every credential held by a service found exposed.
• Deploy a decoy AI endpoint and alert on any interaction.

Standards and references

• MITRE ATLAS: Misconfigured or Publicly Exposed AI Services (AML.T0132)
• MITRE ATLAS: Exposed ClawdBot Control Interfaces case study (AML.CS0048)
• MITRE ATLAS: ShadowRay case study (AML.CS0023)
• Ray: Security documentation
• vLLM: Security
• Qdrant: Security
• Microsoft Learn: Configure user authentication in Copilot Studio
• Oligo Security: ShadowRay, AI workloads actively exploited in the wild

Related NHI Mgmt Group resources: Attack Surface Management Guide · Vector Database Security Guide · vLLM, Triton and NVIDIA NIM Inference Server Security Guide · MITRE ATLAS Mitigations Guide