блог · 10 сентября 2026 · 7 минут

ProxyKey MCP: как дать ИИ-агенту доступ к API без выдачи ключа

Мы уже писали, зачем нужен credential-прокси и почему «zero-knowledge» тут невозможно по архитектуре — это ProxyKey, наш проект. Здесь — практика: как подключить Claude Code или Cursor к ProxyKey через MCP, какие 13 инструментов у агента есть, почему среди них нарочно нет «прочитать ключ», и как выглядит сценарий, ради которого мы это строили — агент деплоит бота, у которого ещё нет токена.

Зачем агенту вообще MCP к вейлту, а не просто ключ в .env

Агент вроде Claude Code или Cursor раскладывает переменные окружения, пишет конфиги, иногда логирует то, что делает. Всё, что попало в контекст модели, нужно считать опубликованным: контекст логируется, трассируется, из него можно вытащить секрет промпт-инъекцией. Выдавать такому агенту боевой ключ от OpenAI или токен телеграм-бота — то же самое, что выдать его случайному скрипту в интернете.

MCP-сервер ProxyKey закрывает это на уровне протокола доступа: агент получает инструмент вместо секрета. У инструмента физически нет операции «вернуть значение ключа» — ни для одного из 13 методов. Агент может создать, отозвать, повернуть пропуск (pass), посмотреть лимиты и логи запросов — но прочитать оригинал не может, потому что такой ручки просто не существует в API.

Подключение: Claude Code и Cursor

Сначала — обычный человеческий шаг: зайти в app.proxykey.org (вход через GitHub OAuth или magic link, бесплатно), открыть раздел MCP и создать токен вида mcp_…. Дальше агенту передаётся только этот токен — не реальные ключи провайдеров.

Для Claude Code — одна команда:

claude mcp add --transport http proxykey https://mcp.proxykey.org/mcp \
  --header "Authorization: Bearer mcp_YOUR_TOKEN"

Для Cursor и Claude Desktop — запись в mcp.json:

{
  "mcpServers": {
    "proxykey": {
      "url": "https://mcp.proxykey.org/mcp",
      "headers": { "Authorization": "Bearer mcp_YOUR_TOKEN" }
    }
  }
}

После этого агент видит инструменты ProxyKey как любые другие MCP-tools и может вызывать их сам, без участия человека на каждом шаге.

13 инструментов — и почему среди них нет «прочитать ключ»

Полный список того, что доступно агенту через MCP:

Заметьте: ни в одной из 13 операций нет параметра, который возвращал бы значение секрета. Это не договорённость «агент обещает не смотреть» — такой возможности физически нет в контракте API. По той же причине MCP-слой не может включить логирование тел запросов (это тоже остаётся человеку в панели) — иначе через логи ключ можно было бы восстановить окольным путём.

Сценарий pending secret: агент деплоит бота без токена

Вот ради чего мы всё это строили. Обычная ситуация: агент разворачивает Telegram-бота, пишет код, настраивает вебхук — а токена от BotFather у него ещё нет, потому что бота ещё не завели.

Вместо того чтобы блокироваться и ждать человека, агент вызывает create_pending_pass. Пропуск (vlt_…) выдаётся сразу и его можно сразу прописать в конфиг бота — но проксирование реального трафика заблокировано статусом original_key_required, пока секрет не заполнен. Дальше агент вызывает get_manual_secret_setup и отдаёт человеку ссылку.

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

Что человек видит в панели

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

Разделение простое: всё, что может раскрыть значение секрета, доступно только человеку через панель. Всё, что нужно агенту для повседневной работы — выпуск, отзыв, ротация, мониторинг, — доступно через MCP.

Сама прокси-часть: как выглядит вызов

Когда пропуск выдан, приложение или агент обращаются к прокси вместо провайдера — меняются только хост и ключ, путь и тело остаются теми же:

# было
curl https://api.openai.com/v1/chat/completions -H "Authorization: Bearer sk-..."
# стало
curl https://api.proxykey.org/p/openai/v1/chat/completions -H "Authorization: Bearer vlt_openai_..."

Стриминг (SSE), тело запроса и заголовки проходят без изменений. У телеграм-ботов сохраняется привычная форма URL: /p/telegram-bot/<pass>/getMe.

Ограничение, о котором нужно сказать честно

Hosted-прокси не может быть zero-knowledge по архитектуре: чтобы подставить ключ в запрос к провайдеру, прокси обязан расшифровать его в памяти в момент обработки. Значит, процесс с полным доступом — а вместе с ним оператор сервиса — теоретически может получить открытое значение. Это не баг конкретно ProxyKey, а свойство любого хостингового решения такого класса. Мы разбирали это подробно на странице security: что именно шифрование защищает (утечку базы, бэкапа, логов), а что нет (полную компрометацию сервера). MCP-доступ агента сюда не добавляет нового риска — он ограничен ещё жёстче, чем доступ человека в панели.

Когда это не нужно

• У вас один ключ и один потребитель. Если ключ используется в одном месте, которое вы полностью контролируете, и агент к нему не притрагивается — прокси добавляет точку отказа без реальной выгоды.
• Ваш threat model не допускает третью сторону в цепочке запроса. Прокси видит трафик (даже если логирует только метаданные). Если это неприемлемо — держите собственный инстанс credential-прокси или не используйте паттерн вовсе.
• Критична задержка на уровне единиц миллисекунд. Лишний хоп и обращение к кэшу валидации добавляют накладные расходы. Для LLM-вызовов это незаметно на фоне генерации ответа, для части низколатентных не-LLM API — может быть важно, здесь стоит считать отдельно.

Итог

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