Attackers do not need to compromise the model itself if the endpoint is exposed. They can call inference directly, reuse free-tier access, or pivot through leaked keys and self-hosted proxies. The failure is a governance failure at the service boundary, where identity and authorization controls were not applied to a high-value runtime asset.
Why weak inference authentication breaks the service boundary
An exposed LLM inference endpoint is not just a technical convenience, it becomes a policy enforcement point. If the caller is not strongly authenticated, the system cannot tell a legitimate tenant from a scraper, a free-tier abuser, or a proxy laundering stolen access. That turns inference into an unaudited public utility instead of a governed runtime service.
The practical failure is that the model can still be “working” while the access model has already failed. In that condition, abuse starts with direct invocation of the endpoint, but the real damage comes from the lack of trust decisions around who may consume tokens, which tenant is responsible, and whether usage should be rate-limited, metered, or blocked.
When teams treat inference as an application feature rather than a protected service boundary, they often miss that the runtime itself is the asset. NIST AI 600-1 GenAI Profile is useful here because it frames governance, testing, and incident handling around the deployment of GenAI services, not just the model artifact.
What attackers gain when inference is open or weakly authenticated
Open inference gives attackers a low-friction way to consume compute, extract value, or chain the endpoint into a broader abuse path. They can reuse leaked keys, abuse shared or free-tier credentials, hide behind self-hosted proxies, or script high-volume calls that look like ordinary usage until cost, latency, or downstream content impact becomes visible.
That access path also creates a clean pivot point. Once an attacker can invoke the service, they may test prompt injection, enumerate hidden capabilities, force expensive completions, or use the endpoint as a relay into data-connected features such as retrieval, tool calls, or connected APIs. The weakness is not limited to confidentiality, because the same access can create availability and integrity harm.
OWASP API Security Top 10 maps well to this failure mode, especially broken authentication, broken object-level authorization, and unrestricted resource consumption. NIST SP 800-63 Digital Identity Guidelines is also relevant where human or tenant authentication assurance is part of preventing anonymous or easily replayed access.
How to recognize the control gap before it becomes abuse
The warning sign is not only “the endpoint is public.” It is any setup where inference can be called without a durable identity, where keys are long-lived and shared, where usage is not attributable to a tenant, or where reverse proxies and gateways can be bypassed directly. If a caller can reach the model without passing a policy decision, authentication is effectively advisory.
Practitioners should look for three conditions together: no strong caller identity, no clear authorization boundary, and no abuse containment. If one tenant can impersonate another through a leaked token, or if anonymous callers can trigger expensive generations, the service boundary is already broken even if the model output still appears correct.
NIST Cybersecurity Framework 2.0 supports the broader governance view of this issue, because the failure sits across govern, protect, detect, and respond. For architecture that assumes continuous verification and least privilege at the edge, NIST SP 800-207 Zero Trust Architecture is the clearest fit.
Risk and Threat Considerations
Open or weakly authenticated inference creates a direct abuse surface for theft of compute, unauthorized content generation, and tenant impersonation. It also increases the chance that leaked credentials or proxy relays will be used to bypass internal controls, because the service has no reliable basis for distinguishing approved consumers from opportunistic ones.
Failure mechanism: The system accepts requests without a sufficiently strong identity assertion or without binding that identity to an authorization decision at the service boundary, so any reachable client can consume the runtime.
Impact: Attackers can generate cost, evade attribution, abuse quotas, reach connected data or tools, and turn a high-value runtime into an uncontrolled external service.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST AI 600-1, NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI 600-1 | Generative Artificial Intelligence Profile | GenAI service governance and deployment controls fit exposed inference boundaries. |
| Recommendation — Apply GenAI governance, testing, and incident controls to the inference service boundary. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Weak inference access is fundamentally an authentication failure at the API boundary. |
| API4 — Unrestricted Resource Consumption | Open inference is easily abused for token and compute exhaustion. | |
| Recommendation — Require strong authentication before allowing inference requests. Rate-limit and quota-protect inference to prevent runaway consumption. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Caller assurance and phishing-resistant authentication help prevent proxy and token abuse. |
| Recommendation — Use high-assurance authentication for users or tenants calling inference. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Inference services need authenticated organizational callers at the boundary. |
| AC-6 — Least Privilege | Inference access should be scoped so callers only reach approved runtime actions. | |
| Recommendation — Authenticate organizational users before granting inference access. Limit each caller to the minimum inference permissions required. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The failure is a governance and access-control gap at the runtime boundary. |
| Recommendation — Enforce identity and access control at the inference service boundary. | ||
Practitioner Guidance
What to verify: Confirm that every inference request is authenticated at the boundary, that the credential is scoped to a tenant or workload, and that direct endpoint access without the gateway is impossible or harmless. If the same key can be reused across environments or hidden inside a proxy, treat that as an exposure, not a convenience.
What good looks like: The inference service rejects anonymous traffic, ties usage to a specific identity, and enforces metering, throttling, and authorization before the model is called. In mature setups, the team can answer who called, what was allowed, and what was consumed without reconstructing the story from logs alone.
Practitioner takeaway: The key decision is not whether the model is accurate, but whether every caller is forced through an enforceable trust boundary before it can spend compute or reach connected capabilities.
Related resources from NHI Mgmt Group
- What breaks in healthcare security when authenticated workstations are left open at the point of care?
- What breaks when offline desktop access is left open-ended?
- What breaks when a customer-data API is left open to the public internet?
- What breaks when organisations do not govern LLM inference access like a credentialed service?