Прокси для API-ключей: что это и как работает

Схема, при которой настоящий ключ вообще не покидает хранилище, а приложения ходят в API с виртуальными токенами. Разбираем устройство, отличия от секрет-менеджеров и цену перехода.

Проблема: ключ нужен всем, а доверять нельзя никому

Один ключ OpenAI расходится по бэкенду, скриптам, CI, ноутбукам разработчиков и ИИ-агентам. Каждая копия — самостоятельная точка утечки: коммит в публичный репозиторий, строка в логе, дамп окружения. При этом у провайдера ключ один: утёк — отзывать и перевыпускать приходится везде сразу, с простоем всего, что на нём сидело.

Как устроен credential proxy

Прокси для ключей (credential proxy) разрывает связь «приложение — настоящий ключ». Три объекта:

приложение ──(vlt_проходка)──▶ прокси ──(настоящий ключ)──▶ провайдер
                                │
                     проверка: статус, IP, лимиты
                     лог: метод, путь, статус, время

Ключевое следствие: зона, где может утечь настоящий ключ, сжимается до одного сервера. Всё остальное — код, конфиги, CI, контексты агентов — оперирует только отзываемыми токенами.

Чем это отличается от секрет-менеджера

Vault или AWS Secrets Manager решают задачу хранения и доставки: ключ лежит централизованно, приложение получает его при старте. Но в момент работы ключ всё равно находится в памяти и окружении приложения — и утекает вместе с ним.

Credential proxy решает задачу невыдачи: приложение не получает ключ ни в какой момент. Это другой класс гарантий — утечка на стороне приложения по построению не может раскрыть оригинал.

Что меняется в коде

Две строки — хост и ключ. Всё остальное (путь, метод, тело, стриминг SSE) проходит через прокси без изменений:

# было — напрямую в OpenAI
curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer sk-...настоящий..."

# стало — через proxykey
curl https://api.proxykey.org/p/openai/v1/chat/completions \
  -H "Authorization: Bearer vlt_openai_..."

Для SDK это одна настройка baseURL. Поддерживаются OpenAI-совместимые API, Anthropic, Telegram-боты (токен в пути URL), Stripe, Slack, GitHub и любые кастомные REST API — полный список в документации.

Когда это особенно оправдано

• ИИ-агенты. Агенту нельзя доверять настоящий ключ — контекст модели утекает. Подробный разбор — в отдельной статье.
• Один ключ на много потребителей. Каждому приложению — своя проходка со своими лимитами; чей трафик — видно в логе; отключение одного не трогает остальных.
• Внешние подрядчики и стажёры. Доступ выдаётся и отзывается за секунды, оригинал не покидает компанию.
• Уже был инцидент. Если ключ утекал — вы знаете цену. Чеклист на этот случай.

Частые вопросы

Насколько это замедляет запросы?

Один дополнительный хоп и проверка токена по кэшу — единицы миллисекунд на фоне сотен миллисекунд генерации LLM. Стриминг проксируется потоково, без буферизации.

А если упадёт сам прокси?

Это честный trade-off схемы: прокси — критичная точка. Смотрите на устройство конкретного сервиса: в proxykey горячий путь работает с кэшем валидации и деградирует предсказуемо (кэш при недоступной БД, fail-closed для валидации).

Прокси видит мои запросы?

Прокси по определению стоит на пути трафика — важно, что он логирует. proxykey пишет метаданные (метод, путь, статус, задержку), но не авторизационные заголовки и не значения ключей; превью тел запросов — только если вы явно включили его для конкретной проходки.