Чувствительные данные и секреты

1. Deny-rule остановит команду. Ваш copy-paste — нет

Allow/ask/deny rules и protected paths вроде payments/** и .env* уже закрыли одну боль: Claude не ходит свободно по чувствительным зонам репозитория. Кажется, после этого можно выдохнуть — но есть неприятный момент: deny-rule останавливает команду, а ваш собственный copy-paste в prompt — нет. Именно здесь начинается сегодняшняя тема. Когда мы говорим про безопасность AI-workflow, очень легко думать только в терминах команд: что Claude запустит, отредактирует, куда полезет. Это важно, но это лишь половина картины. Вторая — какой материал вы сами приносите в сессию. Токен, customer email, сырой production-лог, экспорт support ticket'а, вставленные вручную, — проблема случилась раньше любого tool call.

Здесь полезно держать в голове простую формулу:

Permissions ограничивают действия Claude, а гигиена данных ограничивает материал, который вы сами вносите в контекст.

Это два разных слоя. Но ни CLAUDE.md, ни deny-rule не фильтруют буфер обмена — вставили лишнее, значит сознательно. Claude Code, как очень честный стажёр, не скажет: «Я вижу, у вас тут случайно живой Stripe key, давайте я отвернусь». Он это прочитает, учтёт и, возможно, включит в summary.

Из-за этого даже безобидная на первый взгляд задача может резко стать рискованнее. Обновление документации обычно тянет на low-risk. Но вставьте в сессию production-логи с email клиентов, внутренними URL и следами токенов — и это уже не «просто про README». Риск определяет не вид работы, а качество данных.

И ещё один важный нюанс. Многие думают о чате как о разговоре «здесь и сейчас» — но в Claude Code это не просто разговор, а цепочка артефактов: transcript, tool outputs, file snapshots, exported notes, generated docs, иногда screenshots и handoff notes. Вы разговариваете не только с моделью, но и с будущей стенограммой этой беседы. А стенограмма живёт дольше, чем вам хотелось бы.

2. Секреты начинаются раньше, чем sk_live_...

Когда слышишь слово secrets, мозг сразу рисует пароли и API-ключи. Картинка правильная, но слишком узкая. В реальном проекте чувствительные данные начинаются задолго до строки sk_live_... и заканчиваются много позже — особенно там, где есть деньги, пользователи и support, как в нашем Commerce OS. Полезнее смотреть не на один тип сущностей, а на несколько рабочих категорий.

STRIPE_API_KEY

JWT_SECRET

DATABASE_URL

Здесь есть тонкая, но очень важная мысль. «Синтетические значения» — не «любые случайные числа». Баг проявляется только для возвратов выше 100 USD — нельзя заменить 149.00 на 9.00: смысл кейса умрёт. Ошибка про переход даты через полночь в другом часовом поясе — нельзя заменить проблемный timestamp на спокойную дату посреди дня. Хорошая sanitization сохраняет логику проблемы, плохая делает всё безопасным и бесполезным.

Поэтому лучше думать так: вы не прячете правду, вы прячете лишнюю идентификацию. Нужен факт, что сумма была выше порога, — а не то, что клиент Иван Петров получил refund на 149.37 USD по заказу ORD-938221-AZ. Для расследования важен порог и переход состояния, а не судьба бедного ORD-938221-AZ. Совсем просто: чувствительные данные — это всё, что помогает узнать кто, где, с чем именно и как устроено внутри, когда для задачи достаточно знать только какой механизм сломался.

3. Утечка расползается по мелочам

Когда говорят «не вставляйте секреты в промпт», это звучит правильно, но немного наивно. В реальной работе данные редко утекают одним красивым движением через большую вставку. Чаще расползаются по мелочам: кусок попал в командный вывод, другой — в screenshot, третий — в handoff note, четвёртый — в summary от subagent'а. Никто вроде ничего ужасного не сделал, а утечка уже случилась. Удобно смотреть на это как на набор поверхностей, с которыми вы работаете каждый день.

Очень типичный антипример выглядит так:

cat .env           # Плохо: реальные ключи попадут в вывод команды и в transcript
cat .env.example   # Хорошо: структура конфигурации понятна, секретов нет

Здесь проблема не в команде как таковой. Проблема в том, что вывод команды — это тоже контекст. А значит, если вы один раз показали модели реальный .env, дальнейший /clear уже не волшебная резинка. Он чистит текущий диалоговый слой, но не отменяет того факта, что вы уже создали локальные артефакты, могли экспортировать сессию, переслать summary или зафиксировать эту информацию в заметках.

То же самое относится к generated docs. Очень коварный сценарий: вы скормили Claude Code сырые данные «на минутку», а потом попросили сделать EVIDENCE_LOG.md или REVIEW_NOTES.md. Модель, как дисциплинированный помощник, честно включила туда то, что посчитала важным. В этот момент утечка перестаёт быть «где-то в чате» и становится обычным файлом в репозитории или рабочей папке.

Отдельно запомните одну неприятную вещь про subagent’ов. Изоляция контекста — это не магическая дезинфекция. Если subagent прочитал чувствительные данные, его summary тоже становится чувствительным материалом. То есть subagent отлично изолирует рассуждение, но не превращает сырой production log в безопасный. Было бы удобно, конечно, но увы.

4. Санитизация, которая не убивает улику

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

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

Например, для бага с возвратами важна не фамилия клиента, а факт, что возврат был выше порога и перешёл не в то состояние. Поэтому вместо сырого ticket лучше передавать модели вот такой summary:

## Summary по refund issue

Order id: ORDER-****-2048
Customer: existing_user_01
Refund amount: 149.00 USD
Observed behavior: status changed from `PENDING` to `APPROVED`
Expected behavior: refunds above `100.00 USD` must stay `PENDING_APPROVAL`
Environment: production-like reproduction on sanitized dataset

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

То же самое касается логов. Плохая sanitization часто выглядит как «заменим всё на ***». В результате модель видит невнятную кашу. Намного полезнее оставить структуру лога, но убрать идентификацию:

2026-05-12 10:14:33 WARN RefundPolicyChecker
orderId=ORDER-****-2048 customerEmail=<masked@example.com>
amount=149.00 USD threshold=100.00 USD
actualState=APPROVED expectedState=PENDING_APPROVAL

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

Очень частая ошибка — замаскировать значение, но не сохранить формат. А формат иногда и есть половина бага. Если у вас ошибка возникает только на длинных order id или на конкретном timezone-переходе, это свойство нужно сохранить и в обезличенном примере. То есть ORDER-****-2048 лучше, чем просто 123. А timestamp, который пересекает границу даты, полезнее, чем вычищенная «нейтральная» строка без временного контекста.

Скриншоты подчиняются той же логике. Если вы показываете модели или коллеге экран админки, то crop и blur — не косметика. Это способ не тащить email, адрес, номер заказа и список прошлых покупок, когда для обсуждения нужен только один блок со статусом возврата. У screenshot’а ровно такой же статус артефакта, как у markdown-файла. Он не становится безопасным только потому, что в формате PNG.

5. Правило, а не одноразовое озарение

На этом этапе важно перейти от «я понял мысль» к «у меня это зафиксировано в процессе». Потому что одноразовое озарение живёт примерно до первого дедлайна. А потом начинается старое доброе «да ладно, один раз вставлю». Именно поэтому в Workflow Kit правила про чувствительные данные лучше оформлять как артефакты, а не держать только в голове.

Начать стоит с простого: CLAUDE.md и CLAUDE.local.md — не место для секретов. Вообще. Ни «временный test key», ни «быстрый доступ к staging DB», ни «на всякий случай положу токен». Эти файлы подтягиваются в сессии снова и снова. Положить туда секрет — всё равно что приклеить его на монитор, только ещё и удобнее для модели.

Гораздо полезнее вынести правило в отдельный rule-файл внутри Workflow Kit. Например, так:

# rules/no-secrets-in-prompts.md

Не вставляй в prompts, task spec, notes и examples реальные API keys, tokens,
пароли, содержимое `.env`, customer email, phone и address.
Используй `.env.example`, маски и санитизированные summaries.
Если секрет уже попал в вывод команды, считай его скомпрометированным:
остановись, замени секрет и не распространяй исходный transcript дальше.

Этот фрагмент полезен сразу по нескольким причинам. Во-первых, он короткий. Во-вторых, он не пытается быть курсом по compliance. В-третьих, в нём есть не только запрет, но и безопасная замена: .env.example, маски, summaries. То есть правило не просто говорит «нельзя», а ещё и показывает нормальный маршрут.

Дальше имеет смысл закрепить это в рабочих файлах, которые люди реально открывают. Например, в CLAUDE.md проекта можно спокойно оставить такой раздел без каких-либо секретов:

## Работа с конфигами и логами

Используй `.env.example`, а не `.env`.
Для разбора ошибок вставляй только санитизированные логи.
Не включай customer data и реальные identifiers в notes, docs и review artifacts.
Если не уверен — сначала обезличь данные, потом отдавай их в сессию.

Заметьте: тут нет enforcement в техническом смысле. И это нормально. CLAUDE.md напоминает намерение, а rules, hooks и review удерживают дисциплину. Именно эта связка и делает процесс живым. Потому что одна только инструкция быстро забывается, а одни только deny-правила не решают проблему ручного copy-paste.

Отдельно следите за evidence-файлами. EVIDENCE_LOG.md, REVIEW_NOTES.md, PR_DESCRIPTION.md, HANDOFF_NOTE.md и даже обычный комментарий в командном чате часто становятся местом вторичной утечки. Вы уже всё правильно обезличили в prompt, но потом попросили Claude сделать красивое summary и забыли его перечитать. В итоге чувствительные значения возвращаются через боковую дверь. Поэтому generated docs в таких темах всегда требуют ручного финального чтения глазами, а не только доверия diff’у.

И да, subagent здесь тоже не иммунитет. Если reviewer-agent или debugger-agent получил опасный контекст, его вывод надо ревьюить так же строго, как и свой собственный. Subagent — это не химчистка для секретов. К сожалению. Было бы очень удобно, но пришлось бы читать меньше лекций, а это уже подозрительно.

6. Расследуем баг возвратов без утечки

Чтобы всё это не осталось красивой теорией, давайте сложим реальный сценарий. Представьте, что в Commerce OS пришёл сигнал: возвраты выше 100 USD иногда проходят без ручного подтверждения. Сама по себе задача явно review-required, потому что затрагивает деньги и flow возвратов. Но если вы ещё и начнёте кормить Claude сырыми production-данными, вы быстро скатитесь в high-risk поведение уже на уровне контекста.

Правильная работа начинается не с «скину-ка я весь лог». Она начинается с подготовки безопасного пакета доказательств. Вы берёте реальный кейс, вручную вынимаете из него только значимые свойства и превращаете всё это в короткий sanitized summary. Затем добавляете минимальный лог-отрывок, где видны состояния и порог, но не видно клиента, токена, внутреннего host name и платёжного идентификатора. И только после этого идёте в Claude Code.

Хороший исследовательский запрос в такой ситуации может выглядеть так:

Исследуй баг с возвратами в Commerce OS.

Используй только санитизированные данные из этого task spec.
Не читай `.env` и не проси полный production log.
Сфокусируйся на логике порога возврата и переходе состояний.
Верни:
1. вероятную причину;
2. затронутые файлы;
3. шаги локальной проверки;
4. что ещё нужно подтвердить вручную.

Обратите внимание: такой prompt не делает вас беднее в расследовании — он дисциплинирует анализ. Вы не заваливаете модель мусором, не создаёте новый риск и получаете структурированный результат. А если позже понадобится handoff note для коллеги, у вас уже есть обезличенный материал, который не страшно передать дальше.

Именно в таких рабочих привычках и проявляется зрелость AI-native engineering. Не в том, что вы знаете модное слово sanitization, а в том, что перед каждым багом автоматически спрашиваете себя: «Что здесь реально нужно для анализа, а что я сейчас собираюсь тащить по инерции?» В какой-то момент это перестаёт ощущаться как дополнительная бюрократия и начинает работать как обычная инженерная гигиена — примерно как проверить diff перед commit. Только здесь вы проверяете не код, а следы данных, которые этот код и ваша сессия оставляют вокруг себя.

7. Облачные планировщики расширяют поверхность утечки

Отдельно стоит сказать про облачные поверхности Claude Code, потому что они заметно расширяют поверхность утечки данных. Облачный планировщик и облачное ревью (условно /ultraplan, /ultrareview или их аналоги — точное имя и доступность могут меняться от версии к версии) работают не на вашей машине: исходный код, diff и контекст файлов передаются в облачное окружение и попадают в его транскрипты, логи и записи об учёте расходов.

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

Практические правила здесь звучат скучно, но эта скука и есть профилактика утечек. Репозиторий, ветка или diff, которые вы отправляете в облачный агент, не должны содержать секреты в открытом виде, персональные данные клиентов, подписанные ассеты или продакшн-доступы в истории коммитов. Перед запуском такой команды полезно явно проверить, какие файлы попадают в контекст — часто это вся ветка вместе с метаданными репозитория и зависимостями, — и пройтись по подозрительным маскам: .gitignore, secret, .env*, *credential*, *key*.

Регулируемые среды — HIPAA, PCI-DSS, FedRAMP, данные с требованием on-prem-only — с облачными поверхностями обычно несовместимы по требованиям соответствия, и там безопаснее оставаться на локальных subagents и плагинах. След аудита облачной сессии — что отправлено, что получено, кем запущено — должен быть доступен владельцу команды, иначе следа для проверки соответствия просто не существует, а это сам по себе стопор в регулируемой среде. И, наконец, вывод облачного агента — размеченный diff, план, находки — это тоже поверхность утечки: не публикуйте его в открытых артефактах без чистки.

Но даже идеально санитизированный контекст не отвечает на другой вопрос: где вообще должен жить рискованный эксперимент. Когда данные уже очищены, следующий слой защиты — песочница, а не героизм в основной рабочей копии.

1

Задача

Claude code, 23 уровень, 2 лекция

Недоступна

Terminal-скан сырого набора артефактов

Terminal-скан сырого набора артефактов

Открыть

1

Задача

Claude code, 23 уровень, 2 лекция

Недоступна

Исправление `.gitignore` и `.env.example`

Исправление `.gitignore` и `.env.example`

Открыть