Как собрать безопасную обвязку для агентных систем

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

Такую обвязку удобно рассматривать как Enterprise AI Harness — runtime и набор границ вокруг агента. Для self-hosted сценария на Kubernetes полезна модель из четырёх слоёв: Input, Agent Loop, Execution, Identity/Policy/Audit. Она помогает разложить систему на зоны ответственности и выбрать компоненты так, чтобы их можно было менять без пересборки всей архитектуры.

Зачем нужен harness

Одиночный агент часто выглядит как функция: пользователь отправляет текст, приложение добавляет system prompt, модель возвращает ответ или вызывает инструмент. В корпоративной среде эта схема быстро становится хрупкой. Запросы приходят из разных каналов, у пользователей разные роли, действия агента затрагивают код, API, базы данных, тикеты и пайплайны. Для каждого шага нужны правила доступа и следы для расследования инцидентов.

Harness закрывает именно эту область. Он принимает события, поддерживает stateful-сессии, связывает агента с инструментами, передаёт identity-контекст, ограничивает capabilities и пишет аудит. Важный архитектурный фокус здесь расположен на границах между слоями: где заканчивается runtime агента, где начинается исполнение, как проходят токены, где проверяются политики и каким образом изолируются tenant-данные.

Четыре слоя архитектуры

Первый слой — Input. Через него в систему попадает пользовательский, агентный и событийный трафик. Человек может работать через браузер и SSO, сервисы — через webhook, другие агенты — через A2A и JWT. У этих потоков разные требования к identity и policy, поэтому входной слой должен разделять каналы с самого начала.

Второй слой — Agent Loop. Здесь агент превращает входное событие в последовательность действий: хранит состояние, выбирает следующий шаг, делегирует подзадачи, ждёт проверки человека и обновляет память. В этом слое живут ReAct-цикл, сессии, роли агентов и логика переходов между состояниями.

Третий слой — Execution. Он отвечает за управляемый доступ к внешним возможностям: MCP-инструментам, workflow, LLM-шлюзам, backend API и файловым операциям. Агент получает capabilities через контролируемый путь, без прямого полного доступа к инфраструктуре. Это позволяет задать scope, approval, TTL для учётных данных и сетевые ограничения.

Четвёртый слой — Identity, Policy & Audit. Он проходит через всю систему и отвечает на базовые вопросы: кто инициировал действие, что ему разрешено, какой агент выполнил шаг, какой результат получился и какие проверки прошли. Без этого слоя агентная платформа остаётся непрозрачной для эксплуатации и безопасности.

Компоненты для Kubernetes-сборки

Входной контур можно построить на Traefik и oauth2-proxy для browser UI, а для machine traffic использовать webhooks в n8n или аналогичном workflow-движке. Важная задача входа — превратить произвольное сообщение в структурированный task с tenant, ролями, scope и критериями завершения.

Agent Loop может опираться на kagent для lifecycle агентных CRD, A2A, human-in-the-loop и memory API. Для сценариев, где нужна явная графовая логика, подходит LangGraph: он описывает переходы между состояниями, роли исполнителей и условия завершения. Такой слой удобен для задач вроде «проанализировать требование, внести diff, запустить проверки, отправить результат на review».

Execution-слой собирается из MCP-серверов, per-tenant workflow и model gateway. FastMCP-поды дают инструменты как Kubernetes-ресурсы. n8n может выступать integration orchestrator и MCP endpoint. LiteLLM или RemoteLLM закрывают маршрутизацию запросов к моделям и абстракцию над провайдерами. В этой части особенно важно разделять capability: один агент может читать репозиторий, другой запускать тесты, третий открывать pull request.

Identity и policy можно связать через Keycloak, agentgateway, Vault или OpenBao, External Secrets Operator, OpenTelemetry, Grafana и Postgres. Keycloak выдаёт OIDC/JWT, группы и роли. Agentgateway валидирует токены, применяет CEL-политики, добавляет trusted headers и ограничивает rate limit. Vault или OpenBao выдают короткоживущие секреты. OTEL-трейсы и audit events фиксируют цепочку действий.

Изоляция tenant-данных

Multi-tenancy в такой схеме проходит через несколько уровней. Platform-данные можно разделять через RLS в PostgreSQL. Runtime агентов — через namespace-per-tenant и NetworkPolicy. Состояние сессий и trusted context — через заголовки, которые добавляет только доверенный gateway. Секреты — через отдельные пути в Vault для каждого tenant.

Такой набор ограничений снижает риск бокового перемещения между арендаторами и упрощает анализ прав. Если агент запускается в pod одного tenant, он видит только свой runtime-контекст, получает scoped credentials и обращается к инструментам через policy boundary. Для homelab это тоже полезно: даже небольшая self-hosted платформа выигрывает от понятного разделения окружений, секретов и журналов.

Skills и tools живут на разных уровнях

Отдельного внимания заслуживает различие между skills и tools. Skill можно рассматривать как pod-local capability injection: OCI-образ со SKILL.md и скриптами монтируется в pod агента при старте. В prompt попадают метаданные, полный файл skill подгружается при обращении к возможности. Такой механизм расширяет самого агента и связан с lifecycle образа.

Tools относятся к runtime-сети. Это MCP-серверы, workflow endpoints, API и другие внешние возможности. Доступ к ним проходит через Execution-слой и политики. Разделение помогает держать локальные знания агента отдельно от операций, которые реально меняют внешние системы.

Пример рабочего маршрута

Представим задачу: добавить валидацию в API-метод, обновить тесты и подготовить diff для review. Запрос приходит из Telegram, Jira или web UI. Входной слой получает JWT, передаёт его через gateway, проверяет policy и формирует структурированный task: инициатор, tenant, scope, критерии завершения.

Agent Loop поднимает сессию и распределяет работу. Analyst уточняет требования и формирует план, implementer меняет код в разрешённой области, reviewer выполняет независимую проверку. Каждый шаг записывается как событие, а состояние задачи обновляется после действий агентов.

Execution-слой выдаёт каждому агенту только нужные возможности. Implementer получает доступ к рабочему дереву и тестовой команде, reviewer — к diff и результатам проверок, workflow — к системе задач. Если требуется секрет, secret broker выдаёт short-lived credentials с TTL и последующим отзывом.

Identity, Policy & Audit сопровождает весь маршрут: JWT claims связывают действие с пользователем, CEL-политики фиксируют разрешение, OTEL-трейсы показывают ход выполнения, audit events сохраняют результат. При сбое становится понятно, на каком этапе policy остановила действие или какой агент выполнил конкретную операцию.

Практический вывод

Enterprise AI Harness стоит проектировать вокруг границ ответственности. Input нормализует трафик и identity, Agent Loop управляет состоянием и ролями, Execution даёт контролируемые capabilities, Identity/Policy/Audit удерживает безопасность и наблюдаемость. Kubernetes добавляет среду развёртывания: namespaces, NetworkPolicy, Helm, CRD и привычную модель эксплуатации.

Главная ценность такой схемы — заменяемость компонентов. Сегодня это может быть kagent, FastMCP, Keycloak, agentgateway и Vault; завтра часть стека изменится. Если границы между слоями проведены явно, команда сможет менять инструменты, сохраняя общий runtime-подход к агентам в production.