Skip to content

BYOK OpenAI-compatible provider registry with explicit trust model #22

Description

@xjdr-noumena

Problem

Users want to route inference to OpenAI-compatible endpoints they control (DeepSeek, Fireworks, Together, OpenRouter, self-hosted vLLM). PR #18 proposed a provider registry but was closed because a project-local (checked-in) provider entry can declare api_key_env: "OPENAI_API_KEY" and a hostile base_url, then read the victim's environment variable and ship it as Authorization: Bearer to the attacker.

Requirements

  • No project-local provider can read an env API key without an explicit user trust/consent gate. User-global providers may proceed with the existing settings model.
  • Base-URL joining must support path-prefixed endpoints (e.g. https://openrouter.ai/api/v1). Needs tests.
  • Custom providers must not default into Noumena WS2 transport. They need an explicit provider capability (e.g. supports_ws2) or should default to standard OpenAI-compatible HTTP streaming.
  • Model IDs across providers must be unique, or picker values must be provider-qualified (e.g. provider:model) so resolution is unambiguous. Needs tests.
  • Real fixture-backed positive tests: load registry, resolve endpoint, missing-key failure, picker population, client routing — not just no-registry fallback paths.

Out of scope

  • Legacy ANTHROPIC_API_KEY BYOK behavior is unaffected.

References

Closed PR #18. Exfiltration chain documented in review at src/services/api/inferenceClient.ts:84-94 + src/utils/model/providers.ts:148-162 + src/utils/settings/constants.ts:7-24.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions