
Проблема
AI-memory интеграции выглядят безобидно: они подключают агент к памяти, помогают вспомнить контекст и улучшить ответ. Но технически такой пакет находится внутри процесса, где одновременно могут быть prompt-данные, переменные окружения, токены публикации, SSH-ключи, cloud credentials и доступ к репозиторию.
Почему это опаснее обычной зависимости
Обычная библиотека часто работает с узким набором данных. Agent runtime шире: он может читать запрос пользователя, подтягивать память, запускаться в CI или на машине разработчика и наследовать секреты окружения. Если такой компонент скомпрометирован, инцидент затрагивает не только приложение, но и release pipeline.
Что проверить
- Lockfiles и SBOM: нет ли затронутых версий agent/memory-пакетов в npm, PyPI, контейнерах и CI.
- Где именно запускался пакет: workstation, test runner, container, GitHub Actions, release job.
- Какие секреты были доступны процессу: registry tokens, GitHub/GitLab, AWS, Vault, SSH, Hugging Face, Slack, Stripe, SendGrid.
- DNS/proxy/egress-журналы: были ли обращения к неизвестной инфраструктуре после установки или импорта пакета.
- Историю публикаций своих пакетов: не появились ли релизы, которых команда не делала.
Минимальный контроль для AI-зависимостей
ai_dependency_policy:
install:
require_lockfile: true
block_latest_tag: true
minimum_release_age_days: 7
runtime:
deny_secret_env_by_default: true
allow_egress_domains: ["api.company.local"]
response:
rotate_if_loaded_with_secrets: true
rebuild_runner_from_clean_image: true
Как отвечать на подозрение
Если пакет успел запуститься рядом с секретами, относись к хосту как к потенциально скомпрометированному. Удаление зависимости — только первый шаг. Нужны отзыв токенов, пересборка runner’ов, проверка egress, аудит релизов, очистка кэшей и повторная сборка из известного чистого состояния.
Вывод
AI-плагины памяти нужно относить к privileged software. Они требуют allowlist, pinning, egress-контроля и ограниченного набора секретов. Чем умнее становится агент, тем важнее делать его окружение скучным, наблюдаемым и минимально доверенным.
Используй материал как рабочий чеклист: сначала подтверждай наличие технологии в своей среде, затем собирай evidence, отделяй наблюдения от подтверждённых findings и закрывай изменения ретестом.