Zero Trust слеп на один глаз
Раньше 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 мы собрали полноценные курсы по информационной безопасности с лабораториями, практическими заданиями и пошаговыми образовательными треками - от первых шагов до уровня специалиста.
