What breaks when an LLM proxy has no authentication or authorisation?

The proxy stops being a controlled access layer and becomes a public gateway to privileged model resources. That allows anonymous users to invoke backend AI services, probe behaviour, and potentially extract hidden instructions. The failure is architectural, because the organisation has exposed a non-human access path without the governance controls that should restrict it.

Why unauthenticated LLM proxies change the security boundary

An LLM proxy is supposed to sit between users and model backends and decide who may call what, with which limits, and for what purpose. When authentication and authorisation are absent, that boundary disappears: the proxy no longer distinguishes trusted users from anonymous traffic, so the backend becomes reachable as if it were a public service. That matters because the proxy often fronts costly models, internal tools, hidden prompts, retrieval systems, or other sensitive capabilities. For a general reference on agentic and model-facing risk, see the OWASP Agentic AI Top 10.

The security problem is not limited to exposure. Without identity and permission checks, the proxy cannot enforce tenant separation, apply least privilege, or attribute actions to a caller. That weakens auditability, makes rate limiting and abuse response less reliable, and can allow requests that should have been blocked at the edge to reach the model tier. In practice, the question is not whether the model is powerful, but whether the organisation has left a privileged execution path open to anyone who can reach the endpoint. In practice, many security teams discover this only after the proxy has already been used as an ungoverned entry point to model and tool access.

How the failure plays out across model access, tools, and data

At a technical level, authentication answers who is calling, while authorisation answers what that caller is allowed to do. An LLM proxy without either control cannot reliably enforce session boundaries, service tiers, prompt constraints, retrieval permissions, or tool invocation policies. The result is that every request is treated as equally legitimate, even when the backend is designed to support multiple roles, environments, or data classes.

That breaks several practical assumptions at once. First, the proxy can no longer distinguish an approved application from an opportunistic external caller. Second, it cannot apply caller-specific restrictions to prompts, models, connectors, or output handling. Third, it cannot support accountability, because logs may show requests occurred but not whether the requestor was entitled to make them. For AI governance context, the NIST AI Risk Management Framework is useful because it frames the need for governed, traceable, and controlled AI use rather than open access by default.

Unauthenticated access enables probing of prompts, responses, and policy behaviour.
Missing authorisation can expose higher-value models, internal connectors, or privileged workflows to the wrong caller.
Anonymous use makes abuse harder to attribute, block, or investigate cleanly.
Any downstream tool integration inherits the same open-door problem if it trusts the proxy blindly.

In a mature deployment, the proxy should behave as a policy enforcement point, not a convenience layer. If it does not know who is calling, it cannot safely decide what that caller may see, submit, or trigger. That guidance breaks down when the proxy is only a local developer convenience and is never exposed beyond a tightly controlled machine boundary.

Where the answer stops being simple: internal, external, and agentic edge cases

Tighter access control often adds friction for developers and integration teams, requiring organisations to balance easy model access against traceability and containment. That trade-off is real, but it does not justify leaving a proxy open when the service can reach sensitive models or tools.

The main exception is a genuinely isolated test environment with no sensitive backend data, no persistent credentials, and no route into production systems. Even there, teams should treat the proxy as a trust boundary, because temporary setups are often where permissive patterns become normalised. Another edge case is service-to-service traffic: some teams assume that because the caller is “internal”, authentication is unnecessary. That is a mistake. Internal traffic still needs identity, because authorisation, logging, and revocation all depend on knowing which workload or service is speaking.

There is also a difference between public inference and agentic or tool-using systems. A simple text completion endpoint exposed without auth is bad; an unauthenticated proxy that can call retrieval systems, file stores, code execution, or admin tools is materially worse because the blast radius expands beyond model outputs. Where the proxy mediates those higher-risk actions, permissive access is not just a weak control but a governance failure. For a model-centric threat perspective, MITRE ATLAS adversarial AI threat matrix helps readers think about how adversaries abuse AI systems once access exists.

If teams are debating whether the proxy is “just internal,” the decisive question is whether it can reach anything that would matter if an unauthorised caller used it. If the answer is yes, the proxy is already part of the security perimeter, and leaving it unauthenticated is an avoidable exposure.

Risk and Threat Considerations

When an LLM proxy lacks authentication or authorisation, the primary risk is unauthorised access to a high-value AI control point. That creates exposure not only to model usage but also to prompts, hidden instructions, connected tools, and any data the proxy can reach. The threat is attractive because proxies often sit close to privileged model workflows while appearing simpler than the systems behind them.

Failure mechanism: an attacker or unauthorised user sends requests directly to the proxy, bypassing identity checks and permission gates. Once the proxy accepts arbitrary traffic, the attacker can probe behaviour, force repeated calls, and in some architectures trigger retrieval, tool execution, or data exposure through trusted backend integrations.

Impact: the organisation loses access control, accountability, and containment. Sensitive instructions may be disclosed, backend resources may be abused, costs may spike, and any connected tools or data sources may inherit the same unauthorised access path.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	A1	An open proxy weakens the trust boundary around model access and tool use.
Recommendation: Calls to the proxy must be identity-gated so untrusted users cannot reach privileged agent functions.
NIST AI RMF	GOVERN	The issue is governed AI access, accountability, and controllable use.
Recommendation: AI access should be governed and measurable, not exposed as an anonymous service path.
MITRE ATLAS	T1098	Unauthorised access through the proxy can be used to abuse trusted AI pathways.
Recommendation: Open access enables adversaries to exploit trusted AI workflows and related access paths.
CIS Controls v8	6	The core defect is missing authentication and authorisation at a control boundary.
Recommendation: Access to the proxy should be restricted and governed as a security control, not left public.
NIST CSF 2.0	PR.AA-01	The proxy lacks the identity and access controls needed to enforce who may use it.
Recommendation: Without identity and access controls, the proxy cannot enforce least privilege or accountability.

Practitioner Guidance

What to prioritise: treat the proxy as a protected access boundary, not a transport shortcut. If it can reach production models or tools, it needs caller identity, permission checks, and revocation capability before it is treated as usable.

What to verify: confirm that the proxy distinguishes human users, service accounts, and automated clients, and that those identities map to different permissions. Also verify that denied requests are denied before any backend model, retrieval, or tool call is made.

Decision rule: if the proxy can access private prompts, proprietary data, or action-capable tools, unauthenticated access is a release blocker. If it is only a disposable sandbox with no sensitive reach, the risk is lower, but the boundary should still be explicit and tested.

What practitioners underestimate: logging alone does not compensate for missing authorisation. You may know an anonymous request happened, but you still cannot reliably prove it should have been allowed or safely limit what it could touch.

Practitioner takeaway: the real failure is not “someone can call the proxy”; it is that the organisation has allowed an untrusted caller to enter a policy enforcement point that was supposed to protect models, data, and downstream actions.