Опубликовано: 15.10.2026 | Источник: Kaspersky Daily

Изоляция ИИ-агентов в дипломе: архитектура «песочницы», политика безопасности и метрики для ВКР

В конце марта 2026 года Касперский опубликовал материал о концепции IronCurtain — открытом прототипе исследователя Нильса Провоса, который предлагает «прокладку безопасности» между автономным ИИ-агентом и системой пользователя. Идея простая: агент работает не в вашей почте и не с вашими ключами напрямую, а из изолированной виртуальной машины, где каждое действие проходит через формализованную политику безопасности. Для выпускника ИТ-направления это не просто новость, а готовый скелет темы ВКР: есть проблема (промпт-инъекции, избыточные права, непредсказуемое поведение LLM), есть референсная архитектура и есть открытое поле для собственной реализации с метриками. Ниже — как превратить этот кейс в защищаемую работу, а не в реферат о «трендах ИИ».

Три темы ВКР, которые вырастают из статьи

Тема 1. «Проектирование изолированной среды для автономных ИИ-агентов на базе контейнерной/виртуальной песочницы»

Актуальность: в статье прямо перечислены инциденты — OpenClaw удалил всю почту хозяйки вопреки инструкции, другой агент предложил фишинговую атаку на собственного пользователя. Это фактологическая база для обоснования проблемы, не требующая домыслов.

Цель: разработать архитектуру изоляции ИИ-агента с внешним модулем проверки политик безопасности.

Задачи:

• проанализировать существующие подходы к изоляции процессов и ИИ-агентов (VM, контейнеры, seccomp, gVisor);
• спроектировать схему «агент → прокси проверки политик → внешний сервис»;
• реализовать прототип на Python/Go с конфигурацией политик в YAML или Rego;
• провести нагрузочное тестирование и замерить задержку на одно решение политики.

Структура: Глава 1 — анализ угроз ИИ-агентов и стандартов (ISO/IEC 27001, OWASP LLM Top 10); Глава 2 — проектирование архитектуры, UML-диаграммы компонентов и последовательностей; Глава 3 — реализация прототипа, тесты, оценка overhead.

Тема 2. «Сравнительный анализ методов противодействия промпт-инъекциям в LLM-агентах»

Актуальность: статья честно признаёт, что IronCurtain не закрывает проблему прямых и косвенных промпт-инъекций — это открытый research gap, идеальное поле для аналитической ВКР.

Цель: классифицировать методы защиты и оценить их применимость к агентным системам.

Задачи: собрать корпус атак (direct/indirect injection); реализовать тестовый стенд; сравнить фильтрацию на входе, «двойную модель», маркировку данных и политики на выходе; сформулировать рекомендации.

Структура: Глава 1 — теория LLM и угроз; Глава 2 — методика оценки и стенд; Глава 3 — эксперименты и статистика успешных/проваленных атак.

Тема 3. «Разработка декларативной политики безопасности для ИИ-ассистента с генерацией из естественного языка»

Актуальность: IronCurtain переводит инструкции на английском в формализованную политику — это отдельная задача NLP + формальные методы, которую можно сузить и защитить как самостоятельную ВКР.

Цель: реализовать модуль преобразования NL-правил в машинно-проверяемую политику и оценить точность трансляции.

Задачи: определить грамматику политики; собрать датасет из 100+ правил; обучить/настроить LLM-парсер; замерить precision/recall на тесте.

Аналитическая глава: как сравнивать решения, а не пересказывать статью

Первая глава ВКР должна превращать статью Касперского в систему координат, а не в цитату. Есть как минимум три оси сравнения:

Обоснование стека — обязательная часть аналитической главы. Обязательно укажите, почему выбор пал на конкретный инструмент (лицензия, поддержка сообществом, зрелость API), а не просто «потому что популярно на Хабре».

Проектная часть: схемы, которые ждёт комиссия

Ссылка на IronCurtain даёт готовый контур для диаграммы компонентов. Минимальный набор:

• Диаграмма развёртывания (UML Deployment): пользовательская сеть, изолированная ВМ с агентом, прокси политик, внешние сервисы (Gmail, календарь, файлохранилище).
• Диаграмма последовательности: «запрос агента → перехват → проверка политики → allow/deny → ответ». Отдельно покажите ветку, когда политика требует подтверждения пользователя.
• Схема формата политики: пример в Rego или YAML с 5–7 правилами (запрет удалять письма старше N дней, разрешить чтение календаря, требовать подтверждения для отправки).
• Алгоритм разрешения конфликтов правил: deny-by-default, приоритеты, логирование каждого решения.

# фрагмент политики (Rego-подобный псевдокод)
allow {
    input.action == "email.read"
    input.folder == "inbox"
}

deny {
    input.action == "email.delete"
    input.count > 1
    not input.user_confirmed
}

require_confirmation {
    input.action == "message.send"
}

По ГОСТ 34.602-89 на техническое задание у вас будет отдельный раздел «Требования к системе», куда эти правила ложатся как функциональные требования с идентификаторами (F-01, F-02...). Не забывайте трассируемость: каждое требование должно быть проверено хотя бы одним тестом в третьей главе.

Тестирование и метрики: где взять цифры для выводов

Это самый частый провал на защите: «работает — и всё». Комиссия хочет цифры. Ниже — что реально можно замерить на прототипе IronCurtain-подобной архитектуры.

Для оформления метрик удобно опираться на ISO/IEC 25010 (надёжность, защищённость, производительность) — это даст академический вес вашему разделу оценки.

Чему вы научитесь на такой ВКР

• Проектировать многокомпонентную архитектуру с зоной доверия и изоляцией.
• Работать с policy engine (OPA, Casbin) и писать декларативные правила.
• Настраивать наблюдаемость: OpenTelemetry, Prometheus, структурированные логи.
• Обосновывать выбор стека через критерии, а не через «мне нравится».
• Оформлять техническую документацию по ГОСТ 34 и ГОСТ 19.

FAQ: вопросы, которые задают почти всегда

Источник: «Железный занавес» для ИИ: как повысить безопасность работы автономных ИИ-агентов | Блог Касперского (опубликовано 2026-03-30)