Cloudflare не выдала сотрудникам API-ключи — и правильно сделала

Самая опасная часть внутреннего AI-бумa — не плохие ответы моделей. Это момент, когда сотрудник из отдела продаж просит несколько API-ключей, доступ к десятку production-систем и права администратора в пайплайне деплоя, чтобы собрать свою «SuperApp».

Cloudflare решила не запрещать такие инициативы. Но и не стала раздавать доступы всем желающим. В этом и есть главный урок Cloudflare OS: AI нужно масштабировать не через доверие к каждому автору, а через архитектуру, которая не позволяет случайно получить лишнее.

Сначала компания пошла довольно неочевидным путём. Вместо того чтобы выдать каждому harness для генерации кода, она предложила сотрудникам отправлять рутинные задачи на общий «magic AI email bot». За этим адресом небольшая команда выполняла работу с помощью AI-инструментов.

Звучит не очень технологично — и именно поэтому подход полезен. Такой «ручной» слой позволил собрать реальные запросы бизнеса и постепенно превратить их в набор повторяемых skills. Иначе организация быстро получила бы поток vibe-coded приложений, которые ищут себе проблему уже после написания.

Следующий слой — ответственность. В Cloudflare считают AI инструментом и инструментарием, а не новым сотрудником. Человек, который заказал или запустил агента, отвечает за его результат, качество, тестирование и рабочий процесс. Если сотрудник уходит, ответственность за его агентов переходит руководителю.

Чтобы это не осталось декларацией, доменные эксперты описывают правильный способ работы в Engineering Codex. Это не просто список запретов: Codex задаёт предпочтительные практики. Затем отдельные агенты проверяют Merge Request, технические дизайны и отчёты об инцидентах на соответствие этим правилам.

Самая сильная идея — доступы. Каждый агент и каждое приложение стартуют с нулевыми правами. Интернет и конкретные ресурсы подключаются только явно, а доступ ограничивается разрешениями текущего пользователя. Если агентом поделились, он действует с правами получателя, а не автора.

Для внешних систем Cloudflare использует Gatekeeper — промежуточный сервис, который хранит OAuth-учётные данные, проверяет политики и журналирует действия. Он может разрешить агенту читать issues только в одном репозитории, скрыть отдельные поля, ограничить частоту запросов или потребовать подтверждение перед merge.

Особенно интересно, что система пытается переносить ограничения вместе с данными. Если агент прочитал чувствительный ресурс, полученный результат сохраняет сведения о его происхождении и уровне доступа. Тогда Gatekeeper может запретить передать этот результат другому агенту, пригласить нового участника или отправить данные наружу. Это уже не обычная проверка «есть ли у пользователя доступ», а транзитивный контроль над тем, что было построено на основе данных.

Но здесь как раз начинается зона неизвестного. Cloudflare OS описывается как открытая платформа, однако её архитектура заметно опирается на Workers, Cloudflare Access и другие продукты Cloudflare. Без серьёзной адаптации использовать такой подход за пределами этой экосистемы, вероятно, будет трудно. Кроме того, пока неясно, как именно технически реализовано «заражение» результатов правами и чувствительностью входных данных: детерминированными правилами, AI-механизмами или их сочетанием.

Есть и организационное ограничение: нельзя ожидать от сотрудника без технического бэкграунда понимания рисков на уровне разработчика или архитектора. Поэтому ответственность человека сама по себе не является защитой. Она работает только вместе с opinionated-правилами, шлюзами, аудитом и безопасными настройками по умолчанию.

Для компаний практический вывод простой: прежде чем выдавать всем доступ к генерации приложений, стоит создать безопасный канал для сбора задач, описать «как правильно» для ключевых доменов и убрать API-ключи из пользовательского сценария. Хороший AI-платформенный слой должен защищать людей от собственных неосторожных решений, а не просить их быть экспертами по безопасности.

Если бы вашим сотрудникам завтра понадобились агенты для работы с production-данными, вы бы сначала дали им конструктор или сначала построили Gatekeeper? Источник: Hacker News - Newest: ""AI" "LLM""