Гайд · TNWS AI

Как скрыть переменную окружения от инструментов Copilot CLI

Copilot

19 сентября 2026 7 мин—

Применение --secret-env-vars для удаления секретной переменной из окружения shell/MCP-инструментов Copilot CLI, с тестом на фиктивном ключе.

Этот гайд решает конкретную задачу: не передавать выбранную переменную окружения дочерним shell и MCP-процессам агента, сохранив возможность запуска основной программы. Ниже — воспроизводимый сценарий, а не обещание, что любой текстовый запрос сам по себе создаёт техническое ограничение. Факты о флагах и доступности проверены 19 сентября 2026 года по официальной документации GitHub; динамические тарифы и неподтверждённые лимиты здесь не приводятся.

Задача и граница применимости

Сценарий применим к установленному и авторизованному GitHub Copilot CLI в доверенном тестовом репозитории. Основная команда: DEMO_API_KEY=FAKE_ONLY copilot --secret-env-vars=DEMO_API_KEY -p 'Проверь наличие DEMO_API_KEY в окружении инструмента без вывода значения' -s. Сначала выберите маленький тестовый проект, на котором можно проверить и успешный путь, и отказ. Если полномочий агента недостаточно, это безопасный сигнал уточнить конфигурацию, а не причина сразу включить все разрешения.

Важно различать четыре уровня: выбор доступных модели tools, разрешение tool на действие, доступ к файлам и сетевую политику ОС. Один флаг управляет лишь тем уровнем, который ему назначен в документации. Инструкция на естественном языке направляет поведение, но не заменяет реальное правило доступа. Поэтому результат оценивают по фактическим вызовам и артефактам, а не по фразе агента «я не буду».

Официальные источники и дата проверки

В справочнике команд GitHub Copilot CLI указаны синтаксис основных параметров, список имён tools и правила шаблонов разрешений. Руководство по разрешениям различает --available-tools/--excluded-tools и --allow-tool/--deny-tool, объясняет сохранённые разрешения и приоритет deny. Для запуска с -p, -s и --no-ask-user используется официальное руководство по программному запуску. Эти первоисточники просмотрены 19 сентября 2026 года. Не переносите без проверки параметры между разными CLI: одинаковое слово «agent» не означает одинаковую модель прав.

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

Подготовка тестового стенда

Проводите тест только с фиктивным DEMO_API_KEY=FAKE_ONLY. Официальная справка --secret-env-vars=VAR определяет как redaction переменной из окружения shell и MCP server; параметр можно повторять, несколько значений допускаются quoted comma-separated list. Значения GITHUB_TOKEN и COPILOT_GITHUB_TOKEN редактируются из output по умолчанию согласно документации, однако полагаться на это вместо секрет-хранилища нельзя. Не вкладывайте реальный токен в аргумент команды, prompt или диагностический вывод.

Запишите исходное состояние проекта: текущий каталог через pwd, версию CLI через copilot version, git status --short и наличие нужных входных файлов. Не вставляйте реальный секрет в тестовый prompt, публикацию или screenshot. Разделяйте код процесса, код завершения Copilot и утверждения модели: успешный exit code не доказывает правильность итогового текста, а отказ в разрешении не обязательно означает ошибку конфигурации.

Пошаговое выполнение

В родительском shell задайте фиктивное значение и убедитесь, что переменная существует у запускающего процесса; используйте проверку наличия, не печатайте значение.
Запустите Copilot с --secret-env-vars=DEMO_API_KEY и безопасной задачей, которая при наличии разрешения проверяет только факт существования переменной в shell tool.
Попросите вернуть YES или NO, не значение. Ожидайте NO для окружения инструмента; если tool не был вызван из-за разрешений, это не доказательство redaction.
Сопоставьте результат с контролем без флага на фиктивной переменной в отдельной тестовой сессии. Не делайте контроль с настоящим токеном.

После каждого прогона сравните git status --short с исходным состоянием. Если передан конкретный путь или имя инструмента, проверьте его посимвольно; похожее имя способно расширить либо сузить правило. Для команд с shell-скобками заключайте всё значение опции в одинарные кавычки. На Windows используйте правила кавычек своей оболочки и проверяйте, что CLI получает значение целиком.

Готовый шаблон для копирования

Команда для контролируемой проверки; замените указанные тестовые пути, если пример использует файлы, и сначала прочитайте смысл каждого аргумента:

DEMO_API_KEY=FAKE_ONLY copilot --secret-env-vars=DEMO_API_KEY -p 'Проверь наличие DEMO_API_KEY в окружении инструмента без вывода значения' -s

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

Реалистичный вход и ожидаемый результат

Вход: Процесс запуска имеет DEMO_API_KEY=FAKE_ONLY. Нужно исключить её из окружения доступного агенту shell, не раскрывая строку в отчёте.

Ожидаемый результат: Контрольная тестовая сессия без флага видит наличие переменной, с флагом — нет. Ни prompt, ни ответ, ни публикация лога не содержат FAKE_ONLY. Разница касается окружения инструмента, а не гарантии, что секрет никогда не попадёт в другие входные данные.

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

Положительный и отрицательный тест

Используйте shell-команду вида test -n "${DEMO_API_KEY+x}" и выводите только YES/NO. В статье эта команда дана как идея для отдельного тестового стенда; кавычки и расширение переменной должны исполняться в tool shell, а не при формировании prompt. Если агент не имеет shell-разрешения, сначала дайте минимальное разрешение лишь на безопасную проверку. Изолируйте стенд и после теста unset DEMO_API_KEY.

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

Ошибки, отладка и ограничения

Не путайте удаление env из инструмента с маскированием уже выведенного текста. Если вы вручную вставили ключ в prompt, флаг этого не отменит. MCP может иметь свои настроенные секреты вне родительского env, их проверяют отдельно. Не публикуйте логи включённой debug-диагностики с реальными значениями. Для production-секретов лучше отдельный vault и минимальные права сервиса.

Чтобы локализовать причину, сделайте второй прогон на пустом тестовом репозитории с одним изменяемым параметром. Не меняйте одновременно prompt, модель, каталог и разрешения: тогда нельзя понять, почему исчезла ошибка. Если модель сообщает об отсутствии ресурса, сначала проверьте путь и доступ на уровне процесса, затем разрешения CLI, и лишь после этого формулировку задачи.

Чек-лист финальной проверки

Точный синтаксис параметров сверен со справочником GitHub на 19 сентября 2026 года.
Входной файл, путь или домен соответствует тестовой задаче.
Исходное состояние репозитория записано до запуска.
Положительный тест показал ожидаемую разрешённую операцию.
Отрицательный тест не вызвал запрещённого действия.
Итоговый ответ сверён с фактическими файлами или журналом tools.
Секреты, реальные токены и частные пути не попали в отчёт.
Изменения в git просмотрены и объяснены.

FAQ

Что передавать в параметре?

Имя переменной, например DEMO_API_KEY, а не её значение. Для нескольких имён справка допускает список через запятую в кавычках.

Затрагивает ли флаг основной процесс?

Документированное назначение — redaction из shell и MCP environments. Проверяйте нужный эффект в конкретном инструменте.

Можно проверять настоящим ключом?

Не стоит: используйте фиктивный маркер и тест на наличие, иначе сам тест создаёт риск утечки.

Почему одно NO не доказательство?

Модель могла не вызвать tool. Посмотрите журнал фактического вызова и сравните с контролем без флага на фиктивном значении.

Итог

Для задачи «не передавать выбранную переменную окружения дочерним shell и MCP-процессам агента, сохранив возможность запуска основной программы» важна не только команда DEMO_API_KEY=FAKE_ONLY copilot --secret-env-vars=DEMO_API_KEY -p 'Проверь наличие DEMO_API_KEY в окружении инструмента без вывода значения' -s, но и доказательство её действия на маленьком тестовом случае. Сохраните исходное состояние, выполните разрешённый и запрещённый сценарии, затем перенесите только подтверждённый вариант в рабочий проект. При смене версии CLI перепроверьте первоисточник и повторите оба теста.