Что такое AdmissionController в Harness и зачем он нужен?

Краткий тезис

AdmissionController в платформе Harness — это компонент инфраструктурного слоя (harness-one/infra), который перехватывает запросы агента на выполнение действий (tool calls) до их фактического исполнения и решает, разрешить или заблокировать действие на основе заданных политик. Он действует как guardrail (ограничитель) для безопасности: проверяет, имеет ли агент с текущими правами и в данном контексте право вызывать конкретный инструмент с конкретными аргументами. Без AdmissionController агент мог бы выполнить опасные операции (удалить файлы, отправить письмо от чужого имени), даже если модель «знает», что это плохо.

1. Термин: AdmissionController (контроллер допуска)

Термин заимствован из Kubernetes, где Admission Controller — это программный модуль, который перехватывает запросы к API-серверу (например, создание Pod'а) после аутентификации и авторизации, но до сохранения объекта в etcd. Он может модифицировать запрос (mutating) или отклонить его (validating). В Harness концепция аналогична, но применяется не к Pod'ам, а к tool calls (вызовам инструментов) агента.

Основные характеристики

• Работает синхронно — задерживает выполнение tool call'а до вынесения вердикта.
• Оценивает запрос по политикам (policy) — набору правил.
• Возвращает allow/deny (разрешить/запретить) и опционально — модифицированный запрос (например, обрезать слишком длинный текст).

2. Контекст: Harness и Agentic RAG

Harness — это платформа для оркестрации AI-агентов, включающая компоненты для построения agentic RAG (Retrieval-Augmented Generation с автономными агентами). В типичной архитектуре:

• Агент (LLM + loop) получает задачу пользователя.
• Агент решает, какие инструменты (tools) вызвать — например, поиск в базе знаний, выполнение SQL-запроса, отправка email.
• Tool call'ы выполняются через среду выполнения (runtime).
• AdmissionController встраивается между агентом и средой выполнения, проверяя каждый вызов на соответствие правилам безопасности и доступа.

Таким образом, AdmissionController — это не часть самого LLM, а часть инфраструктуры безопасности вокруг агента.

3. Зачем нужен AdmissionController: три ключевые причины

3.1 Безопасность (Safety)

Агент, даже хорошо обученный, может ошибиться или быть скомпрометирован (атака indirect prompt injection). AdmissionController предотвращает:

• Вызов деструктивных инструментов (удаление данных, изменение конфигурации).
• Передачу конфиденциальной информации во внешние API.
• Выполнение действий с недопустимыми аргументами (например, sql injection через tool call).

3.2 Соответствие политикам (Compliance)

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

3.3 Контроль доступа (RBAC)

Даже если агент действует от имени пользователя с определёнными правами, AdmissionController проверяет, что запрошенное действие входит в его scope. Например: «агент от имени менеджера может читать отчёты, но не может удалять проекты».

4. Как работает AdmissionController в Harness: пошаговый pipeline

1. Агент генерирует tool call — например, send_email(to="boss@company.com", body="...", attachments=["/etc/passwd"]).
2. Запрос перехватывается AdmissionController (через middleware-цепочку или webhook).
3. Контроллер запускает оценку политики (policy evaluation):
   • Извлекает identity агента/пользователя (токен, сессия).
   • Извлекает контекст (время, окружение, тип запроса).
   • Проверяет правила (policy as code) — например, на языке Rego (OPA) или в формате YAML.
4. Вердикт:
   • allow — запрос передаётся исполнителю.
   • deny — запрос блокируется, агенту возвращается ошибка с объяснением.
   • mutate (опционально) — изменение аргументов (например, удаление опасного attachment'а) и затем allow.
5. Если deny, Harness логирует событие, может отправить алерт или запросить подтверждение у человека (human-in-the-loop).

5. Политики: примеры правил

Политики определяются администраторами в коде (policy-as-code). Ниже — упрощённые примеры в псевдо-YAML (реальный формат зависит от реализации — OPA, Kyverno и т.д.).

# policy_example.yaml
rules:
  - name: "no-send-to-external"
    description: "Запретить отправку писем на внешние домены"
    tool: "send_email"
    condition:
      all:
        - param: "to"
          pattern: "!.*@external.com$"
    action: deny
    reason: "Отправка на внешние адреса запрещена политикой безопасности"

  - name: "max-batch-delete"
    description: "Не более 10 записей за один delete"
    tool: "delete_records"
    condition:
      all:
        - param: "ids"
          length: "<=10"
    action: deny
    reason: "Массовое удаление более 10 записей запрещено без подтверждения"

Возможны также динамические политики, обращающиеся к внешним API (например, проверка баланса счета перед оплатой).

6. Сравнение с аналогичными механизмами

Harness-контроллер — это guardrail для действий, а не для текста, что принципиально отличает его от guardrails для LLM.

7. Реализация в Harness: технические детали

В архитектуре Harness AdmissionController — это микросервис (обычно в harness-one/infra), который подписан на события из event bus или вызывается через gRPC webhook из рантайма агента. Типовой стек:

• Policy engine – может быть встроенный (на основе Rego/OPA) или подключаемый (например, AWS Cedar).
• Decision cache – кэширование результатов для однотипных запросов (снижение latency).
• Audit log – все решения (allow/deny) записываются в централизованное хранилище для ретроспективы.
• Hot reload – политики обновляются без перезапуска сервиса.

# Пример псевдокода контроллера
class AdmissionController:
    def __init__(self, policy_engine):
        self.policy_engine = policy_engine

    def admit(self, tool_call, identity, context):
        # собираем факты
        facts = {
            "tool": tool_call.name,
            "params": tool_call.params,
            "user": identity.user_id,
            "role": identity.role,
            "time": context.time,
            "env": context.environment
        }
        decision = self.policy_engine.evaluate(facts)
        if decision == "deny":
            raise AdmissionError(decision.reason)
        return tool_call  # или модифицированная версия

8. Преимущества и ограничения

Плюсы

• Безопасность «по умолчанию»: все действия проходят проверку.
• Централизованное управление: политики в одном месте, легко менять.
• Аудит: полная запись всех решений для compliance.
• Гибкость: можно писать правила любой сложности (вплоть до вызова внешних сервисов).

Минусы

• Latency: каждый tool call добавляет RTT до AdmissionController (обычно <50ms, но для высоконагруженных систем критично).
• Сложность настройки: нужно квалифицированно писать политики (особенно на Rego).
• Риск блокировки легитимных действий: плохо написанная политика может парализовать работу агента.

9. Связь с компонентами Agentic RAG

AdmissionController не изолирован — он взаимодействует с другими элементами архитектуры:

• Tool Registry – реестр доступных инструментов; AdmissionController использует его метаданные (например, какие параметры обязательны).
• Identity Provider – получает информацию о пользователе/агенте.
• Agent Loop – получает обратную связь (error) при отклонении.
• Observability – метрики (число allow/deny, задержки) экспортируются в Prometheus.

10. Пет-проект для закрепления

Задача написать симулятор AdmissionController для простого агента с двумя инструментами: read_file и delete_file.

Инструменты Python, Flask/FastAPI (симуляция контроллера), простая база политик в YAML.

Шаги:

1. Создать Flask-сервер с эндпоинтом /admit, который принимает JSON с полями tool, params, user, role.
2. Загрузить политику из YAML: «пользователи с ролью guest не могут вызывать delete_file», «параметр path не должен содержать ..».
3. Написать простого агента (скрипт), который генерирует случайные tool call'ы, отправляет их на /admit и выводит результат.
4. Добавить кэширование решения для повторяющихся вызовов (словарь).
5. Собрать метрики: число запросов, % deny.

Ожидаемый результат работающий микросервис, который блокирует опасные вызовы, и агент, который корректно обрабатывает отказы (повтор с другим действием или запрос пользователю).

Расширение подключить OPA в Docker, написать политику на Rego, интегрировать с сервисом.

11. Связь с другими вопросами

Навигация

• Предыдущий: 746
• Следующий: 748
• Индекс: 00. Индекс разборов