nah для Claude Code: контекстный «стоп-кран» вместо грубых разрешений — VogueTech

Что появилось / что изменилось

В экосистеме Claude Code появился nah — контекстный guard для прав доступа. Он встраивается как PreToolUse‑хук и проверяет каждый вызов инструментов до выполнения.

Главное отличие от стандартных прав Claude Code: вместо простого allow/deny на уровень «инструмент целиком» nah смотрит, что именно делает команда и где она это делает.

Конкретные новшества:

Классификация каждого вызова Bash, Read, Write, Edit, Glob, Grep и MCP‑инструментов по типу действия, а не по имени команды.
Мгновенная (миллисекунды) детерминированная проверка без LLM, с опцией подключить LLM только для спорных кейсов.
Готовые политики по типам действий: allow, context, ask, block для 20 встроенных action types.
Отдельная логика для чувствительных путей: ~/.ssh, ~/.aws, .env и собственных директорий из конфигурации.
Инспекция содержимого для Write/Edit: поиск приватных ключей (-----BEGIN PRIVATE KEY-----), секретов, попыток эксфильтрации и деструктивных payload’ов.
Демо‑сценарий /nah-demo прямо в Claude Code: 25 живых кейсов по 8 категориям угроз (RCE, утечка данных, обфускация и т.д.), занимает около 5 минут.
Простая установка: pip install nah и nah install; удаление — nah uninstall && pip uninstall nah.

Из коробки всё работает без настроек, но есть глобальный конфиг ~/.config/nah/config.yaml и проектный .nah.yaml, который может только ужесточать правила.

Как это работает

Архитектура у nah двухслойная.

Детерминированный классификатор.
- Каждый вызов инструмента сначала проходит через структурный анализ.
- Для Bash nah разбирает тип действия, пайпы, декодирование и последующее выполнение (base64 -d | bash распознаётся как decode+exec и блокируется).
- Для Read/Write/Edit — проверка пути (проект против домашней директории), границ проекта и содержимого.
- Для Glob и Grep — защита от сканирования чувствительных директорий и поиска секретов вне проекта.
- MCP‑инструменты (mcp__*) проходят через общий классификатор.
Опциональный LLM‑слой.
- Если детерминированный слой не может уверенно решить, он помечает действие как ask.
- Можно подключить LLM‑провайдер (Ollama, OpenRouter, OpenAI, Anthropic, Snowflake Cortex).
- Поток: tool call → nah (детерминированный) → LLM (по желанию) → встроенные права Claude Code → выполнение.
- Если LLM недоступен, остаётся ask, и решение принимает пользователь.

Решения кодируются просто:

✓ — пропускает тихо.
nah. — блокирует.
nah? — спрашивает подтверждение.

Один и тот же бинарь ведёт себя по‑разному в зависимости от контекста:

rm dist/bundle.js внутри проекта — разрешено.
rm ~/.bashrc — запрос подтверждения или блокировка.
git push — ок.
git push --force — запрос, как переписывание истории.

Профили классификации задаются параметром profile: full|minimal|none в конфиге. По умолчанию — full с широкой покрываемостью shell, git, пакетов, контейнеров.

Что это значит для вас

Если вы активно пользуетесь Claude Code как «автопилотом» в терминале и редакторе, nah снижает риск того, что ИИ случайно:

удалит нужные файлы (rm -rf не там, где надо);
тронет важные дотфайлы (~/.bashrc, ~/.ssh);
вытащит ключи из ~/.aws/credentials или id_rsa;
выполнит обфусцированную команду из curl sketchy.com | sh.

Практические сценарии, где nah полезен:

Ежедневная разработка. Можно спокойно давать Claude Code доступ к Bash, Read, Glob, Grep и не бояться, что он внезапно сделает rm -rf ~.
Работа с секретами и прод‑конфигами. Чувствительные каталоги настраиваются в sensitive_paths, например ~/Documents/taxes: block или ~/.kube: ask.
Командная разработка. Проектный .nah.yaml жёстче глобального: команда может зашить правило «никогда не делать force push» (git_history_rewrite: block).

Где nah не решит все проблемы:

Он не заменяет аудит кода и нормальную практику работы с секретами.
В режиме --dangerously-skip-permissions смысла в нём почти нет: разработчики прямо предупреждают, что в bypass‑режиме хуки срабатывают асинхронно и могут не успеть заблокировать команду.

Рекомендованный режим: не использовать --dangerously-skip-permissions, оставить в allow‑листе Bash, Read, Glob, Grep, а Write/Edit — по ситуации. nah всё равно инспектирует содержимое.

Место на рынке

nah решает конкретную боль текущей системы прав Claude Code: грубый allow/deny на уровне инструмента плохо масштабируется, потому что:

удалять временные файлы иногда нормально, а иногда опасно;
git push безопасен, а git push --force — нет;
даже тщательно подобранный deny‑лист легко обойти за счёт креативных комбинаций команд.

Здесь nah предлагает другой принцип: политика по типу действия, а не по имени команды. Например:

filesystem_delete: ask — всегда спрашивать при удалении;
git_history_rewrite: block — никогда не разрешать force push;
lang_exec: allow — доверять встроенным скриптам, если вы к этому готовы.

Конкурентами по духу можно считать любые permission‑системы вокруг ИИ‑ассистентов, которые ограничиваются простым списком разрешённых инструментов и путей. На их фоне nah даёт более детальную грануляцию внутри одного и того же инструмента: Read ./src/app.py проходит, а Read ~/.ssh/id_rsa — блокируется.

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

Если вы уже используете Claude Code и боитесь режима --dangerously-skip-permissions, nah выглядит как разумный компромисс: меньше ручной настройки deny‑листов и больше автоматического контекстного контроля без заметной задержки (проверки занимают миллисекунды).

Что появилось / что изменилось

Как это работает

Что это значит для вас

Место на рынке

Читайте также