Любая платформа заявляет, что серьёзно относится к безопасности. Никто не говорит об этом в разборе инцидента после утечки — вот тогда наконец описывают архитектуру, а не прилагательные. Так что сразу перейдём к архитектуре. Проще всего объяснить изоляцию арендаторов через три способа, которыми команды обычно её ломают, и что из-за этого происходит.
Ошибка первая: фильтрация по ID арендатора в коде приложения
Это выбирают по умолчанию, потому что так проще всего написать: в каждый запрос добавляют условие WHERE user_id = ? , и пока каждый разработчик о нём помнит, каждый запрос остаётся в своих границах. Последствия проявляются позже, когда в кодовой базе становится четыреста эндпоинтов вместо четырёх. Кто-то добавляет отчётный запрос с джойном двух таблиц и забывает фильтр для второй. Кто-то другой создаёт админ-инструмент «только для внутреннего использования», который запрашивает данные вообще без привязки к арендатору, потому что в тот момент это казалось безопасным. Ни одна из этих ошибок не срабатывает в тестах, потому что запрос по-прежнему возвращает валидные строки — просто валидные строки не того арендатора.
Мы не полагаемся на то, что каждый запрос «вежливо» вспомнит спросить нужное. Защита на уровне строк применяется на уровне базы данных, поэтому сама база данных отказывается возвращать строки другого арендатора независимо от того, что запросил вызывающий код. Привилегированного обхода в пути запроса тоже нет — политика действует всегда, включая пути, которые хотелось бы считать доверенными.
Ошибка вторая: относиться к «песочнице» как к оптимизации, а не как к границе
Агенты здесь выполняют реальный код — в этом и есть суть продукта, — и соблазнительный кратчайший путь состоит в том, чтобы запускать этот код где-то удобно и «ограничить, когда дойдут руки». В этой версии последствия выглядят как скомпрометированная зависимость, подтянутая во время сборки и выходящая в открытый интернет, или как выполнение агента одного арендатора, читающего файлы, принадлежащие рабочему пространству, которое ему видеть не полагалось, потому что файловая система была общей по умолчанию, а ограничения вводились как исключение.
Вместо этого рабочие нагрузки агентов выполняются в изолированных средах:
- Закрытые файловые системы.
- Исходящий сетевой трафик по принципу белого списка, а не открытой двери.
Агент, работающий над вашей сборкой, видит только ваше рабочее пространство — и точка. Недоверенный код — включая сборки вашего собственного приложения — компилируется в контейнерах, где изоляция структурная, а не настройка, которую кто-то не забыл включить.
Ошибка третья: передать учётные данные агенту
Это самая тонкая ошибка, и, пожалуй, та, на которой чаще всего попадаются команды. Если агенту нужно задеплоить на ваш хостинг или опубликовать что-то в вашем магазине, самый короткий путь — положить OAuth-токен или SSH-ключ в его контекст и дать им воспользоваться. Это же и самый короткий путь к катастрофе: инструкция, внедрённая через промпт-инъекцию, галлюцинированное действие, учётные данные, случайно оказавшиеся в логе где-то не там. Агенту не обязательно быть злонамеренным, чтобы всё пошло не так — достаточно ошибиться один раз, имея на руках настоящие ключи.
Поэтому агент никогда не держит ключи у себя. Подключённые учётные данные хранятся в рамках вашего аккаунта и используются только для того действия, ради которого их подключили:
- Аккаунты магазинов
- OAuth-токены соцсетей
- Ключи для деплоя
- Сервисные аккаунты Google
Когда агенту нужно задеплоить или загрузить файл, он просит платформу сделать это; учётные данные хранит и действие выполняет платформа. Агент никогда не видит секрет, который просит использовать. А на стороне аналитики, где ресурсы Google иногда используются совместно несколькими сайтами, каждый запрос к GA4 фильтруется по имени хоста, поэтому ваша панель не может случайно показать чужие цифры, даже если базовый ресурс собирает данные по многим доменам.
Что реально проверяется перед публикацией
На этой платформе повсеместно действуют два правила, и именно здесь они особенно важны:
- Агенты не могут тратить ваши деньги.
- Агенты не могут публиковать что-либо от вашего имени.
Оба этих действия требуют вашего клика. Это значит, что худший день любого автоматизированного компонента всё равно не затронет ни ваш кошелёк, ни вашу репутацию — радиус поражения ограничен по замыслу, а не здравым смыслом агента. Полная информация о хранении и удалении данных приведена в Политике конфиденциальности; запросы на удаление вступают в силу в течение 30 дней.
