25 июня 2026 года Grab рассказала о Palana — собственной Kubernetes-native платформе для запуска автономных AI-агентов в изолированной среде. Для тех, кто уже примеряет агентов к разработке, саппорту или внутренней автоматизации, новость важна по простой причине: безопасность AI-агентов перестает быть задачей для промптов и фильтров на входе, а уходит на уровень инфраструктуры.
О платформе Palana сообщает InfoQ. По описанию Grab, команду к разработке подтолкнули эксперименты с Claw и другими агентными фреймворками: быстро выяснилось, что прототипы, собранные вручную под каждый сценарий, не отвечают на базовые вопросы о границах доступа, сетевой изоляции и аудите действий. Если обычный сервис делает примерно то, что в него запрограммировали, то модельный агент живет заметно веселее: сам вызывает инструменты, ходит в API, пишет и читает код, а иногда еще и уверенно ошибается. В такой архитектуре prompt injection, logic hijacking, зависимость от компрометированных пакетов и банальное «слишком усердное выполнение цели» становятся не теоретическим риском, а штатным режимом работы.
Главная ставка Palana — изоляция как единица доверия. Каждый агент получает собственный namespace в Kubernetes, отдельную service account, жесткие настройки Role-Based Access Control и индивидуальные network policies. Идея довольно приземленная, но в этом ее плюс: если один агент или даже целый фреймворк скомпрометирован, проблема не должна перепрыгнуть в соседнюю нагрузку или, что хуже, в сам кластер. Для долгоживущих асинхронных задач Grab добавляет локальное постоянное хранилище, чтобы агент не терял состояние между рестартами контейнера. Это важная деталь: на практике многие агентные сценарии не укладываются в короткий request-response цикл, а значит, вопрос памяти и состояния становится частью эксплуатационной модели, а не удобным бонусом.
Самый показательный кусок архитектуры касается секретов. Grab исходит из довольно трезвого предположения: если агентный runtime скомпрометирован, хранить реальные ключи в переменных окружения или в примонтированных файлах уже поздно и бессмысленно. Поэтому в Palana секреты разделены на две категории. Агент видит только абстрактные, подставные токены, а настоящие учетные данные — например, API-ключи к model gateway или персональные токены для систем контроля версий — остаются в HashiCorp Vault. Когда агент отправляет внешний запрос, промежуточный защищенный прокси перехватывает его, проверяет адрес назначения и только в этот момент подменяет заглушку на реальный секрет. В итоге ключ не попадает ни в окружение контейнера, ни в память исполняемого процесса в явном виде, ни в логи. Для безопасности AI-агентов это, пожалуй, один из самых практичных тезисов всей истории: не доверять рантайму даже тогда, когда сам его и запустил.
Сетевой выход в Palana тоже превращен в контрольную точку, а не в удобный pipe наружу. Весь HTTP- и HTTPS-трафик автоматически уходит через Envoy и внешний сервис авторизации на базе Open Policy Agent. Grab использует схему с MITM-терминацией сертификатов, чтобы расшифровывать трафик на лету, проверять заголовки, валидировать конечные точки и подменять токены там, где это разрешено политиками. Параллельно платформа строит структурированный audit trail. Для корпоративной эксплуатации это почти важнее красивых демо: когда агент написал что-то не туда, дернул лишний API или полез в неожиданный endpoint, команде нужно не гадать по косвенным следам, а видеть маршрут действий внятно и по слоям.
Еще одна здравая мысль Grab: скомпрометированный агент нельзя просить «пожалуйста, завершись». Поэтому операционные предохранители вынесены за пределы исполняемой среды. Если нагрузку нужно остановить, сетевые kill switch работают на уровне network policies из control plane. За остановку простаивающих задач отвечает внешний reaper, который не требует модифицировать код самого агента. Это снова возвращает разговор из области «надеемся, что агент будет послушным» в область нормальной SRE-практики: управление жизненным циклом должно принадлежать платформе, а не приложению, особенно если приложение склонно к импровизации.
С инженерной точки зрения Palana интересна еще и тем, что не пытается изобрести параллельный DevOps-мир специально под AI. Каждый агент в системе описывается как custom resource и обслуживается собственным Kubernetes-оператором, который поднимает namespace, storage, network policies и ingress-маршруты. Для разработчиков сверху дается упрощенный интерфейс и CLI, а для платформенных команд остается стандартный слой Kubernetes, который можно аудитить, обновлять и катить через привычные infrastructure-as-code процессы. Grab прямо говорит о сотнях параллельных агентных нагрузок в production-кластере. Даже если не цепляться к цифре как к маркетинговой метрике, посыл понятен: агентный execution постепенно переходит из песочницы для innovation team в объект серийной эксплуатации.
Для русскоязычной IT-аудитории здесь есть неприятный, но полезный вывод. Если компания всерьез запускает AI-агентов, которые пишут код, ходят в корпоративные API, трогают тикеты, репозитории и внутренние базы знаний, «обернем все в один контейнер и добавим allowlist» уже не выглядит серьезной архитектурой. Безопасность AI-агентов требует отдельной модели идентичности, сети, секретов и внешнего контроля. Иначе любой красивый pilot быстро упирается либо в паранойю службы ИБ, либо в первый же инцидент, после которого проект тихо переименуют из strategic в experimental.
История с Palana хорошо показывает общий сдвиг на рынке: вокруг агентных систем теперь спорят не о том, смогут ли они вызвать инструмент или написать код, а о том, можно ли разрешить им делать это без постоянного страха за кластер, токены и журналы аудита. Похоже, следующая линия конкуренции пройдет не только по качеству моделей и фреймворков, но и по тому, насколько зрелую платформу исполнения компании смогут построить вокруг этого нового класса софта.