Дикий код становится рабочей проблемой безопасности: сотрудник может за пару дней собрать AI-автоматизацию для обработки заявок, а через месяц она уже читает клиентские записи и публикует сводки в общем канале. The Hacker News пишет, что такие полезные решения распространяются внутри компаний быстрее, чем процессы согласования, поддержки и контроля доступа. Для российских IT-команд это знакомый сценарий: low-code, боты и агенты экономят часы, но легко превращаются в незадокументированный сервис с правами продакшена.
В качестве типового примера издание приводит менеджера по продажам, который строит AI-процесс для маршрутизации лидов. Он подключает его к данным клиентов, поручает суммировать входящие обращения и отправлять обновления коллегам. Задача выглядит безобидно и вполне оправданно с точки зрения бизнеса: меньше ручной работы, быстрее реакция на заявку. Проблема начинается не в момент написания кода, а в момент, когда эксперимент становится частью ежедневной операции.
Под «диким кодом» авторы понимают не просто несанкционированную установку очередного SaaS-сервиса. Речь о новых приложениях, агентах и интеграциях, которые сотрудники создают сами. Такой проект может не пройти через разработку, ИБ и эксплуатацию, но всё равно получить учётные данные, доступ к API и реальным данным. У него часто нет владельца в реестре систем, понятного жизненного цикла и процедуры отключения.
Самая очевидная угроза — избыточные права. Автоматизации может требоваться чтение небольшой группы записей, но для удобства ей выдают токен сотрудника с куда более широким доступом. Вторая проблема — утечка чувствительных данных: сведения могут попасть в запрос к модели, в историю выполнения или в канал, где их увидят люди без нужных полномочий. Третья — нежелательные действия. Агент способен менять записи или права доступа, если для таких операций не предусмотрена отдельная граница подтверждения.
Есть и менее заметный риск: автор сценария переводится в другой отдел или увольняется, а его workflow продолжает работать от старой сервисной учётной записи. Когда затем возникает инцидент, служба безопасности вынуждена выяснять задним числом, какая идентичность запускала процесс, к чему она обращалась и что успела изменить. Если журналов, владельца и механизма остановки нет, расследование превращается в археологию по логам нескольких систем.
Авторы материала считают, что обучение сотрудников, песочницы и AI-комитеты полезны, но не решают задачу сами по себе. Политика объясняет желательное поведение, но не мешает подключить не тот источник данных. Песочница хороша для проверки промпта или прототипа, однако ценность решения обычно появляется после подключения к боевым системам. По словам полевого CTO Tines Брэда Рамфа, песочницы закрывают проблему проектирования, но оставляют без ответа вопрос безопасности во время работы системы.
Комитеты тоже не способны увидеть всё. Их цикл рассмотрения обычно медленнее, чем создание внутреннего бота или связки из нескольких API. Кроме того, контроль часто сосредоточен вокруг инженерных команд, где процессы уже существуют, а самодельные решения появляются в продажах, финансах, HR и операциях. Одобрение не может быть единственным способом, которым ИБ узнаёт о новом пути к чувствительным данным или привилегированным действиям.
Практический вывод для команд — переносить контроль в среду, где создают и запускают автоматизации. До подключения бизнес-систем нужно задавать разрешённые источники данных, действия и уровни доступа. После запуска эти ограничения не должны исчезать. Права стоит выдавать не по возможностям создателя сценария, а по минимальному набору, необходимому самой автоматизации. Для операций с последствиями — например, изменения прав или клиентских записей — нужен человек, который подтвердит действие.
Важно сделать безопасный путь не только обязательным, но и удобным. Если на получение разрешённого коннектора или сервисной учётной записи уходят недели, сотрудники найдут обходной маршрут под дедлайн. Нужны готовые подключения к одобренным системам, понятное назначение владельца, отдельные идентичности выполнения, аудит значимых действий и быстрый способ отозвать доступ. Промпт с фразой «не передавай конфиденциальные данные» не заменяет ограничение прав доступа — это инструкция, а не технический барьер.
Дикий код не исчезнет: AI-инструменты сделали создание внутреннего софта доступным людям, которые раньше не писали приложения вовсе. Вопрос теперь не в том, удастся ли запретить такие инициативы, а в том, сможет ли компания предложить им управляемую траекторию от идеи до продакшена. Побеждать будут не организации с самым длинным регламентом, а те, где безопасность не заставляет выбирать между скоростью работы и контролем над данными.
