Skip to main content
Пользовательские политики превращают паттерн сбоя из ваших трассировок или аудитов в решение, которое выполняется во время работы агента. Политика может разрешить действие, предоставить агенту рекомендации или заблокировать действие до того, как оно вызовет новый инцидент. Используйте пользовательскую политику, когда поведение зависит от ваших инструментов, путей, команд, окружений или правил эксплуатации. Сначала проверьте встроенный каталог политик, чтобы не переделывать существующий контроль.

Создание пользовательской политики

  1. Перейдите в Admin → policy editor, выберите New policy и опишите сбой, который вы хотите предотвратить.
  2. Добавьте источник политики, затем протестируйте ожидаемые совпадения и безопасные несовпадения в редакторе. Разрешите все ошибки валидации.
  3. Сохраните черновик и выберите Publish version, чтобы создать неизменяемую версию.
  4. Перейдите в Admin → enforcement, разверните версию на тестовой машине в режиме observe, и проверьте её решения в разделе Observe → policy перед тем, как его применять. Редактор политик, используемый для создания и публикации пользовательской политики.

Начните с узкого правила

Эта политика блокирует деструктивные команды Kubernetes только когда команда нацелена на production. Всё, что находится вне этого точного паттерна сбоя, возвращает allow().
Хорошие политики достаточно узки, чтобы их можно было объяснить в одном предложении. Сопоставляйте наблюдаемое действие — не намерение, которое вы надеялись найти у агента — и возвращайте allow() как только правило перестанет применяться.

Выберите решение

Напишите причину для агента, который должен восстановиться. Объясните, что было обнаружено и что он должен делать вместо этого.
Не используйте instruct() для границы безопасности. Доставка рекомендаций варьируется в зависимости от harness агента. Используйте deny(), когда действие должно быть предотвращено.

Объект политики

Фильтруйте инструменты внутри fn. match.toolNames не является частью публичного типа пользовательской политики.

Контекст политики

Каждая политика получает PolicyContext. Относитесь к каждому опциональному значению как к действительно опциональному. Версии агентов и типы событий не предоставляют одинаковые поля.

Типичные входные данные инструментов

Failproof AI нормализует общие инструменты на поддерживаемых harnesses, поэтому политика обычно может использовать одну форму ввода. Используйте защитное приведение типов, так как значения входных данных инструмента типизированы как unknown:

Выберите событие

Доступность событий и поведение блокировки зависят от harness агента. См. Agent harnesses перед тем, как полагаться на событие во всей смешанной флоте.
SessionStart, SessionEnd, UserPromptSubmit, PreToolUse, PermissionRequest, PermissionDenied, PostToolUse, PostToolUseFailure, Notification, SubagentStart, SubagentStop, TaskCreated, TaskCompleted, Stop, StopFailure, TeammateIdle, InstructionsLoaded, ConfigChange, CwdChanged, FileChanged, WorktreeCreate, WorktreeRemove, PreCompact, PostCompact, Elicitation, ElicitationResult, UserPromptExpansion, PostToolBatch и Setup.

Создание типичных паттернов политик

Блокировка записей в защищённые пути

Предоставление рекомендаций без блокировки

Ограничение завершения сессии

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

Загрузка файлов политик

Файлы соглашений

Файлы соглашений загружаются автоматически:
  • Как проектные, так и пользовательские каталоги политик загружаются.
  • Файлы загружаются в алфавитном порядке в каждом каталоге.
  • Файл должен заканчиваться на policies.js, policies.mjs или policies.ts.
  • Поддерживаются несколько вызовов customPolicies.add() в одном файле.
  • Поддерживаются относительные импорты из локальных модулей.
  • Проектные политики могут быть фиксированы, чтобы одни и те же правила следовали репозиторию.

Явные файлы

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

Валидация и тестирование

Валидация выполняет модуль через production loader и подтверждает, что он регистрирует хотя бы одну политику.
Валидация отлавливает отсутствующие файлы, синтаксические ошибки, неразрешённые импорты, исключения на верхнем уровне и таймауты загрузки модулей. Она не доказывает, что логика сопоставления верна. Протестируйте хотя бы эти случаи:
  • Одно действие, которое должно соответствовать и производить предусмотренную причину политики.
  • Одно близлежащее, но безопасное действие, которое должно возвращать allow().
  • Отсутствующие или неправильные поля инструмента.
  • Альтернативные синтаксисы команд, пути, кавычки, регистр и пробелы.
  • Недоступная подпрограмма или зависимость сети.
Назначьте результат своей пользовательской политике в разделе Observe → policy. Заблокированный тест недостаточен, если другая встроенная политика приняла решение.

Поведение во время выполнения

  • Встроенные политики оцениваются перед пользовательскими политиками.
  • Первый deny останавливает дальнейшую оценку политики.
  • Несколько результатов instruct могут быть объединены, когда ни одна политика не отклоняет событие.
  • Функция политики имеет крайний срок выполнения в 10 секунд.
  • Выброшенное исключение или таймаут регистрируется и обрабатывается как allow().
  • Файл конвенции, который не загружается, пропускается; другие пользовательские файлы и встроенные политики продолжают работу.
  • Загрузка модуля на верхнем уровне также имеет крайний срок в 10 секунд.
  • Облачный режим observe запускает политику, но записывает решение, отличное от allow, без применения его.
Сохраняйте модули политик детерминированными и быстрыми. Избегайте сетевых вызовов на верхнем уровне или запуска сервера. Ограничивайте работу внутри fn, ловите сбои зависимостей и осознанно выбирайте, должен ли этот сбой разрешить или отклонить операцию.

Экспортируемый API

TypeScript экспортирует PolicyContext, PolicyResult, CustomHook, PolicyDecision и PolicyFunction.

Развертывание пользовательских политик

Опубликуйте версию, разверните её в режиме observe, проверьте решения и перейдите к применению.