Прокси для API-ключей: сравнение подходов

За задачей «не дать приложению настоящий ключ» стоят четыре довольно разных решения. Это не конкурирующие реализации одной идеи — они закрывают разные проблемы, и ошибка в выборе категории обходится дороже, чем ошибка в выборе продукта. Ниже — что каждый подход делает на самом деле, написанное в том же духе, что и наша модель угроз: включая случаи, где ответ — не мы.

Четыре подхода

1. Хранилище секретов — HashiCorp Vault, Doppler, AWS Secrets Manager, .env

Хранит секрет и отдаёт его вам по запросу. Последнее — и весь смысл, и вся проблема: с момента выдачи ключ живёт в памяти процесса, в переменных окружения, в дампах при падении, в том, что решит сериализовать ваш логгер, и — если запросил агент — в контексте модели. Хранилище защищает ключ в покое и по дороге к вам. После выдачи защищать уже нечем, потому что выдача и есть его функция.

Брать, когда потребитель — ваш собственный доверенный бэкенд, и нужно одно место для паролей от баз, сертификатов и ключей подписи. Это инфраструктура, и подходы ниже её не заменяют.

2. LLM-шлюз с виртуальными ключами — LiteLLM, Portkey

Стоит перед провайдерами моделей и выдаёт свои ключи вместо провайдерских. LiteLLM выпускает виртуальные ключи с бюджетами, ограничением доступных моделей, лимитами и учётом трат по каждому ключу; Portkey добавляет облачную панель управления, очень широкий каталог моделей и наблюдаемость. Настоящие ключи остаются внутри шлюза. Если ваша задача — именно LLM-трафик, эта категория сильнее нас: она понимает токены, стоимость, маршрутизацию между моделями, кеширование и фолбэки, а мы всего этого сознательно не делаем.

Брать, когда трафик — в основном обращения к моделям и нужен контроль расходов, маршрутизация между провайдерами или специфичная для LLM аналитика.

Граница: шлюз говорит на языке LLM. Туда, где всё построено вокруг chat completions, не кладут секретный ключ Stripe, токен телеграм-бота или GitHub PAT.

3. Локальный прокси с перехватом TLS — Infisical Agent Vault

Работает на вашей машине или внутри вашей инфраструктуры и перехватывает HTTPS-трафик агента: агент ходит через него по HTTPS_PROXY, прокси терминирует TLS с помощью локально доверенного удостоверяющего центра, срезает подставной ключ, подставляет настоящий и открывает уже нормально проверенное соединение наверх. Работает с любым API и — по-настоящему изящная часть — вообще не требует менять код агента, потому что агент по-прежнему уверен, что обращается напрямую к api.stripe.com.

Брать, когда вы не можете или не хотите править вызывающий код, когда учётные данные не должны покидать ваше железо, или когда оборачиваете агента, чьими HTTP-запросами вы не управляете.

Цена: в хранилище доверия агента придётся поставить свой удостоверяющий центр, а сам прокси — поднимать и обслуживать. Право перехватывать TLS — серьёзное полномочие для компонента; это осознанный размен, а не изъян, но размен настоящий.

4. Облачный прокси учётных данных — proxykey

Настоящий ключ вы кладёте один раз, он шифруется AES-256-GCM и не покидает сервер. Клиенты получают проходку (vlt_…) и обращаются к явному адресу: меняете хост с https://api.openai.com/v1/… на https://api.proxykey.org/p/openai/v1/…, остальное оставляете как было. У каждой проходки своя привязка к IP, лимиты rpm/rpd, срок и лог запросов, и отзывается она отдельно, не задевая оригинал. Любые API, не только модели — больше 25 провайдеров, включая Stripe, Telegram, GitHub, Notion, Airtable, плюс режимы для произвольного HTTP-API с любой схемой авторизации. Есть MCP-сервер, чтобы агент сам выписывал и отзывал себе проходки, не имея инструмента для чтения секрета.

Брать, когда вызывающая сторона не вполне доверенная — мобильное приложение, браузер, скрипт подрядчика, ИИ-агент, — API не обязательно языковая модель, и поднимать под это инфраструктуру не хочется.

Цена: придётся поменять адрес в коде, чего третья категория не требует. И это облако — то есть оператор попадает внутрь вашего контура доверия; мы говорим об этом прямо и подробнее на странице модели угроз, а не делаем вид, что этого нет.

Рядом друг с другом

На узком экране таблица прокручивается вбок. Составлено по публичной документации каждого проекта, ссылки выше, в августе 2026 года. Продукты меняются быстро — если что-то устарело, напишите, поправим.

Выбор в одну строку

• Потребитель — ваш собственный бэкенд → хранилище секретов. Больше ничего не нужно.
• Трафик — в основном обращения к моделям, нужны бюджеты, маршрутизация, аналитика → LLM-шлюз.
• Код клиента менять нельзя или ключи не должны покидать ваше железо → локальный прокси с перехватом TLS.
• Клиент недоверенный, API разные, поднимать ничего не хочется → облачный прокси учётных данных. Это мы.

Когда proxykey — неправильный выбор

Три случая, названные прямо, потому что узнать о них потом хуже:

• Вы не можете трогать вызывающий код. Нам нужна замена хоста. Если это невозможно — третья категория сделана ровно под вас.
• Регламент запрещает третью сторону в пути учётных данных. Облачный прокси расшифровывает ключ в памяти, чтобы подписать каждый запрос. Если это неприемлемо — а для части организаций это справедливо, — берите то, что разворачивается у вас.
• Нужен контроль расходов на модели. Бюджеты по моделям, учёт токенов, семантическое кеширование, цепочки фолбэков — мы этого не делаем и не планируем. LiteLLM и Portkey делают это хорошо.