Искусственный интеллект кардинально меняет правила игры в бизнесе: от автодополнения кода с помощью GitHub Copilot до чат-ботов, мгновенно находящих ответы в корпоративных базах знаний. Каждый такой агент должен проходить аутентификацию в сервисах, из-за чего число не‑человеческих идентификаций (NHI) в облаках компаний стремительно растёт.
Их количество уже вышло из‑под контроля: сегодня на каждого человека в организации приходится в среднем 45 машинных идентификаций. Сервисы, CI/CD‑боты, контейнеры и AI‑агенты — у всех есть секреты, чаще всего в виде API-ключей, токенов или сертификатов, которые необходимы для безопасного взаимодействия с другими системами. Согласно исследованию GitGuardian по управлению секретами в 2025 году, в 2024‑м только на публичном GitHub было обнаружено более 23,7 миллиона секретов. И что ещё хуже — репозитории с включённым Copilot допускали утечки на 40% чаще.
45 машинных идентификаций на каждого человека
23,7 миллиона раскрытых секретов
40% роста утечек с Copilot
Что такое NHI и почему это не люди
В отличие от реальных пользователей, NHI почти никогда не подвергаются обязательной смене ключей, ужесточению прав доступа или деактивации устаревших учетных записей. Без надлежащего контроля они образуют сложную и непрозрачную сеть высокорисковых связей, которыми злоумышленники могут пользоваться долгое время, даже спустя годы после того, как сами секреты забыты.
Появление AI, особенно больших языковых моделей и методов Retrieval-Augmented Generation (RAG), резко ускорило рост таких угроз и усложнило масштабы проблемы.
Например, внутренний чат‑бот поддержки на базе LLM может по запросу выдать страницу из Confluence с реальными учетными данными. Не подозревая о рисках, бот раскрывает секреты любому, кто умеет правильно задать вопрос. А логи таких запросов могут оказаться доступными всем, у кого есть доступ к журналам. Более того, сама модель иногда рекомендует разработчикам использовать эти ключи в открытом виде — что создает серьёзные дыры в безопасности.
Но решение есть. При грамотном управлении NHI и секретами разработчики смогут быстрее создавать и безопаснее запускать AI‑решения.
Пять практических советов для снижения рисков, связанных с AI и NHI
Чтобы минимизировать угрозы безопасности, связанные с не‑человеческими идентификациями и AI, компаниям стоит сосредоточиться на пяти основных шагах:
- Провести аудит и очистить источники данных
- Централизовать управление всеми NHI
- Предотвратить утечки секретов из LLM‑систем
- Улучшить безопасность логирования
- Ограничить доступ AI к данным
Давайте разберём каждую из этих рекомендаций подробнее.
Аудит и очистка источников данных
Первые LLM использовали лишь учебные наборы данных, что серьёзно ограничивало их возможности. Технология RAG позволила моделям обращаться к дополнительным источникам по запросу. Но если в этих данных содержатся секреты, связанные с ними идентификации становятся уязвимыми.
Платформы для управления проектами, такие как Jira, системы коммуникаций вроде Slack и базы знаний, например Confluence, изначально не были созданы с учётом AI и безопасного обращения с секретами. Если кто-то случайно загружает открытый API‑ключ, никто не сигнализирует о риске. Один только некорректный запрос к чат-боту может превратить его в источник массовой утечки секретов.
Единственный надёжный способ закрыть эту брешь — полностью удалить такие секреты или хотя бы деактивировать связанные с ними доступы. Недействительный ключ уже не представляет угрозы. Лучший путь — убрать их раз и навсегда, чтобы AI‑агент никогда не получил к ним доступ. К счастью, существуют инструменты вроде GitGuardian, значительно упрощающие этот процесс.
Централизация управления NHI
Как говорится, «что не измерено, то не управляется». Это верно и для не‑человеческих идентификаций. Без полного учёта всех сервисных аккаунтов, ботов, агентов и конвейеров невозможно эффективно контролировать новые NHI, связанные с AI‑агентами.
Объединяет все NHI то, что у них есть секреты, обеспечивающие аутентификацию. Фокусируясь именно на управлении этими секретами, становится проще держать всё под контролем — тема далеко не нова.
Для централизованного хранения и управления секретами отлично подойдут такие инструменты, как HashiCorp Vault, CyberArk или AWS Secrets Manager. Собрав все NHI в одном месте, компании смогут автоматически и регулярно менять ключи согласно правилам безопасности.
Предотвращение утечек секретов из LLM‑систем
Протокол Model Context Protocol (MCP) — новый стандарт взаимодействия AI‑агентов с сервисами и данными. Раньше разработчикам приходилось собирать всё вручную, что часто приводило к «жёстко прописанным» в коде ключам. MCP стандартизирует процесс и снижает риск человеческих ошибок.
Однако исследования безопасности показали, что 5,2% MCP серверов содержат хотя бы один зашитый в код секрет, что выше среднего — 4,6% среди всех публичных репозиториев.
Ранняя профилактика поможет избежать серьёзных инцидентов. Например, если утечку ключа обнаружить на стадии работы с веткой фичи, её проще устранить до публикации. Интеграция систем поиска секретов, таких как ggshield от GitGuardian, в процесс разработки предотвратит появление открытых ключей в общем коде.
Укрепление безопасности логирования
LLM — это «чёрные ящики»: они принимают запросы и выдают вероятностные ответы. Мы не можем напрямую контролировать внутреннее устройство модели, но можем управлять тем, что она выдаёт на выходе. Команды AI и ML ведут логирование всего процесса: от запроса и контекста до ответа, чтобы улучшать качество работы агентов.
Если секрет случайно появляется в процессе логирования, он множится — чаще всего в сторонних инструментах или облачных хранилищах с минимальными настройками безопасности.
Самый надёжный способ — добавить этап очистки логов перед их сохранением или отправкой третьим лицам. Это требует усилий инженеров, но инструменты вроде ggshield позволяют автоматически сканировать и удалять секреты из логов, значительно снижая риски.
Ограничение доступа AI к данным
Стоит ли LLM иметь доступ к вашей CRM? Всё зависит от ситуации. Если это внутренний инструмент продаж с SSO для быстрого поиска заметок — это может быть безопасно. Но для чат-ботов на публичном сайте — категорически нельзя.
Как и с принципом наименьших привилегий для пользователей, AI‑агентам нужно ограничивать доступ к данным по минимуму. Желание дать ИИ полный доступ ради ускорения работы велико, но чрезмерный доступ увеличивает риск инцидентов, а слишком жёсткие ограничения сводят на нет преимущества RAG‑моделей.
Повышение осведомлённости разработчиков
Хотя это и не входит в предыдущий список, без обучения и информирования разработчиков все меры окажутся малоэффективными. Людям, работающим с AI, нужны понятные инструкции и ограничения, которые помогут им быстро и безопасно выполнять задачи.
Универсального технического решения не существует — безопасное масштабирование AI требует слаженной работы людей, процессов и правил.
Если вы разработчик, поделитесь этой статьёй с командой безопасности и обсудите, как внедрять AI безопасно у вас в компании. Если вы специалист по безопасности — расскажите об этих рекомендациях разработчикам и DevOps‑командам, чтобы вместе построить надёжную защиту AI‑процессов.
Безопасность машинных идентификаций — ключ к надежному AI
Следующий уровень внедрения AI достанется тем компаниям, которые будут относиться к не‑человеческим идентичностям так же внимательно, как к реальным пользователям. Необходимо внедрить постоянный мониторинг, управлять сроками жизни учетных данных и строго регулировать обращение с секретами. Создав надёжный фундамент сегодня, корпорации смогут без опасений масштабировать AI‑проекты и раскрыть весь потенциал интеллектуальной автоматизации, не подвергая риску безопасность.
Если вам понравилась эта статья, подпишитесь, чтобы не пропустить еще много полезных статей!
Премиум подписка - это доступ к эксклюзивным материалам, чтение канала без рекламы, возможность предлагать темы для статей и даже заказывать индивидуальные обзоры/исследования по своим запросам!Подробнее о том, какие преимущества вы получите с премиум подпиской, можно узнать здесь
Также подписывайтесь на нас в:
- Telegram: https://t.me/gergenshin
- Youtube: https://www.youtube.com/@gergenshin
- Яндекс Дзен: https://dzen.ru/gergen
- Официальный сайт: https://www-genshin.ru