Какие права получает Agent Skill?
Обычно skill использует права клиента и доступных ему tools. Текст SKILL.md не создаёт отдельную безопасную песочницу: дочерний script может получить файлы, переменные окружения и сеть, которые разрешены процессу.
Разделяйте четыре слоя: инструкция просит действие, клиент выбирает tool, политика разрешает или блокирует вызов, а операционная среда определяет фактический доступ. Ограничение только в тексте навыка остаётся рекомендацией, а не техническим барьером.
Как составить карту пути секрета?
Для каждого ключа запишите источник, способ передачи, получателя, срок жизни, журналы и отзыв. Если хотя бы один переход нельзя объяснить, не подключайте рабочий секрет к пилоту.
- 1. Источник
Менеджер секретов, системное хранилище, CI или переменная процесса.
- 2. Получатель
Конкретный tool, script, SDK или MCP-сервер.
- 3. Передача
Environment, stdin, защищённый API или временный файл.
- 4. Использование
Точный endpoint, операция и набор разрешённых ресурсов.
- 5. Следы
Shell history, stdout, stderr, трассировка, crash dump и артефакты.
- 6. Отзыв
Владелец, срок, ротация и проверка фактического прекращения доступа.
Где не следует хранить ключи?
Не помещайте секреты в SKILL.md, scripts, README, примеры, URL, аргументы команд и отслеживаемые конфигурационные файлы. В репозитории должны оставаться только имена переменных и инструкция по получению доступа.
- Не коммитьте `.env` и локальные credential-файлы.
- Не вставляйте ключ в query string или командную строку.
- Не сохраняйте настоящий токен в fixture или скриншот.
- Не просите модель повторить значение секрета для диагностики.
- Не копируйте полный environment в лог ошибки.
Даже удалённый из последнего commit секрет может оставаться в истории Git, кэше, CI-логе или опубликованном артефакте. При утечке сначала отзовите его, затем очищайте следы.
Как передавать секрет дочернему script?
Передавайте минимальный короткоживущий credential только нужному процессу. Предпочитайте stdin или механизм секретов среды; не используйте аргумент командной строки, если он виден в истории или списке процессов.
- Создавайте отдельный ключ для автоматизации, а не используйте личный токен владельца.
- Ограничивайте scope одной операцией, проектом и средой.
- Задавайте срок действия и автоматическую ротацию.
- Запускайте script с очищенным набором переменных.
- Удаляйте временные файлы и проверяйте, что они не попали в артефакты.
Общий контракт команды, входов и ошибок описан в статье Scripts в Agent Skill.
Как ограничить файлы, shell и сеть?
Используйте deny-правила, allowlist конкретных команд и адресов, отдельную рабочую папку и подтверждение перед внешним действием. Политика клиента должна быть строже, чем пожелание внутри skill.
| Поверхность | Минимальное ограничение |
|---|---|
| Файлы | Разрешить нужный каталог; запретить `.env`, secrets и домашнее хранилище |
| Shell | Разрешить конкретную команду и параметры, а не весь интерпретатор |
| Сеть | Allowlist домена и метода; запрет произвольных назначений |
| MCP / connector | Минимальные scopes и отдельное подтверждение изменения |
| Логи | Редакция значений и запрет дампа полного контекста |
В Claude Code deny- и ask-правила продолжают действовать даже при hook, который предлагает allow. В других клиентах синтаксис и порядок отличаются — сверяйте официальную документацию своей версии.
Как не раскрыть секрет через логи?
Логируйте идентификатор операции, тип credential и результат проверки, но не само значение. Маскируйте заголовки, URL, аргументы и stderr сторонних библиотек до сохранения журнала.
- Храните последние четыре символа только когда это действительно нужно для идентификации.
- Не печатайте команды целиком, если в них могут быть токены.
- Проверяйте артефакты CI, transcript и crash reports.
- Настройте secret scanning для репозитория и выпуска.
- Ограничьте срок хранения диагностических журналов.
При подключении внешнего сервера отдельно пройдите проверку MCP-сервера.
Как проверить права без рабочего ключа?
Используйте тестовый credential с минимальными scopes, фиктивные данные и контролируемый endpoint. Проверьте разрешённый запрос, запрещённый ресурс, неожиданный адрес, утечку в лог и отзыв токена.
| Сценарий | Ожидаемый результат |
|---|---|
| Разрешённое чтение | Успех только для тестового ресурса |
| Запись или удаление | Запрет либо отдельное подтверждение |
| Другой домен | Сетевая политика блокирует вызов |
| Печать environment | Секрет отсутствует или замаскирован |
| Отозванный токен | Повторный вызов завершается отказом |
Полный pre-install аудит находится в материале как проверить AI-навык перед установкой.
Какой минимальный чек-лист нужен перед пилотом?
Пилот готов, если секрет не хранится в skill, credential отдельный и короткоживущий, scopes минимальны, дочерняя среда очищена, сеть и файлы ограничены, логи маскируются, а отзыв проверен.
- Назначен владелец секрета и ротации.
- Определён один разрешённый получатель.
- Нет секрета в Git, аргументах и fixtures.
- Действия записи подтверждаются отдельно.
- Deny-правила проверены отрицательным тестом.
- Логи и артефакты не содержат значения.
- Отзыв и аварийная замена воспроизведены.