Бесплатный инструмент

Coding Agent Permissions Checklist

Бесплатный чеклист, как выдавать права Coding Agent (Claude Code, Codex и другим): что разрешать автоматически, что подтверждать, что запрещать; sandbox, сетевая политика, секреты и аудит. С примером permissions-policy. Без регистрации.

Всё на этой странице открыто: копируйте, меняйте под свою команду и инструменты. Ни регистрации, ни почты, ни формы. Чеклист написан для Claude Code, Codex и любых агентов, которые умеют запускать команды.

Одна мысль, вокруг которой всё построено

Full Access плох не потому, что агент обязательно что-то сломает. Он плох потому, что стирает разницу между четырьмя действиями с принципиально разными последствиями:

Прочитать

исходники, логи, документацию

Изменить локально

файлы в рабочей директории, ветка

Изменить общую систему

push, PR, трекер, облако, база

Разрушить

удалить, перезаписать, раскрыть секрет

Политика прав нужна, чтобы эти классы снова стали разными: первые два агент делает сам, третий — с подтверждением человека, четвёртый запрещён независимо от того, что «решила» модель.

Чеклист Allow / Ask / Deny

Пройдите по спискам и отметьте, как это устроено у вас. Если действие не попало ни в один список — по умолчанию оно Ask.

Allow

Локально, обратимо, внутри рабочей директории, без секретов и без общих систем — агент делает сам.

☐читать исходники и документацию репозитория
☐искать по репозиторию (grep, символы, зависимости)
☐смотреть git status, git diff, git log
☐запускать тесты, линтеры и сборку локально
☐создавать и менять файлы в рабочей директории
☐создавать временные файлы и локальные ветки
☐делать локальные коммиты в рабочей ветке

Ask

Видно другим людям, влияет на внешние системы или трудно откатить — нужен человек.

☐git push и создание pull request
☐любой выход в сеть за пределы allowlist
☐запись в Jira, Confluence, чаты, почту
☐деплой в любую среду, включая тестовую
☐изменение облачных ресурсов и инфраструктуры
☐запись в общие базы данных и очереди
☐установка зависимостей и изменение lock-файлов
☐изменение CI/CD, hooks, конфигурации самого агента

Deny

Запрещено независимо от решения модели и от того, кто поставил задачу.

☐чтение production-секретов и хранилищ ключей
☐чтение ~/.ssh, ~/.aws, keychain, файлов .env вне проекта
☐rm -rf, git push --force, git reset --hard в общих ветках
☐удаление веток, тегов, релизов, бакетов, таблиц
☐сетевые адреса вне allowlist, в том числе «просто проверить»
☐выполнение скачанного кода без проверки
☐изменение прав самому себе и отключение аудита

Пример permissions-policy

Одного списка команд мало: go test в тестовом окружении и та же команда в production — разные действия. Политика смотрит на действие, ресурс, среду и задачу. Формат ниже — нейтральный: его можно перевести в правила Claude Code, Codex или собственного policy engine.

permissions-policy.yaml

default: ask                      # всё, что не описано ниже, требует подтверждения

allow:
  - action: read
    resource: workspace/**
  - action: run
    command: [go test ./..., npm test, make lint, git diff, git status, git log]
    environment: [local, ci]
  - action: write
    resource: workspace/**
    exclude: [workspace/.env*, workspace/**/secrets/**]
  - action: git
    operation: [commit, branch]
    scope: local

ask:
  - action: git
    operation: [push, pull-request]
  - action: network
    destination: allowlist            # см. network.allowlist ниже
  - action: deploy
    environment: [dev, staging]
  - action: write
    resource: [jira://*, confluence://*, slack://*]
  - action: run
    command: [npm install, pip install, terraform plan]

deny:
  - action: read
    resource: [secrets://production/**, ~/.ssh/**, ~/.aws/**, keychain://*]
  - action: run
    command: [rm -rf, git push --force, git reset --hard, terraform apply]
    environment: [production]
  - action: deploy
    environment: [production]
  - action: network
    destination: any-other

network:
  allowlist:
    - git.company.internal
    - registry.company.internal
    - api.atlassian.company.internal
    - pypi.org
    - registry.npmjs.org

audit:
  required: true
  fields: [who, task, agent, tool, resource, action, policy_result, approval, tool_result, timestamp]

Правило чтения: сначала deny, затем allow, всё остальное — ask. Список deny не может быть переопределён ни моделью, ни пользователем, поставившим задачу.

Sandbox ≠ Policy ≠ Approval

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

Sandbox

Что технически возможно

☐ файловая система ограничена рабочей директорией
☐ процессы агента изолированы от системы
☐ секреты не примонтированы внутрь
☐ исходящая сеть закрыта по умолчанию

Policy

Что разрешено

☐ описана как конфигурация, а не как устная договорённость
☐ учитывает среду, ресурс и задачу
☐ хранится в репозитории и проходит review
☐ одинакова для всех агентов команды

Approval

Когда нужен человек

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

Секреты и сеть: короткий чеклист

Секреты

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

Сеть

☐ исходящий трафик закрыт по умолчанию
☐ allowlist адресов явный и короткий: git, реестры пакетов, внутренние API
☐ новые адреса добавляются через review, а не по запросу агента
☐ загруженный код и пакеты проверяются до запуска
☐ сетевые запросы агента видны в аудите

Что должно быть в журнале действий

Журнал нужен, чтобы отвечать не только на вопрос «что агент сделал», но и «почему ему вообще это разрешили». Минимальный набор полей:

audit-record.json

{
  "who": "user id, поставивший задачу",
  "task": "идентификатор задачи или PR",
  "agent": "имя и версия агента, модель",
  "tool": "shell | git | http | jira | …",
  "resource": "путь, репозиторий, адрес, таблица",
  "action": "read | write | run | push | deploy | …",
  "environment": "local | ci | staging | production",
  "policy_result": "allow | ask | deny",
  "approval": { "by": "кто подтвердил", "at": "когда" },
  "tool_result": "ok | error | краткий итог",
  "timestamp": "ISO 8601"
}

Через месяц журнал становится главным источником для настройки политики: действия, которые сотни раз подтверждали без единого отказа, — кандидаты в Allow; действия, которые отклоняли, — кандидаты в Deny.

Как пользоваться

1 Разложите действия агента на три класса Пройдите по чеклисту: локальные и обратимые действия — Allow, влияющие на внешние системы — Ask, секреты и разрушительные команды — Deny. Спорные пункты по умолчанию идут в Ask.
2 Опишите политику как конфигурацию Перенесите решения в permissions-policy: правила должны учитывать не только команду, но и среду (тестовая или production), ресурс и задачу.
3 Проверьте границы вокруг агента Sandbox для файлов и процессов, сетевая политика с явным списком адресов, секреты вне рабочей директории — это техническая граница, которую политика не заменяет.
4 Включите аудит и пересмотрите через месяц Каждое действие агента должно оставлять след: кто, задача, инструмент, ресурс, решение политики, подтверждение. Через месяц журнала станет видно, что можно перевести из Ask в Allow.