AegisKernel описывает защитный слой между инструментами AI-агента и потенциально опасными действиями. В README авторы проекта предлагают маркировать внешние данные как недоверенные и проверять разрешения перед операциями вроде запуска команд, записи файлов и изменения базы данных. Исследовательский вопрос здесь практический: насколько убедительны четыре опубликованных сценария CrewAI и что ещё нужно проверить перед использованием такого перехватчика в реальной системе?
Как авторы описывают схему защиты
По описанию AegisKernel, внешние строки оборачиваются в TaintedString. Авторы проекта утверждают, что метка недоверенных данных сохраняется при срезах, конкатенации, переводе регистра и форматировании. Отдельная матрица разрешений должна ограничивать операции с повышенными полномочиями; среди примеров README называет SHELL_EXEC, FILE_WRITE и DATABASE_MODIFY.
Логика подхода понятна: содержимое, пришедшее извне, не становится безопасным только потому, что его обработал агент. Опасным считается не только текст запроса, но и его попадание в аргумент инструмента, которому разрешено выполнять чувствительную операцию. Однако реальный охват зависит от того, какие входы получают метку, как она проходит через конкретные библиотеки и где именно проверяется разрешение. README описывает заявленное поведение, но доступные материалы не содержат независимого анализа реализации этих путей. README AegisKernel.
Что именно показаны четыре сценария CrewAI
Авторы AegisKernel в README сообщают о сравнении стандартной конфигурации CrewAI с вариантом, защищённым их инструментом. В таблице перечислены четыре сценария: destructive root injection, утечка .env через path traversal, database drop injection и command chaining hijack.
| Сценарий | Стандартный CrewAI по README | С AegisKernel по README |
|---|---|---|
| Destructive root injection | Атака отмечена как успешная | Заблокирована, 0,061 мс |
| Path traversal, попытка утечки .env | Атака отмечена как успешная | Заблокирована, 0,041 мс |
| Database drop injection | Атака отмечена как успешная | Заблокирована, 0,022 мс |
| Command chaining hijack | Атака отмечена как успешная | Заблокирована, 0,016 мс |
Таким образом, опубликованный результат ограничен четырьмя строками таблицы: авторы проекта сообщают о блокировке всех четырёх перечисленных сценариев. В итоговой строке README они называют это «100% IMMUNITY». В данном контексте знаменатель — четыре сценария этой таблицы, а не все возможные атаки, инструменты, модели или настройки. README называет тест «verified reproduction», но доступные материалы не раскрывают подробный протокол, исходные данные и независимое повторение.
Почему эти числа не подтверждают защиту системного уровня
Четыре заявленные блокировки дают основание проверить именно такие сценарии на собственной конфигурации, но не доказывают универсальную защиту. Для более широкого вывода понадобились бы разные модели, инструменты, способы передачи данных, конфигурации разрешений и заранее определённые критерии успешной атаки. Независимых результатов такого тестирования в доступных материалах нет.
README также утверждает, что перехват происходит до системного вызова и защищает на границе syscall. Но таблица с четырьмя атаками не показывает, где физически проходит контроль, какие пути исполнения охвачены и можно ли обойти его через другой инструмент, дочерний процесс или иной обработчик. Поэтому заявление о системной границе остаётся заявлением проекта, а не установленным результатом теста.
С показателями задержки есть внутреннее расхождение. README сообщает о перехвате менее чем за 0,05 мс, итоговая строка содержит порог менее 0,04 мс, а для destructive root injection в таблице указано 0,061 мс. Последнее значение выше обоих сводных порогов. Без методики измерения, описания аппаратной среды и определения того, что включено в замер, эти цифры нельзя использовать как подтверждённую гарантию производительности.
Что проверить перед внедрением
README предлагает подключать защиту к агентам CrewAI или LangChain через protect_agent, а отдельные инструменты — через protect_tool. Такой пример показывает предполагаемый способ интеграции, но сам по себе не подтверждает совместимость с каждым инструментом, адаптером и обработчиком ошибок.
- Составьте список реально необходимых инструментов и выдайте каждому только требуемые разрешения.
- Проверьте, какие внешние данные получают метку недоверенных и сохраняется ли она после всех преобразований, используемых в вашей системе.
- Повторите четыре опубликованных сценария на собственной конфигурации, отдельно проверяя команды, файлы и операции с базой данных.
- Проверьте обходы через другой инструмент, дочерний процесс, альтернативный обработчик или ошибку интеграции.
- Зафиксируйте условия и методику измерения задержки, а затем сравните результат с требованиями вашей системы, не принимая числа README за гарантию.
Практический вывод
AegisKernel предлагает проверяемую гипотезу: маркировка недоверенных данных в сочетании с матрицей разрешений может остановить опасную передачу аргументов в инструменты агента. Авторы проекта сообщают о блокировке четырёх сценариев CrewAI, но эти результаты опубликованы самим проектом, не сопровождаются доступным независимым тестированием и не подтверждают универсальную защиту. Перед использованием перехватчика нужно проверить реальную границу контроля, полноту маркировки, обходы и задержку на собственной конфигурации.
