HTTP-аутентификация для ИИ-агентов: безопасные схемы работы с учетными данными

ИИ-агент должен уметь запросить HTTP-действие, ни разу не получив учетные данные, которые делают это действие возможным. Это правило важнее того, использует ли запрос bearer-токен, Basic-аутентификацию или заголовок провайдера. Если секрет попал в контекст агента, он может утечь через промпт, трассировку инструмента, сгенерированную команду оболочки, файл репозитория или последующее резюме, которое никто не собирался сохранять.

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

Агенты превращают обычные учетные данные в копируемые данные

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

Опасная цепочка часто сначала выглядит безобидно:

1. Планировщик задач помещает PAYMENTS_TOKEN в окружение процесса агента.
2. Агент запускает диагностическую команду, которая выводит окружение или записывает скрипт оболочки.
3. Скрипт попадает в репозиторий, артефакт CI, прокрутку терминала или другой вызов инструмента агента.
4. Позже кто-то находит токен и отправляет действительные запросы, пока он не истечет или оператор его не отзовет.

Сложному атакующему не понадобилось ничего делать. Секрету было достаточно стать текстом в месте, созданном для копирования текста.

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

Поэтому HTTP-аутентификация для ИИ-агентов требует двух отдельных границ. Агенту нужно разрешение предложить запрос. Доверенному компоненту нужны хранение учетных данных и право отправить запрос. Если объединить эти границы, агент получит копируемый секрет, а последующие меры контроля начнут зависеть от безошибочного обращения агента с ним. Это неоправданное предположение.

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

Bearer-токены легко отправлять и легко повторно использовать

Bearer-токен дает доступ тому, кто его предъявляет, поэтому агент никогда не должен получать такой токен, если вы не готовы к тому, что утечка расшифровки превратится в утечку доступа к API. RFC 6750 описывает использование bearer-токена в заголовке запроса Authorization:

GET /v1/projects/alpha/releases HTTP/1.1
Host: api.example.test
Authorization: Bearer eyJhbGciOi...
Accept: application/json

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

RFC 6750 допускает передачу bearer-токенов в теле формы при ограниченных условиях и описывает передачу через URI-параметры для устаревших случаев. Не помещайте их в строки запроса. URL быстрее попадают в историю браузера, журналы прокси, системы аналитики, заголовки referrer, обращения в поддержку и логи приложения, чем ожидает большинство команд. Сам стандарт предупреждает, что передача через URI с высокой вероятностью приведет к раскрытию. Нет веской причины делать секрет агента частью URL.

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

Обычно передать bearer-токен агенту предлагают ради скорости: одна переменная окружения, один HTTP-клиент, никаких дополнительных компонентов. В демонстрации это работает, поэтому подход популярен. Но он ломается, когда агенту нужны отладка, делегирование, длительная работа или доступ к нескольким сервисам. Скопированный в контекст токен сложнее избирательно отозвать, поскольку вы уже не знаете, где он побывал.

Есть и другая ловушка: токен с ограничительным названием все равно может обладать широкими фактическими правами. Изучите документацию провайдера и выясните реальную модель областей действия. Одни сервисы используют области для отдельных конечных точек. Другие предоставляют права на уровне организации, проекта, репозитория или учетной записи. Некоторые API-токены незаметно наследуют все права пользователя, который их создал. Название токена не доказывает, что его возможности ограничены.

Посредник может хранить bearer-токен и формировать заголовок только после проверки целевого назначения. Агент должен передавать намерение и данные запроса, например «создать релиз в проекте alpha с таким телом», а не буквальный заголовок Authorization. Исполнитель добавляет секрет после проверки и удаляет его до возврата любых записей агенту.

Для Basic-аутентификации нужна отдельная сервисная идентичность

Basic-аутентификация допустима для узкой сервисной учетной записи поверх TLS, но это плохой способ передать агенту имя пользователя и пароль человека. RFC 7617 задает формат передачи как кодировку Base64 строки user-id:password, помещенную в заголовок Authorization:

Authorization: Basic YWdlbnQtcmVsZWFzZXI6czNjcjN0LXZhbHVl

Любой, кто может прочитать это значение, сможет его декодировать. Base64 меняет представление, но не защищает значение. TLS защищает соединение между клиентом и сервером, однако не защищает учетные данные после того, как агент, локальный процесс, отладочный журнал или прокси скопировали заголовок.

Многие провайдеры API используют Basic-аутентификацию с API-токеном в качестве пароля и фиксированным или игнорируемым именем пользователя. Это не превращает схему в более слабую разновидность bearer-аутентификации. Риск повторного использования остается, а к нему добавляются практические проблемы. Клиент или журнал может записать декодированное имя пользователя, исходный заголовок или и то и другое. Разработчик может повторно использовать настоящий пароль учетной записи, поскольку протокол называет второе поле паролем. Именно такие учетные данные не следует делегировать автономному процессу.

Если Basic-аутентификация неизбежна, создайте отдельную учетную запись для исполнителя. Дайте ей только права, нужные для соответствующего семейства запросов. Не используйте личную или административную учетную запись, а также учетные данные, общие для несвязанных автоматизаций. Сервисная идентичность позволяет отзывать доступ и расследовать инциденты, не блокируя человека и не ломая все задания сразу.

Отдельно продумайте кодировку символов. RFC 7617 описывает проблему совместимости, связанную с набором символов имени пользователя и пароля, и позволяет серверам объявлять поддержку UTF-8. Если провайдер принимает только обычные значения ASCII, храните машинные учетные данные в этом диапазоне. Не придумывайте собственный шаг кодирования в промпте агента: так появляется еще одно непоследовательное место, где секрет может быть преобразован и записан в журнал.

Исполнитель запроса должен сам формировать Basic-заголовок из защищенных полей. Агент может выбрать одобренную операцию и передать несекретные параметры. Он не должен формировать значение Base64 и никогда не должен видеть расшифрованные учетные данные в сообщении об ошибке. Безопасная ошибка сообщает, что аутентификация для выбранной ссылки на учетные данные не прошла. Она не повторяет заголовок и не подсказывает агенту, какая часть пароля совпала.

Пользовательские заголовки требуют точного соблюдения семантики провайдера

Пользовательский заголовок аутентификации безопасен ровно настолько, насколько безопасны документированные правила проверки API и обращение с его значением. Распространенные примеры: X-API-Key, Api-Key или заголовок конкретного провайдера. Одни провайдеры ожидают статический API-ключ. Другие требуют подписанный запрос с временной меткой, nonce, каноническим путем и дайджестом тела. Если считать все пользовательские заголовки взаимозаменяемыми, можно сломать аутентификацию и, что еще хуже, случайно расширить места отправки учетных данных.

Во-первых, точно следуйте спецификации провайдера. Имена заголовков в HTTP нечувствительны к регистру, но значения заголовков и входные данные для подписи могут зависеть от него. Схема подписи может требовать определенного порядка канонизации, точных байтов тела и ограниченного временного окна. Если исполнитель разбирает JSON, а затем сериализует его перед подписью, он может получить визуально корректный JSON с другой последовательностью байтов. Провайдер отклонит запрос, а люди часто отвечают отключением проверки подписи или добавлением слишком широких повторных попыток. Исправляйте обработку байтов, а не проверку.

Во-вторых, отличайте заголовок аутентификации от заголовка, который идентифицирует клиента. User-Agent, идентификаторы запросов и идентификаторы приложения помогают провайдеру наблюдать за трафиком, но обычно не подтверждают полномочия. В свою очередь, заголовок X-API-Key может быть так же пригоден для повторного использования, как Authorization: Bearer. Не оценивайте чувствительность заголовка по наличию слова authorization в его названии.

В-третьих, не позволяйте агенту внедрять произвольные заголовки. У агента не должно быть свободной карты исходящих заголовков, если защищенный исполнитель также добавляет учетные данные. Такая карта позволяет добавить второй заголовок Authorization, переопределить ожидаемый тип содержимого, прикрепить неодобренный заголовок идентичности или повлиять на downstream-прокси так, что проверяющий этого не увидит.

Используйте контракт запроса с именованными типизированными полями. Например:

{
  "credential_ref": "release-service",
  "method": "POST",
  "url": "https://api.example.test/v1/projects/alpha/releases",
  "headers": {
    "accept": "application/json"
  },
  "body": {
    "version": "2025.06.0",
    "notes": "Fix parser crash on empty input"
  }
}

Именно исполнитель, а не агент, сопоставляет credential_ref с пользовательским заголовком или процедурой подписи провайдера. Он должен отклонять попытки передать authorization, cookie, заголовок учетных данных провайдера, host или дубликаты этих имен. Исполнитель также должен сам управлять Content-Length, поскольку HTTP-клиент обязан вычислить его по итоговым байтам.

К результату, который показывается агенту, нужен такой же строгий подход. HTTP-ответ может содержать Set-Cookie, диагностические сведения или отраженные детали запроса. Возвращайте статус, выбранные безопасные заголовки ответа и тело, необходимое для задачи. Если операторам нужны исходные заголовки и трассировки, храните их в защищенном хранилище аудита.

Выберите требуемую провайдером схему и ограничьте масштаб ущерба

Для стороннего API вы редко выбираете схему аутентификации. Ее уже выбрал провайдер. Зато вы можете решить, будут ли учетные данные широкими или узкими, где они будут храниться, какие запросы смогут их использовать и что произойдет при странном поведении агента.

При проектировании границы используйте это сравнение:

Для подписанных запросов нужна важная оговорка. Временная метка и nonce могут уменьшить риск простого повторного использования на границе API, но не делают секрет подписи безопасным для контекста агента. Агент, получивший секрет, сможет подписать новый вредоносный запрос. Если реализация подписи принимает от агента произвольные метод, хост, путь и тело, она добросовестно подпишет действия, которые вы не собирались разрешать.

Область действия должна соответствовать текущей операции, а не гипотетическому будущему использованию. Агенту для публикации релизов может быть нужно право создавать релиз в одном проекте. Ему не нужны права удалять проекты, менять платежные настройки, читать все артефакты или приглашать пользователей. Если провайдер не умеет выдавать достаточно ограниченные учетные данные, поставьте перед его API более узкий контролируемый вами сервис или сохраните подтверждение человека для опасных вызовов.

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

Посредничество не дает секретам попасть в контекст агента

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

В небезопасном варианте инструмент получает токен и передает его агенту, например через переменную окружения, подстановку или «временные» учетные данные. Следующее действие агента отправляет запрос. Токен уже пересек границу и попал в систему, предназначенную для анализа, преобразования и повторения текста.

В посредническом варианте агент отправляет исполнителю структурированный запрос. Исполнитель проверяет запрос на соответствие разрешенной форме, получает выбранные учетные данные из защищенного хранилища, подставляет правильные данные аутентификации, отправляет запрос, записывает действие и возвращает ограниченный результат. Агент не получает значение секрета, его закодированную форму или команду оболочки с ним.

Это различие меняет и реагирование на инциденты. Если вы подозреваете, что сессия агента пошла не так, можно остановить ее способность запрашивать действия, не меняя немедленно все учетные данные. Если сами учетные данные могли утечь, их все равно нужно заменить. Отзыв сессии и замена учетных данных решают разные задачи, и команды теряют время, когда воспринимают их как одну и ту же кнопку.

Практичный исполнитель по умолчанию должен отклонять несколько форм запросов:

• Абсолютные URL, указывающие на неодобренный источник, включая похожие поддомены.
• Запросы с пользовательскими заголовками Authorization, Cookie, прокси или заголовками, связанными с учетными данными.
• Перенаправления, которые могут перенести аутентифицированный запрос к другому источнику.
• Методы, не предусмотренные назначением учетных данных, особенно разрушающие методы.
• Тела, превышающие ожидаемый размер или не соответствующие ожидаемому формату конечной точки.

Sallyport использует эту модель хранения на macOS: его зашифрованное хранилище содержит API- и SSH-учетные данные, а MCP-агент просит приложение выполнить HTTP-вызов, не получая значения учетных данных.

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

Граница запроса должна охватывать перенаправления, DNS и ответы

Одного одобрения https://api.example.test недостаточно, потому что аутентифицированный запрос содержит больше, чем имя хоста. Исполнитель должен контролировать каждое место, где агент может изменить фактическое назначение или смысл запроса.

Начните с точного источника: схемы, имени хоста и порта. Для обычных интернет-учетных данных API требуйте HTTPS. RFC 9110 определяет правила цели запроса и полномочий HTTP, но прикладной код все равно должен применять собственные правила назначения. Не одобряйте хосты только по суффиксу. Проверка вроде «имя хоста заканчивается на example.test» может принять notexample.test, а свободная проверка подстроки еще хуже. Сравнивайте разобранные имена хостов с точным списком разрешений или с тщательно спроектированным правилом для поддоменов.

Затем ограничьте методы и пути. Если агент должен создавать релизы, разрешите точное семейство путей POST, которое ему нужно. Не добавляйте DELETE, потому что он может пригодиться для очистки. Не разрешайте произвольные версионированные пути, не решив, может ли следующая версия API вести себя иначе. Важна и нормализация пути. Разберите URL до сравнения и отклоняйте неожиданные кодировки, сегменты с точками или повторяющиеся разделители, если код сопоставления не обрабатывает их предсказуемо.

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

DNS создает вторую проверку назначения. Доверенный хост может разрешаться в разные адреса, а имена внутренних систем могут указывать на чувствительные сети. Если исполнитель работает на ноутбуке разработчика, произвольный исходящий HTTP может стать маршрутом к локальным административным сервисам или конечным точкам метаданных облака. Ограничивайте одобренные источники до подключения, не принимайте настройки прокси от агента и не позволяйте ему выбирать сетевой интерфейс или резолвер.

Наконец, ограничьте размер ответа и отфильтруйте его. Агенту не нужна загрузка размером в несколько мегабайт, чтобы узнать об успешном создании релиза. Большие тела расходуют контекст и могут переносить в рассуждения агента инструкции, скопированные из ненадежного сервиса. По возможности возвращайте только поля, нужные для следующего действия. В контракте инструмента помечайте удаленный текст как данные и никогда не позволяйте содержимому ответа менять правила авторизации исполнителя.

Подтверждение должно называть процесс и конкретное действие

Кнопка подтверждения полезна только тогда, когда дает человеку достаточно информации для решения. Формулировка «Разрешить агенту доступ к API» скрывает общее разрешение за видом запроса. Она усиливает усталость от подтверждений, потому что человек не видит, какой локальный процесс обратился, какие учетные данные он хочет использовать и что именно отправит.

Идентифицируйте вызывающий процесс так, чтобы оператор мог его узнать. В macOS полномочия подписи кода часто полезнее изменяемого имени процесса. Процесс с именем agent может быть легитимным инструментом разработчика или посторонним бинарным файлом с тем же именем. Цепочка процессов, путь к исполняемому файлу и сведения о подписи дают более надежные признаки, хотя ни один из них не заменяет ограниченный запрос действия.

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

Не заставляйте человека при каждом вызове изучать плотный необработанный дамп HTTP. После третьего прерывания его начнут подтверждать не читая. Показывайте краткое описание действия: сервисную идентичность, метод, назначение, путь, значимые поля тела и побочный эффект, указанный API. Подробности исходного запроса сохраняйте в записи аудита для последующего расследования.

Также разделяйте разрешение начать сессию и разрешение сохранять ее активной. Если процесс агента завершился, новый процесс не должен наследовать разрешение только потому, что у него то же имя. После отзыва сессии пользователем исполнитель должен немедленно перестать принимать от нее вызовы. Надпись «отозвано» в интерфейсе, пока уже авторизованный клиент продолжает отправлять запросы, хуже полного отсутствия функции отзыва, потому что создает ложную уверенность.

Записи аудита должны показывать, что произошло после завершения агента

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

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

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

Храните записи аудита отдельно от обычного рабочего контекста агента. Агент может получить сводку вроде 201 Created, release id r-4821. Оператору может понадобиться более подробная запись с путем и метаданными решения. Ни одна из сторон не должна получать исходный заголовок авторизации только потому, что ведется журнал.

В Sallyport журналы Sessions и Activity строятся на основе зашифрованного журнала аудита с цепочкой хешей, а sp audit verify позволяет офлайн проверить эту цепочку без разблокировки хранилища. Для проверки это разумная архитектура, поскольку она не требует раскрывать учетные данные, которыми были авторизованы вызовы.

Проверяйте сценарии ошибок до выдачи доступа к рабочей среде

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

Используйте такую последовательность тестов:

1. Запросите одобренную конечную точку GET и убедитесь, что агент получает ожидаемое тело, но не заголовок с учетными данными.
2. Передайте от агента заголовок Authorization и убедитесь, что исполнитель отклоняет его, а не молча объединяет или заменяет заголовки.
3. Измените URL на неодобренный хост и на обманчиво похожее имя, затем убедитесь, что оба запроса отклоняются до любого сетевого вызова.
4. Верните от тестового API ответ 302 на другой источник и убедитесь, что исполнитель останавливается, а не пересылает аутентификацию.
5. Отзовите сессию агента во время выполнения и убедитесь, что последующие вызовы завершаются ошибкой, а проверка аудита по-прежнему проходит.

После теста проверьте окружение процессов, временные каталоги, историю оболочки, созданные файлы, отчеты о сбоях и тестовые журналы. Выполните поиск по известной строке тестовых учетных данных. Такая проверка выявляет удивительное количество утечек в скриптах-обертках и режимах отладки, которые тесты на уровне запросов не замечают.

Проверяйте и ошибки провайдера. API может вернуть тело с отраженным содержимым неверного заголовка, идентификатором трассировки или советом повторить запрос к другой конечной точке. Убедитесь, что фильтр результата не передает агенту данные, похожие на учетные, а логика повторных попыток не превращает один отклоненный запрос в поток попыток. Ограничивайте повторы ошибками, для которых документация API считает их уместными, и сохраняйте метод и назначение неизменными.

Первые производственные учетные данные должны быть настолько узкими, чтобы провал теста был неприятностью, а не катастрофой. Если команда не может точно объяснить, какие формы запросов она разрешает и как отозвать активный запуск агента, учетные данные все еще слишком широки для автономного использования.