Unique AI Documentation

LLM Proxies: Purpose and Security Policy

4 min read

Overview

Unique provides three authenticated passthrough proxies for clients and internal agent workflows that need provider-compatible APIs:

  • OpenAI proxy for OpenAI-compatible APIs, including Chat Completions, Responses, files, batches, assistants, containers, streaming, uploads, and binary responses.

  • Anthropic proxy for Anthropic-compatible Messages API requests, including regular and SSE streaming responses.

  • Cursor proxy for the subset of the Cursor API used by the Cursor SDK agent lifecycle.

These proxies let callers use provider-native request and response formats while Unique manages upstream credentials, model routing, usage attribution, limits, and security controls. Routes and request capabilities are checked before forwarding.

Provider-hosted tools deserve special attention because they execute under credentials held by Unique and may send prompts, files, or tool arguments to infrastructure outside Unique-controlled environments. The proxy policies therefore use explicit allowlists for tool capabilities and reject unknown typed tools by default.

Public endpoints and service location

Clients call the proxies below the Public API base path:

  • /public/chat/openai-proxy/{provider-path}

  • /public/chat/anthropic-proxy/{provider-path}

  • /public/chat/cursor-proxy/{provider-path}

All three proxies replace or supply the upstream authorization credential. Callers authenticate to Unique; provider credentials are kept in the backend.

OpenAI proxy

Purpose and routing

The OpenAI proxy exposes an OpenAI-compatible path surface. The requested model is resolved through Unique's OpenAI service factory, which selects the configured Azure OpenAI or LiteLLM-backed route. It supports normal JSON requests, SSE streaming, multipart uploads, and binary downloads.

Common examples include:

  • POST /v1/chat/completions

  • POST /v1/responses

  • GET /v1/models

  • File, batch, assistant, and container operations where enabled by the upstream API

OpenAI path checks normalize query strings, repeated slashes, trailing slashes, and encoded path segments before applying the security policy. Equivalent aliases such as /responses and /chat/completions receive the same checks as their /v1/... forms.

Tool and parameter policy (as of release .38)

For Chat Completions routes:

  • Allowed tool types: function, custom.

  • Blocked parameter: web_search_options.

  • The checks apply to both the top-level body and extra_body; therefore extra_body.tools and extra_body.web_search_options cannot bypass the policy.

For Responses and other OpenAI routes carrying tool declarations:

  • Allowed tool types: function, custom, apply_patch, local_shell, and code_interpreter.

  • shell is allowed only when environment.type is local.

  • All other typed tools are rejected by default.

This blocks provider-hosted capabilities such as:

  • mcp

  • web_search and web_search_preview

  • file_search

  • image_generation and image_generator

  • computer and computer_use_preview

  • Hosted shell environments

code_interpreter and OpenAI container routes remain available by design for approved code-execution workflows. Allowing container routes does not allow blocked tool declarations to bypass body validation.

The integrated /integrated/chat/stream-responses flow applies the same Responses tool policy to its options before calling the upstream model.

Anthropic proxy

Purpose and routing

The Anthropic proxy accepts Anthropic-compatible requests and forwards them through the company-scoped LiteLLM route. It supports regular Messages responses and SSE streaming while preserving company-level usage and cost attribution.

Common examples include:

  • POST /v1/messages

  • POST /v1/messages/count_tokens

Tool and parameter policy (as of release .38)

Allowed capabilities:

  • Untyped custom tool definitions

  • Tool type custom

  • Tool type function

  • Tool types beginning with code_execution

Blocked capabilities:

  • mcp_servers, both top-level and under extra_body

  • Typed web search and web fetch tools

  • Typed MCP tools

  • Advisor and tool-search tools

  • Browser and computer tools

  • Bash and text-editor tools

  • Memory tools

  • Any other unknown typed tool

Tool declarations are checked in both tools and extra_body.tools. Anthropic code_execution* remains enabled by design for approved code-execution workflows.

Cursor proxy

Purpose and routing

The Cursor proxy supports the API surface required by the Cursor SDK to create, run, resume, and dispose agents. Requests are forwarded directly to configured Cursor upstreams with the platform-held Cursor credential:

  • Primary API: CURSOR_API_BASE_URL, defaulting to https://api.cursor.com

  • Authentication API: CURSOR_AUTH_API_BASE_URL, defaulting to https://api2.cursor.sh

Regular responses and Cursor's NDJSON streaming responses are supported.

Allowed routes

Cursor uses a route allowlist rather than the broader denylist used by the OpenAI and Anthropic proxies. Only these routes and methods are forwarded:

  • /v1/agents and descendant agent lifecycle routes: GET, POST, PATCH, DELETE

  • /v1/models: GET

  • /v1/me: GET

  • Exact route /auth/exchange_user_api_key: POST

Every other Cursor route or method is blocked. Cursor does not currently apply an OpenAI/Anthropic-style body tool filter; its security boundary is the narrow route-and-method allowlist required by the SDK.

Route security

OpenAI and Anthropic denied routes

OpenAI and Anthropic use a denylist because their supported provider-compatible API surface is broad. The following logical route prefixes and their descendants are blocked:

  • Root proxy path

  • /admin

  • /api-keys

  • /cohere

  • /gemini

  • /key

  • /model and /models

  • /openai_passthrough

  • /organization

  • /scim

  • /settings

  • /spend

  • /team

  • /user

  • /v1/me

The OpenAI proxy additionally blocks /anthropic to prevent switching provider protocols through the OpenAI surface.

Paths are decoded and normalized before matching. Dot-segment paths, malformed encoding, repeated-prefix tricks, and encoded variants of blocked routes cannot bypass the route policy.

Cursor denied routes

For Cursor, every route not present in the allowlist above is denied. This prevents a caller from using Unique's Cursor credential against billing, account-management, administrative, or future Cursor APIs that have not been explicitly reviewed.

Rejection behavior

Security checks run before the upstream request is sent.

  • A blocked route is rejected with HTTP 403.

  • A malformed or disallowed request capability is rejected as a client error by node-chat.

  • The 2026-03-01 unique-api OpenAI/Anthropic facades may expose forwarded non-streaming proxy validation failures as HTTP 422 according to their upstream-error contract.

  • Streaming facades relay upstream status and body where supported.

The policy implementation and tests are the source of truth when provider APIs evolve.

Last updated