Как не дать ИИ-агенту слить ваши данные наружу
Как не дать ИИ-агенту слить ваши данные наружу Чем больше умеет ИИ-агент — программа, которая сама рассуждает, вызывает внешние инструменты и работает с личными данными, — тем больше у злоумышленника способов вытащить из него ценное: внутренние инструкции модели, ключи доступа, приватные данные или саму модель через многократные запросы. Автор разбирает, как выстроить защиту: обычной защиты приложений тут уже мало, нужны отдельные механизмы контроля. Первый шаг — описать весь путь работы агента: что на входе (запросы, файлы, документы), что видит модель в процессе (системные подсказки, память, результаты поиска), какие инструменты использует и что уходит наружу — ответы, логи, сетевые запросы. Так видно, где в систему попадают ценные данные и через какие каналы они могут покинуть её. Автор также советует разделять два уровня: тот, где задаются правила и права агента, и тот, где обрабатываются сами запросы — взлом любого из них открывает доступ к секретам. Ключевое правило — по умолчанию запрещать агенту свободный выход в интернет: каждому рабочему процессу выдаётся белый список разрешённых адресов и типов данных. Поверх этого автор предлагает несколько уровней проверки: сканировать ответы на ключи и личные данные, блокировать неутверждённые адреса, ограничивать частоту запросов, подкладывать в защищённые данные отслеживаемые «маркеры-приманки», запускать инструменты в изолированной среде и требовать подтверждения человека для массовых выгрузок и смены прав. Для отслеживания цепочек действий упоминается открытый проект TrustGraph от HONEYPOTZ-AI: он строит граф связей между агентами, их правами, инструментами и действиями, чтобы проверять не отдельный запрос, а всю цепочку доверия за ним. Автор отмечает, что подход соответствует исследованиям HONEYPOTZ INC и особенно актуален там, где нужны строгие границы доступа, например в продукте DeepBody от DEEPBODY INC. Отдельная тема — ключи доступа к внешним сервисам. Их нельзя держать в тексте запросов, коде, памяти модели или настройках. Вместо этого специальный сервис выдаёт агенту короткоживущие ключи строго под одну задачу: агент, который только читает данные, не должен иметь права на запись или администрирование. Логи выдачи ключей ведут отдельно от содержимого запросов, ключи автоматически меняются, а при подозрении мгновенно отзываются. Автор отвечает и на частые вопросы: одной фильтрации запросов недостаточно — нужны ограничения доступа, проверка ответов и мониторинг; каждому агенту — свои ключи, чтобы было ясно, кто что делал, и легко отзывать доступ. Следить в первую очередь стоит за неожиданными запросами наружу, чувствительными данными в обращениях к инструментам, сменой прав и повторяющимися запросами «на извлечение». Это разбор подхода, а не описание внедрения с измеренным результатом. Источник: https://dev.to/vladimir_lialine_b2e67374/ai-agent-security-essential-defense-against-leaks-mkp