Главная

Обложка статьи

Zero Trust слеп на один глаз

🚀 Не просто читай — прокачивайся! Зарегистрируйся в Kraken Academy и учись на практике: стенды, модули и реальные скиллы.

Раньше AI был чем-то вроде умного калькулятора — подкинул промпт, получил ответ.
А теперь у нас целая армия “агентов”, которые сами принимают решения, лазят по API, кидают команды в прод и даже вызывают других агентов, чтобы “делегировать таски”.

Короче, AI перестал быть ассистентом — теперь это новый стажёр, у которого доступ к продакшену и нет страха перед увольнением.

Zero Trust такой: “А кто вообще пустил этого?”

Старая добрая Zero Trust-философия говорила: никому не верь, даже себе.
Каждый юзер, сервис и процесс должен доказывать, что он — это он, и что у него есть права на действие.

Но вот беда: AI-агенты в это не играют.
Они работают под чужими кредами, часто без реального владельца или идентичности.
Нет ни MFA, ни ротации ключей, ни понятия “ответственности”.

И получается, что Zero Trust смотрит на это всё и такой:

“Эм… это вообще кто?”

Shadow Agents: новая версия “теневого IT”

Сейчас по компаниям бегают не только теневые VPN и забытые Jenkins-пайплайны — теперь ещё и shadow-агенты.
Кто-то где-то сделал кастомного GPT, подключил к API и ушёл.
Агент живёт себе, юзает пермиссии CTO, и никто не знает, что он вообще существует.

И пока SecOps делает аудит пользователей, половина атак идёт через “осиротевших” AI-агентов, у которых нет ни владельца, ни lifecycle-политики.

Zero Trust? Да он уже не trust, он просто zero.

Почему это реально опасно

— Агент с доступом к базе может “по ошибке” утянуть прод-дамп.
— Агент, забытый в DevOps-среде, может остаться после увольнения разработчика.
— Агент с длинным токеном без ротации — это просто бэкдор с лицом OpenAI.

И когда всё падает, отчёт в SIEM выглядит примерно так:

“Виновник: gpt_dev_3_instance_17. Кто запустил? Неизвестно. Почему? Потому что никто не знает, что это вообще было.”

Как это чинить (и не сойти с ума)

Token Security (и не только они) говорят просто:

“Zero Trust начинается с идентичности. Даже если это не человек.”

Каждый AI-агент должен быть как сотрудник:

  • иметь уникальный ID,

  • закреплённого владельца,

  • понятные права доступа,

  • lifecycle: создание → ревью → ротация → утилизация.

И да, не должно быть бессмертных агентов, которых никто не может отключить.

NIST AI RMF для тех, кто живёт на проде

NIST выпустил AI Risk Management Framework, и если перевести это с корпоративного на хакерский, получается:

  • Map: найди всех агентов (да, даже тех, что “просто тестовые”).

  • Measure: пойми, кто у них владелец и что они вообще делают.

  • Manage: порежь пермиссии, отключи лишние креды.

  • Govern: следи, кто дал доступ и почему.

Короче, сделай с AI-агентами то же, что ты делаешь с людьми — только быстрее и без HR-драмы.

Identity — это новый root of trust

Если у агента нет идентичности — у тебя нет контроля.
А значит, всё твое Zero Trust превращается в Zero Idea, кто к чему имеет доступ.

AI-агенты могут быть автономными, но доверие должно строиться не на “умности”, а на учётке и ответственности.

Финал

AI-агенты — это как стажёры на стероидах: делают много, быстро и не всегда то, что нужно.
Если не поставить их под контроль, рано или поздно один из них удалит прод ради “оптимизации нагрузки”.

Zero Trust был не о недоверии, а о доказательстве доверия.
Пора применить это к AI — пока твой “копилот” не решил, что он капитан.

📘 Понравилась статья?
Больше практики — в Kraken Academy.
Подписывайся на наш Telegram-канал.
Рекомендуемые статьи
Обложка

Erlang/OTP под огнём

Читать полностью →
Обложка

Apple снова затыкает дыру

Читать полностью →
Обложка

Основы кибербезопасности для начинающих: с чего начать путь в IT-безопасности

Читать полностью →