Доступ AI-агенту к одному приложению: зачем Cloudflare разделила права в Workers

У разработчика или AI-агента есть задача исправить один сервис. Для этого ему выдают доступ ко всему облачному аккаунту — просто потому, что так быстрее настроить. Цена такого удобства становится заметна при ошибке: область возможного ущерба намного шире порученной работы.

15 сентября 2026 года Cloudflare представила более точные права для Workers. Доступ можно ограничить конкретным приложением и выбрать роль: просмотр метаданных, чтение содержимого, редактирование или администрирование. Ограничения применимы и к токенам для автоматических систем.

Специалисту, который ищет причину сбоя, может быть достаточно журналов и показателей. Тому, кто изучает код, нужен другой объём доступа. А выпуск новой версии — отдельная операция с последствиями для пользователей.

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

Один небольшой сервис может иметь доступ к общей клиентской базе. Тогда разрешение менять его код всё равно чувствительно. Нужно оценивать не только видимое приложение, но и то, какие данные и действия доступны ему самому.

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

У автоматической системы должен быть собственный доступ, который можно отозвать независимо от человека. Общий секрет на всю команду затрудняет расследование: по записи в журнале непонятно, кто именно выполнил действие.

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

Проверяют и разрешённые, и запрещённые действия. Участник должен суметь выполнить свою задачу, но не получить доступ к соседнему проекту. Такие проверки проводят на безопасных ресурсах, без попыток удалить рабочее приложение.

Также нужен ответ на случай ошибки: кто остановит автоматизацию, как отключит её токен и где посмотрит историю изменений. Ограниченные права уменьшают риск, но не делают некорректное обновление безвредным.

Можно начать с одного вопроса: какой доступ получит подрядчик, которому завтра поручат исправить форму? Если ответ — пароль основного администратора, полезная работа по безопасности уже найдена.

Новость Workers показывает направление развития платформ: права становятся ближе к конкретной задаче. Для бизнеса это возможность передавать работу людям и автоматике с понятными границами ответственности.

A developer or AI agent has a task to fix a single service. To do this, they are granted access to the entire cloud account simply because it is faster to set up. The cost of this convenience becomes apparent when an error occurs: the scope of potential damage is far wider than the assigned task.

On September 15, 2026, Cloudflare introduced more granular permissions for Workers. Access can be restricted to a specific application with a chosen role: viewing metadata, reading content, editing, or administering. These restrictions also apply to tokens for automated systems.

A specialist looking for the cause of a failure may only need logs and metrics. Someone studying the code requires a different level of access. Publishing a new version is a separate operation with consequences for users.

New Cloudflare roles make this distinction explicit. For example, an editor can update content and settings but cannot create or delete resources. This approach is worth adopting as a baseline for permission audits in other company systems, even if role names differ.

A small service may have access to a shared customer database. In that case, granting permission to modify its code remains sensitive. You must evaluate not only the visible application but also the data and actions it can access directly.

Therefore, before granting permissions, draw a simple chain of responsibility: what task does the participant perform, what must they see, what changes are allowed, and who approves the release. This helps select minimally sufficient privileges without constant manual exceptions.

Automated systems need their own access, revocable independently of any person. A shared secret for the entire team complicates investigations: log entries alone often reveal nothing about who actually performed an action.

It is useful to track token assignments and integration owners. If an experiment ends, its access should not remain active for months out of habit. The process for revoking access is just as important as the initial issuance.

Both allowed and denied actions are verified. The participant must be able to complete their task without gaining access to adjacent projects. Such checks are performed on safe resources, without attempts to delete the live application.

There must also be a response plan for errors: who will stop the automation, how to revoke its token, and where to review the change history. Limited rights reduce risk but do not make an incorrect update harmless.

Start with one question: what access will the contractor receive tomorrow to fix a form? If the answer is the main administrator password, you have already found a valuable security improvement.

The Workers update signals the direction of platform evolution: permissions are becoming more task-specific. For businesses, this offers the ability to delegate work to people and automation with clear boundaries of responsibility.