Когда твой агент решает, что базу данных пора удалить
Представьте сцену: ваш автономный исследовательский агент, собранный на CrewAI, вдруг получает задание 'очистить систему от мусора'. Или финансовый бот, подключенный к платежному API, решает 'оптимизировать бюджет' самым радикальным способом. Эти кошмарные сценарии - не выдумка. В 2025 году уязвимости через prompt injection стали основной головной болью для разработчиков автономных систем, о чем подробно писалось в разборе Jailbreak SAFi агента.
Проблема в том, что большинство фреймворков вроде LangChain или CrewAI дают агентам доступ ко всем инструментам сразу. Нет механизма, чтобы сказать 'эту функцию можешь использовать только при условии X, а эту - никогда'.
Faramesh - детерминированный гейт для инструментов
Библиотека Faramesh, вышедшая в конце 2025 года, решает эту проблему радикально. Это не просто обертка, а система политик выполнения (execution policies), которая стоит между агентом и его инструментами. Каждый вызов инструмента проходит через 'гейт', который проверяет: можно ли сейчас это выполнить, с какими параметрами и в каком контексте.
1 Что умеет Faramesh на практике?
- Политики на уровне инструментов: Можно запретить агенту использовать инструмент 'delete_database' вообще, или разрешить только в определенных сессиях.
- Валидация аргументов: Проверка, что параметры вызова находятся в допустимых пределах. Например, 'перевести не более 1000 рублей' или 'отправить запрос только к определенным доменам'.
- Контекстно-зависимые правила: Разрешение действий в зависимости от предыдущих шагов агента или внешних условий (например, времени суток).
- Поддержка Model Context Protocol (MCP): Интеграция с новой стандартизированной системой подключения инструментов, которая набирает популярность в 2026 году.
- Аудит и логирование: Детальная запись всех попыток вызова инструментов, включая заблокированные.
Чем Faramesh отличается от встроенных средств защиты?
В LangChain 1.0, о котором мы писали в гайде по middleware, есть система промежуточного ПО. Она хороша для базовой валидации и логирования, но не предлагает такого уровня детализированного контроля. Faramesh же позволяет описать сложные политики в декларативном стиле.
| Подход | Уровень контроля | Сложность настройки |
|---|---|---|
| Встроенный middleware LangChain | Базовый (логирование, модификация запросов) | Низкая |
| Ручная валидация в коде агента | Высокий, но фрагментарный | Очень высокая |
| Faramesh | Детализированный, системный | Средняя (декларативные политики) |
Альтернативы вроде самописных валидаторов раздувают код и усложняют поддержку. Другие фреймворки, например RLM-Toolkit, фокусируются на архитектуре агентов, а не на безопасности исполнения.
Как это выглядит в реальном проекте?
Допустим, у вас есть агент для управления облачной инфраструктурой. Без Faramesh вы даете ему инструменты 'create_server', 'delete_server', 'modify_firewall'. И молитесь, чтобы в промпт не закралась инструкция 'удали все серверы'.
С Faramesh вы определяете политику:
- Инструмент 'delete_server' требует подтверждения от человека (через веб-хук) для любого сервера из продакшен-пула.
- 'modify_firewall' запрещен между 18:00 и 09:00 по местному времени.
- 'create_server' разрешен, но только с тегами 'env:staging' и ограничением по количеству ядер.
Эти правила описываются в YAML или Python-конфигурации и подключаются к агенту за пару строк. Интеграция работает как с классическим LangChain, так и с более современными стеками, например, если вы перешли на Cogitator для TypeScript-агентов.
Важный момент: Faramesh не заменяет защиту на уровне API или базы данных. Это дополнительный слой безопасности, который предотвращает проблему до того, как агент отправит вредоносный запрос во внешний мир.
Кому стоит срочно посмотреть в сторону Faramesh?
Библиотека не для всех. Если ваш агент только читает RSS-ленты и пишет твиты, возможно, это overkill. Но в определенных сценариях она становится критически важной.
Идеальные кандидаты:
- Финансовые и торговые боты, которые взаимодействуют с реальными платежными системами или биржами. Одна ошибка агента - и вы в минусе.
- Администраторы инфраструктуры, управляющие облачными ресурсами через API (AWS, GCP, Kubernetes).
- Корпоративные агенты, имеющие доступ к внутренним базам данных с чувствительной информацией.
- Разработчики, которые упаковывают агентов в продукты для клиентов. Faramesh дает гарантии, которые можно прописать в SLA.
Если вы разворачиваете множество агентов, как в случае с Coreness, централизованная система политик Faramesh упростит управление безопасностью.
Под капотом и что ждет в будущем
Faramesh написан на Python, но авторы заявляют о планах поддержки TypeScript в 2026 году. Архитектура модульная: ядро обработки политик, адаптеры для разных фреймворков (LangChain, CrewAI, LlamaIndex) и система плагинов для кастомных валидаторов.
Самое интересное - научная статья, сопровождающая релиз. Авторы формализуют проблему 'безопасного исполнения инструментов' и предлагают модель, которая, вероятно, станет основой для будущих стандартов. Это тот уровень серьезности, которого не хватало в агентной инженерии как дисциплине.
Прогноз на 2026-2027: инструменты вроде Faramesh перестанут быть опциональными. Крупные облачные провайдеры начнут требовать подобные системы контроля для запуска агентов в своих экосистемах. Безопасность станет не фичей, а обязательным полем в конфигурации.
Так что если вы все еще надеетесь, что ваш агент 'и так не натворит дел', посмотрите на Faramesh. Это страховка от того дня, когда LLM решит проявить инициативу не в том месте. И этот день может быть ближе, чем кажется.
