AI Web Checkby noviKEY
Меню

Руководство · Стандарт и практики безопасности

Безопасность API для ИИ-агентов: публичное описание без лишних полномочий

Практическая граница между публичным описанием возможностей и защищённым выполнением: HTTPS, безопасные URL, OAuth и области доступа, минимальные полномочия, секреты и запрет слепого вызова операций.

Опубликовано
Обновлено

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

Публичное описание должно быть безопасным само по себе

Документы для ИИ-агентов могут публиковать URL и требования к аутентификации, но не сами учётные данные. Адрес API в well-known-профиле, Agent Card, OpenAPI или декларации MCP должен быть безопасным публичным адресом, а не приватным IP, localhost или URL с логином и паролем.

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

Что проверяет AI Web Check

AI Web Check консервативно проверяет объявленные адреса API: отклоняет приватные и локальные адреса, URL с IP-литералами и встроенными учётными данными, проверяет безопасный сайт назначения и не сохраняет исходные документы, ключи, подписи или секретные значения.

Сервис никогда не оформляет заказ, не проводит оплату, не создаёт A2A-задачи и не вызывает MCP-инструменты. Это принципиальная граница: пассивно проверить публичное описание можно без побочного эффекта, а реальную авторизацию нужно тестировать в отдельной контролируемой среде.

Авторизация: область доступа важнее самого токена

Современные протоколы для агентов используют обычные механизмы безопасности: OAuth, bearer-токены, схемы безопасности и авторизацию на уровне ресурса. Спецификация MCP, например, требует не передавать токен доступа в строке запроса и привязывать токен к целевому ресурсу.

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

Типичные опасные публикации

  • API-ключ или bearer-токен прямо в Agent Card, профиле UCP или URL сервера OpenAPI.
  • Адрес API на 127.0.0.1, в приватной сети RFC1918 или диапазоне локальной связи.
  • Операция, изменяющая состояние, доступна без ограничения областей доступа и серверной проверки владельца ресурса.
  • Один набор учётных данных используется для публичного описания, чтения каталога и финансовых операций.
  • Проверяющий бот «тестирует» безопасность реальным заказом или разрушительным вызовом.

Минимальный безопасный порядок

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

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