Fastly представила контрольный слой для ИИ-вызовов и доступа агентов к API

Fastly 21 сентября 2026 года анонсировала AI Runtime Control, AI Firewall и новые возможности API Security. ARC централизует маршрутизацию запросов к моделям, виртуальные ключи, лимиты и учёт токенов; AI Firewall предназначен для защиты от LLM-атак, а API Security — для проверки обращений агентов к корпоративным API. Публичных независимых тестов, цен и российских условий компания не раскрыла.

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

В релизе Fastly от 21 сентября 2026 года компания сообщила о доступности ARC, AI Firewall и новых возможностей API Security. Fastly заявляет, что ARC направляет запросы к публичным и самостоятельно размещённым поставщикам моделей через единый endpoint; виртуальные ключи позволяют не раздавать приложениям исходные ключи провайдеров. В релизе также заявлены наблюдение за расходом токенов, rate limit, бюджетные пороги и резервное переключение провайдера.

AI Firewall, по заявлению поставщика, проверяет промпты прямо в пути запроса и предназначен для снижения риска LLM-атак, включая prompt injection. API Security призван сопоставлять обращения с контрактами API и журналировать либо блокировать некорректные запросы. Это относится не только к автономным агентам, но и к обычному и «агент-поддерживаемому» трафику.

Важная оговорка: Fastly — первоисточник релиза и поставщик продукта. Его утверждения о защитном эффекте, удобстве управления и ожидаемой пользе не являются независимым тестом. Компания не опубликовала в релизе результаты испытаний на prompt injection, долю ложных срабатываний, показатели доступности, клиентские кейсы, методику расчёта экономии или цены.

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

В техническом описании ARC Fastly конкретизирует механику: приложение передаёт запрос ARC, сервис определяет виртуальный ключ и выбранную модель, подставляет учётные данные провайдера, применяет лимиты и записывает данные запроса. Возможна привязка запросов к сессии, если клиент сам передаёт идентификатор. В журнал попадают, в частности, виртуальный ключ, сессия, провайдер, модель, входные и выходные токены, время, текст запроса и ответ.

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

Представим службу поддержки, где бот отвечает по базе знаний, а агент при необходимости создаёт заявку в CRM. Вместо прямых обращений разных команд к нескольким модельным API приложение обращается к ARC. Виртуальный ключ можно выделить для конкретного сценария: например, отдельный для черновиков ответов и отдельный для классификации заявок. Для ключа задаются допустимые модельные цели, лимит запросов или токенов и бюджетное поведение: только уведомить или уведомить и блокировать запросы при достижении порога.

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

На стороне действий агента API Security работает с контрактами API. Полезный прикладной вопрос для владельца процесса: не «может ли агент вызвать CRM», а «какие именно операции и параметры ему разрешены». Контрактная проверка помогает отсечь запросы вне ожидаемой схемы, но сама по себе не доказывает, что разрешённая операция бизнес-корректна. Права, лимиты действий, подтверждения человека и журналы решений всё равно нужно проектировать на уровне приложения и процесса.

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

Независимый контекст здесь важнее рекламных формулировок. NIST AI RMF описывает добровольный подход к встраиванию доверенности и управления рисками в проектирование, применение и оценку ИИ-систем. OWASP GenAI Security Project публикует открытые рекомендации по рискам генеративного ИИ и отдельно подчёркивает роль прозрачности и контроля для доверия к агентам. Эти источники не подтверждают работу продуктов Fastly, но объясняют, почему одних модельных настроек недостаточно для производства.

Для руководителя практический вывод состоит из трёх шагов:

1. Составить реестр агентных сценариев, их моделей, API-инструментов и владельцев бюджета.
2. Разделить ключи по процессам и средам, задать лимиты и заранее решить, что происходит при превышении: уведомление, остановка или эскалация человеку.
3. До масштабирования провести собственный тест: проверить не только блокировку вредных промптов, но и ложные блокировки, утечки в журналах, поведение при failover и корректность разрешённых API-действий.

На уровне архитектуры ARC относится к классу AI gateway / control plane: такие слои объединяют модели, учётные данные, наблюдаемость и правила. Конкурировать здесь нужно не по обещанию «единой точки», а по проверяемым для конкретного контура свойствам: поддерживаемым провайдерам и self-hosted endpoint, типам лимитов, составу и доступу к журналам, региональным условиям, интеграции с IAM/SIEM, задержке, отказоустойчивости и цене.

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

Fastly заявляет, что три возможности уже доступны, однако команда внедрения должна отдельно подтвердить набор функций в своём аккаунте и регионе, статус beta-функций, совместимость с выбранными моделями и политику логирования. На ближайшем пилоте стоит измерять не абстрактную «безопасность ИИ», а долю запросов с корректной атрибуцией, блокировки по лимитам, ложные блокировки, успешность failover и полноту аудита действий агента.

Источники:
1. Fastly — официальный релиз, 21 сентября 2026
2. Fastly — документация AI Runtime Control
3. Fastly — документация мониторинга ARC
4. NIST AI Risk Management Framework
5. OWASP GenAI Security Project

По документации Fastly, ARC — это контрольный слой между приложением и поставщиками LLM. Он направляет запросы через один endpoint, использует виртуальные ключи, применяет заданные ограничения и записывает сведения о маршрутизируемых запросах.

ARC позволяет назначать бюджетные и rate limits и видеть использование, но сам по себе не доказывает снижение расходов. Экономический эффект зависит от правил, поведения приложений, цен провайдеров и результатов собственного измерения.

Нет. Fastly заявляет о снижении риска LLM-атак, но публичных независимых метрик эффективности в изученных материалах нет. Защита должна дополняться ограничением инструментов агента, правами доступа, подтверждениями и тестами.

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